Dynamoに触発されて開発されたNoSQLデータベースの1つに、「Voldemort」があります。この製品は大規模SNSサービスのLinkedIn(リンクトイン)で開発され、オープンソースとしてリリースされました。
LinkedInではサービスの成長に伴い、プロファイル、サーチ、グループ交流、ネットワーク更新、会社情報など、それぞれのサービスのためにデータベースを分けて対応してきました。これらのデータベースは読み出しのオペレーションを中心とし、書き込みオペレーションに対する拡張性は求められませんでした。
しかし最近の利用者は、「Who's Viewed My Profile(誰が自分のプロファイルを見ているか)」といったサービスをインターネットサイトに期待するようになりました。この種のサービスはビッグデータ型であり、読み出しよりも書き込みを多く要求され、しかも書き込みオペレーションに高い負荷が掛かります。こうしたことからLinkedInは「Dynamoに触発されてVoldemortを開発した」と説明しています。
Dynamoと共通する特徴 VoldemortはDynamoと同じく結果整合性を採っています。しかし、Quorum*10により整合性レベルを調整できます。
そこで発生する複数バージョンの管理にも、やはりDynamoと同じくベクタークロックを用いています。また、拡張性を得るためのデータの分割および複製には、コンシステント・ハッシングを用いています。ストレージエンジンはプラグイン方式を採用しており、BerkeleyDB、MySQLなどのDBMSと併用する必要があります。
Hadoop MapReduceとの連携 Voldemortは、Hadoop MapReduce処理からVoldemortのデータファイルを直接出力し、リードオンリー(読み出し専用)のテーブルとして公開する機能を備えています。公開したテーブルは、応答性が要求されるアプリケーションや、他のMapReduce処理から参照できます。時間がかかるデータベースへのファイルのインポート処理を省けるので、データの作成から公開までの時間を大幅に削減できます。
また、MapReduce処理を再び実行して更新版のデータファイルを作成した場合でも、テーブルをオンラインにしたまま更新版へ切り替えることができます。LinkedInはHadoop MapReduceのヘビーユーザでもあることことから、このような機能が必要になったようです。
*10 Quorum 複製データの整合性を保証する際に用いられるアルゴリズムの1つ。高頻度でデータ更新が発生する場合、複数のノードにデータを書き込みむ際、全てのノードへの書き込みが終わっていない可能性があります。Quorumとは、このような状況下でも読み込むデータが必ず正しくなることを保証する方法のことを指します。書籍では分散データの整合性確保について別途節を設けて解説しています。
RiakはCAP定理*11とAmazon Dynamoに触発されて、Basho Technolo-giesが開発しました。オープンソース版のほか、Riak Enterprise DSという商用パッケージが提供されており、2011年9月末にバージョン1.0がリリースされました。
豊富な機能 Riakは、キーとバリュー(オブジェクト)の他に、RDBのテーブルに相当し、オブジェクトをグループ化するバケットがあり、この「キーとバケット」がバリューと対になるというデータモデルを実現しています。
バリューはJSONフォーマットで保存し、取り出せるので、ドキュメント指向型に近いといえます。ただし、ドキュメント指向型はドキュメント内のフィールドを指定できますが、Riakはドキュメントを単にオブジェクトとして保存する点が異なっています。また、オブジェクトとオブジェクトの間のリンクも扱うことができます。
その他、RiakにはMapReduce、全文検索(Riak Search)といった機能があり、商用パッケージ版には、ネットワーク機器の監視プロトコルであるSNMP、複数データセンター間のレプリケーション(データセンターをまたがる複製)、Webベースのインターフェースによる管理ツールが追加機能として実装されています。
Dynamoと共通する特徴 Riakも「結果整合性」が、Quorumにより整合性レベルを調整できます。
バージョン管理もDynamoと同じく、ベクタークロックを用いて行います。データの分割と複製にはコンシステント・ハッシングを使っています。ゴシッププロトコルにより、どのノードが生きており、どのサーバがどのデータを保存し、クライアントからのリクエストに応えているかを把握します。
ストレージエンジンをプラグイン可能 Riakは、Bitcaskというストレージエンジンとともに提供されますが、このローカルストレージ部分はプラグイン可能であり、他のストレージエンジンを利用することもできます。また、バケットごとにストレージエンジンを選択することもできます。
バージョン1.0からはGoogleが開発したLevelDB*12も選択できるようになりました。LevelDBではBigtableのLSM-Treeに近い構造でデータを保存するため、書き込み性能に優れています。また、Bitcaskと比べるとメモリの使用効率が良いという利点がある一方で、読み込みの性能はBitcaskより劣るようです。
*11 CAP定理 分散システムにおいては、Consistency(整合性)、Availability(可用性)、Partition Tolerance(分断耐性)の3つのうち、最大で2つしか同時に実現できない、とするもの。Eric Brewer氏が講演「Towerds Robust Distributed System」で発表したものです。分散システムでは、CPもしくはAPのいずれかに分類できるとされています(参考リンク)。書籍では第3章で解説しています。
*12 LevelDB Googleがオープンソースとしてリリースしたキー・バリュー型のNoSQLデータベースです。詳細はhttp://code.google.com/p/leveldb/を参照してください。
本連載で抜粋・紹介している原稿の初出は下記書籍です。本連載では詳述していないNoSQLの基本的な考え方、アーキテクチャの詳細などは、書籍でご確認ください。
本書はクラウディアン(旧ジェミナイ・モバイル・テクノロジーズ)の技術者らが監修および執筆を行っています。同社は、国産NOSQL「HIBARI」を開発、その後、Cassandraに自社の「HyperStore」を実装したクラウドストレージ用パッケージソフトウェア「Cloudian」を開発して、現在商用提供を行っているITベンチャー企業です。
Copyright © ITmedia, Inc. All Rights Reserved.