株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

データベースのワークロードの特性とそのストレージアーキテクチャへの影響 - part 4 - NoSQLプラットフォーム

本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。

本記事の原文はDatabase workload characteristics and their impact on storage architecture design – part 4 – NoSQL platformsで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

データベースのワークロード特性シリーズのパート4へようこそ! データベースは仮想インフラストラクチャの中でもっともI/Oを消費するもののうちの一つだと考えられています。データベース操作とデータベース設計はそれ自身が研究ともなり得るものです。しかし、データベース設計の世界の表面から少し潜ってみるということはとても面白いことだと思いました。PernixDataの製品ディレクタであり、データベースの専門家である同僚のBara Narasimhan氏のもとへ赴き、データベース設計とそのI/Oの特徴について教えてもらいました。

本シリーズの以前の投稿はこちら :

質問4 : 最近のデータ管理業界で気に留めておくべきトレンドは何でしょうか?

この数年、データ管理業界では様々な革新が起こっています。以前の記事の中で我々は関係性(リレーショナル)モデル、スキーマ、そしてACIDコンプライアンスについて述べてきました。これらは関係性(リレーショナル)データベースのその成り立ちの基盤とも言えるものです。今回の記事では近年の革新であるNoSQLプラットフォームにフォーカスを当てます。

何年もの試行錯誤の中で、リレーショナルデータベースの要件(ACIDコンプライアンス、リレーショナルモデル、スキーマデザイン)が非常に面倒なアプリケーションがあることがわかってきました。これらのアプリケーションの詳細に深く入って行くことはしませんし、どうして要件が面倒なのかという議論もしません(もしも、そうしてほしいというのであれば喜んでやりますが[E:happy01])

このような発見に対しての反応として、業界はNoSQLプラットフォームとして総称される新しいデータ管理プラットフォームを開発し始めました。NoSQLプラットフォームの例としてはHadoopMongoDBが挙げられます。何よりもNoSQLプラットフォームはSQLに比べて、横展開、スケールアウトアーキテクチャ、プログラミングのパラダイムのサポートなどがその特徴です。多くのNoSQLプラットフォームは可用性や耐障害性を意識した一貫性よりも、一時的な一貫性に主眼をおいて設計されています。(これについての詳しい議論についてはこちらのCAP定理を見てください。) 例としてこれからは2つのNoSQLプラットフォームについて議論していきます。HadoopとMongoDBです。

Hadoop

Hadoopは以下の2つからなるソフトウェアフレームワークとして捉えることができます :

HadoopMapReduceジョブをクラスタ化されたマシン上で実行します、インタラクティブ処理ではなく、バッチプロセスのために設計されています。MapReduceジョブは非常に単純な形をしており、Mapフェーズとその後のReduceフェーズを合わせたものです。Mapフェーズは同一のキーを持つすべてのデータをマップにするプログラムと考えてください。同様にReduceフェーズはMapフェーズでの出力結果を減らし(Reduce)、ひとつの値にまとめる処理と考えてください。MapReduceジョブの基本的な例は「Word Count」プログラムです。(MapReduceがWord Countで何をしているかについて詳しくはこちら・訳注:リンク先は英文)

Hadoopは結果として巨大なシーケンシャルのReadとWriteを発行しているので、バッチ処理に最適です。Hadoopスループットがすべてのシステムです。パッチプロセスのHadoopに最適なワークロードの例はデータ準備ジョブや長時間のレポート処理です。

MongoDB

MongoDBは最近のアプリケーション開発のために作成された人気のNoSQLデータベースです。MongoDBはBinary JSON(BSON)と呼ばれるバイナリで構成されるドキュメントとしてデータを保存します。類似した構造を持つドキュメントはコレクションとして組織されます。それぞれのドキュメントは1つ以上のフィールドを持っています。MongoDBのコレクションはリレーショナルデータベースのテーブルのようなもので、ドキュメントは列のようなものです。ドキュメント内のフィールドはリレーショナルデータベースの行に相当します。MongoDBのリレーショナルデータベースに対する強力な差別化要因は堅牢かつ、柔軟なスキーマです。

MongoDBはKey-Value(キーバリュー)クエリ、レンジクエリ、アグリゲーションに非常に有効です。これはMongoDBによって生成される大抵のI/Oがランダムであることを意味し、ReadとWriteが程よくミックスされたものになります。つまり、MongoDBはレイテンシがすべてであり、低遅延によって大きなパフォーマンス面でのメリットを受けることが可能です。

FVPはどのように役立つのか?

NoSQLプラットフォームは従来のデータベースにおいて実行するためには非常に面倒な、もしくは非常に低パフォーマンスなアプリケーションのために開発されています。上で述べたようにとあるNoSQLプラットフォームはスループットがすべてであり、もう一方はレイテンシがすべてです。FVPがNoSQLプラットフォームの高速化において非常に強力である理由は :

  1. FVPはReadもWriteも双方を高速化します。これはサーバサイドのリソースを利用して高速化を行い、プラットフォーム上で走らせるワークロードの種類を選ばないということです。
  2. DFTMによって、これらのプラットフォームはサーバサイドのRAMを高速化リソースとして利用可能になります、これによって驚くほどのパフォーマンス向上が可能です。
  3. 巨大な一時ファイル作成や、リソースを消費するソートのような処理はFVP経由のRead/Write高速化のメリットを受けることが可能です

もはや、こうしたプラットフォームもパフォーマンスの心配をすることなく仮想化することが可能になったのです。馬鹿らしいサイロのアーキテクチャを増やすのではなく、PernixData FVPを利用する意味があります。FVPはVMwareの助けを借りて、高速化をフラッシュもしくはメモリを利用してクラスタ化された耐障害性のあるI/Oの高速化を実現します。高速化リソースを1つのシームレスなプールに仮想化することで、スループットを劣化させることなく仮想マシンはシームレスにクラスタ内のどんなホストへも移行できます。