NOSQLの新顔、分散KVS「okuyama」の機能
(3)データ・ノード
データ・ノードは、データの保存を担当するノードです。
データ永続化サポート
データを保存する際の特性として最も気になるのは、ノードの停止時にデータが消えてしまう特性なのか、それともディスクなどに書き出されることによって消えずに残る特性なのか、という点でしょう。キー・バリュー・ストアの場合はキャッシュ・システム用途に利用されることが多く、必ずディスクに書き出される(永続化される)必要はあるわけではありません。
okuyamaは、ストレージとしても利用できるように、データの永続化も可能にしています。また、永続化/非永続化だけではなく、永続化の中で、いくつかの特性から1つを選択できます。それぞれの特性を説明する前に、okuyamaにおけるデータ永続化の仕組みを説明します。
okuyamaは、データの永続性を、操作ログを使って実現しています。操作ログとは、すべてのデータ操作の記録をログ形式で時系列に記録し、再起動時にログ・ファイルを先頭からトレースすることでデータを復元する仕組みです。
図2-4: データ永続化の仕組み(クリックで拡大) |
okuyamaは、この仕組みをベースにKeyとValueのデータを保存する場所を選択することで、異なった特性のストレージを提供しています。それぞれの特性と仕組みは、以下の通りです。
- 非永続化型
- KeyとValueの両方をメモリー上に保持:
操作ログ・ファイルを残しません。このため、ノードが停止すれば、データを復元することはできません。しかし、ファイルI/Oが発生しないため、データ更新処理も高速に処理できます。
- KeyとValueの両方をメモリー上に保持:
- 永続化型
- 操作ログ+Key=メモリー+Value=メモリー:
操作ログを残すこと以外は、非永続化型と同じです。永続化されつつ、取得性能に関しては完全メモリー型と同じ性能が出ます。ただし、すべてのデータはメモリー上で管理されるため、保持できるデータ・サイズも、おのずとメモリーの上限になります。 - 操作ログ+Key=メモリー+Value=ファイル:
Valueだけがデータ・ファイルに書き出される方式です。Keyはメモリー上で、Valueがデータ・ファイルのどこに存在するかを管理します。データ取得処理の際は、メモリー上のKey値を高速に検索し、Valueをデータ・ファイルからピンポイントに取得します。このため、高速なディスク・システム上、特に、SSDのようなランダム・リードが高速な場合は、効率的に稼働します。また、全体として大量のデータを管理するけれども通常時に取得するデータが偏っている場合などは、データ・ファイルがOSのページ・キャッシュに存在し続けるため、高速に処理可能です。 - 操作ログ+Key=ファイル+Value=ファイル:
Key、Valueともにファイルで管理する方式です。メモリーを利用しないため、ディスクの上限までデータを管理可能です。Keyを管理するファイルは、1つのファイルに書かれるのではなく、大量のファイルのいずれかに一定のアルゴリズムのもとで導き出したファイルに書き出されます。メモリーの制約を受けなくなった反面、データ取得、更新ともに、最も遅い方式になります。
- 操作ログ+Key=メモリー+Value=メモリー:
(4)okuyamaの性能を支える仕組み
ここまでは、okuyamaを構成する要素を解説してきました。最後に、これらの各構成要素をつなぐネットワークの仕組みを紹介します。
大量アクセスをさばくネットワークI/Oの仕組み
分散キー・バリュー・ストアは、その特性上、単純データの高速な管理に用いられることが多いです。このため、同時処理の要求が多くなりがちです。
okuyamaは、こうした処理要求に応えるため、タスク別キューイング・メカニズムという仕組みを備えています。これは、クライアント(データ・ノードの場合はマスター・ノード)からの処理要求をタスクという形で分類し、タスク単位の専用のワーカー・スレッドに処理させるというものです。
この仕組みにより、ワーカーの処理内容を局所化できます。かつ、1接続に1ワーカーを割り当てずに済みます。これにより、少ないスレッド数で大量の処理要求を処理できます。
図2-5: タスク別キューイング・メカニズム(クリックで拡大) |
今回の解説で、okuyamaの全体像をつかんでもらえたでしょうか。
okuyamaは、ノードに障害が発生した際の対応やノード追加時のデータ再配置などを自動化することで、分散環境で起こりがちな運用の難しさや運用負荷の増加を極力抑えるように設計、開発されています。また、利用シーンに合わせたストレージ特性の変更により、多様なユース・ケースで利用できます*1。
- [*1] ユース・ケース別の利用パターンは連載4回目で解説する予定です。
説明したいことはたくさんありますが、説明ばかりではつまらないと思います。次回は、実際にokuyamaを動かして、その機能を知ってもらおうと思います。