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

[＠IT]

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

マスタ型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 フェイルオーバー　サーバに障害が発生した際に、代替用のサーバが処理やデータを引き継ぐ機能であり、代替機により、引き続きサービスを継続させます。