検索
連載

KVS系NoSQLのまとめ(Hibari、Dynamo、Voldemort、Riak編)知らないなんて言えないNoSQLまとめ(1)(2/4 ページ)

エンジニアとして「知らない」とは言えない空気が漂うNoSQL界隈……。いろいろあるけども何がどう違うのか、主要プロダクトの特徴をコッソリ自習しよう。第1回はKVS系NoSQLの中から、マスタ型、P2P型に分類されるものを紹介していく。

Share
Tweet
LINE
Hatena
※本記事はアフィリエイトプログラムによる収益を得ています

マスタ型KVS「Hibari」

 マスタ型のキー・バリューストア(KVS)として、最初にHibariを紹介します。

Webメールのメールボックスに利用されたHibari

 Hibariは、GoogleのGmailのように、ユーザ1人当たり数GBのメールボックスを提供するWebメールに利用されています。大規模システムでの運用を経た後に、オープンソースとして公開されました。

チェイン・レプリケーションによる強い整合性

 Hibariの開発が始まった2005年には、Bigtableの論文(2006年発表)もDynamoの論文(2007年発表)もまだ世に出ていませんでした。そのためHibariでは、2004年に発表された論文*2を参考にした「チェイン・レプリケーション」という仕組みにより、「強い整合性」を提供します。この仕組みの概念を図2に示します。


図2 Hibariのチェイン・レプリケーション

 この図は、異なる3つのノードに3つの複製を作る場合を表しています。チェイン・レプリケーションでは、複製を行うノードに対し、Head Brick(ヘッドブリック)、Middle Brick(ミドルブリック)、Tail Brick(テイルブリック)という役割を与えます。

 書き込みの際には必ず、Headの役割を担うノードに対して書き込みを行い、Middle、Tailの順に複製を作っていきます。そして、Tailノードへの複製が完了した時点で、書き込み完了を告げる応答をクライアントに返します。データを読み出す際には、必ずTailから読み出します。つまり、複製途中の状態で読み出しが行われることがないため、データは常に整合性を保つことになります。

 ただし、書き込み重視のNoSQLデータベースと異なり、Tailへの複製が完了するまでの間、遅延が生じるというトレードオフがあります。

テーブルの分割にコンシステント・ハッシング Hibariはデータ分割にコンシステント・ハッシングを用いています。テーブルの作成時に、キーの区切り文字を指定することで、キー先頭の区切り文字以前の部分だけを対象にして、データの格納先となるチェインを決めることができます。例えば、キーの先頭部分にユーザIDを使用すれば、そのユーザに関連する全てのキー・バリューを同じチェインに格納することができます。

 これにより、ある一定のキーの範囲を探す「レンジ・スキャン」を高速化でき、次に説明する「マイクロ・トランザクション」も利用可能になります。なお、それぞれのチェイン内では、キー・バリューはキーの辞書順に格納されます。

マイクロ・トランザクションとCAS操作 Hibariでは強い整合性を生かして、マイクロ・トランザクションというユニークな機能を提供しています。これは、同一チェインに属する複数のキー・バリューの更新をアトミック*3に行う機能です。あるトランザクションに属する一連の処理が全て成功すればHibariに反映され、1つでも失敗すれば処理の全体が取り消されます。

 これはリレーショナル・データベース(RDB)における「コミット」および「ロールバック」に近い動作といえるでしょう。コミットでは、データの更新処理を有効な結果として確定し、データベースに反映します。ロールバックでは、トランザクションによるデータの更新処理の途中で何らかの障害が発生した場合に、それまでの更新処理を無効とし、トランザクションが実行される前の状態に戻します。

 Hibariでは、同一チェイン内という制限を持たせることで、他の方法で見られるような性能の低下を回避しています。また、キー・バリューのタイムスタンプを利用したCAS操作も可能です。

読み込み性能を重視 NoSQLデータベースには書き込み性能を重視したものが多いのですが、Hibariでは読み込み速度を高速化する工夫が施されています。

 例えば、指定したキー・バリューをメモリに常駐させたり、キー・バリューにメタデータという属性を付与して、それを元に、読み込み対象となるキー・バリューを絞り込むことができます。メタデータはメモリに常駐するので、絞り込みは瞬時に実行できます。また、LSM-Treeと異なり、データファイルの世代が増えても、読み込み性能が劣化しない設計となっています。

フェイルオーバー可能なマスタ Hibariはマスタ型ですが、マスタノードは各ノードの状態監視やコンシステント・ハッシュ表の維持といった管理タスクのみを担当します。クライアントからのデータアクセスには関与しないので、もしマスタに障害があっても、クライアントはデータの読み書きを継続できます。ある特定の時点でアクティブになることができるマスタは1つだけですが、あらかじめ複数のマスタをホットスタンバイ(起動状態で待機)させておき、障害時に自動的にフェイルオーバー(障害迂回)*4させることができます。


*1 Hibari Erlangで書かれたキーバリューストア型データベース。プロジェクトの情報は、https://github.com/hibariにあります。

*2 “Chain Replication for Supporting High Throughput and Availability”(PDF)

*3 アトミック(Atomic) 不可分操作(Atomic Operation)のことです。幾つかの操作の組み合わせであっても、システムの他の部分から見て、それらが1つの操作に見えるものを指します。不可分操作においては、次の2つの条件を満たさなければならないとされています。(1)全操作が完了するまで、他のプロセスはその途中の状態を観測できない。(2)一部操作が失敗したら組み合わせ全体が失敗し、システムは不可分操作を行う前の状態に戻る。つまり、幾つかの操作の組み合わせであっても、システムの他の部分から見ると、失敗したか成功したかのいずれかに見えることから、不可分操作と呼ばれます。

*4 フェイルオーバー サーバに障害が発生した際に、代替用のサーバが処理やデータを引き継ぐ機能であり、代替機により、引き続きサービスを継続させます。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る