カラム指向型データベース（HBase、Hypertable、Cassandra）編：知らないなんて言えないNoSQLまとめ（3）（3/3 ページ）
カラム（列）指向データベースは大量データ分析などのニーズが増えていることから、注目を集めつつあります。ここで、ざっと各プロダクトごとの特徴をおさらいしておきましょう。
カラム指向のP2P型データストア
Facebookが開発したApache Cassandra
Apache Cassandra（以下Cassandra）は、FacebookのIn-Boxサーチのために開発され、オープンソースとしてリリースされました。「Dynamoの完全な分散設計と、Bigtableのカラムファミリ型データモデルが一緒になった」と説明されています。Cassandraの技術概要は書籍第3章の解説を参照いただくとして、ここではGoogle BigtableやAmazon Dynamoとの特に大きな相違点を説明します。
調節可能な整合性レベル
CassandraはDynamoと同じく、基本的には結果整合性を前提としていますが、VoldemortやRiakのように「整合性レベルの調節が可能」になっています。Cassandraでは表1、2のように、書き込みと読み出しの整合性レベルを個別に調節できるようになっています。
例えば、強い整合性を必要とするアプリケーションでは、書き込みの設定をALLとすることにより、読み出しデータに不整合が生じないようにできます。ただし、応答性能とのトレードオフがあるので、書き込みを速くしたいアプリケーションでは、Quorum（R＋W＞N）の考え方に基づく調節を行います。例えば、複製の数（N）を3、書き込みの数（R）を2、読み出しの数（W）を2に設定するなどです。
| 設定レベル | 動作 |
|---|---|
| ANY | 少なくとも1つのノードに書き込まれる（ヒンテッド･ハンドオフ*10を受ける側を含んでもよい） |
| ONE | クライアントへの応答前に、少なくとも1つのレプリカのCommit LogとMemtableに書き込まれる |
| QUORUM | クライアントへの応答前に、N/2＋1のレプリカに必ず書き込まれる。 |
| EACH_QUORUM | Quorumと同様。ただしレプリカは、コーディネータノードと同じデータセンターに置かれる |
| LOCAL_QUORUM | クライアントへの応答前に、クラスタ内の各データセンターにある定足数のレプリカに必ず書き込まれる |
| ALL | 全てのレプリカが書き込みを受け取る。その条件を満たせない場合、オペレーションは失敗となる |
*10 ヒンテッド・ハンドオフ ノード間のデータ複製を実行する際に、複製先のノードがダウンしている場合でも、別のノードに対して指示を与える（ノードが回復したら複製する）ことで、データの整合性を保証する方式のこと。
| 設定レベル | 動作 |
|---|---|
| ONE | 最初のレプリカから応答を返し、バックグラウンド・スレッドで一貫性のチェックを行う |
| QUORUM | 過半数のレプリカ（N/2＋1）からの応答の後、最新のタイムスタンプを持つレコードを返す |
| LOCAL_QUORUM | コーディネータに近いデータセンターにある定足数のレプリカから応答の後、最新のタイムスタンプを持つレコードを返す |
| EACH_QUORUM | クラスタ内の各データセンターにある定足数のレプリカから応答の後、最新のタイムスタンプを持つレコードを返す |
| ALL | 全てのレプリカからの応答の後、最新のタイムスタンプを持つレコードを返す |
書き込み性能に最適化
Cassandraではデータの保存に、Bigtable系のNoSQLデータベースに見られるLSM-Treeを採用したことで、他のDynamo系よりも高い書き込み性能を実現しています。また、Dynamo系が持っている調整可能な整合性レベルを採用しているので、ノード障害やネットワーク分断の発生時でも、整合性レベルを下げることで読み書きを継続できます。
Cassandraは、同じカラム指向型のHBaseとよく比較されます。両者の違いはCAP定理に沿って比較すると理解しやすいでしょう。HBaseはCAP定理のCPを採用し、CassandraはAPを採用しています。そのためHBaseでは、ノード障害時のフェイルオーバー動作中に読み書きが待たされますが、Cassandraにはそれがありません。その一方で、HBaseが持つCAS操作やインクリメント操作は、結果整合性を基本とするCassandraでは実現できません。このような特徴から、Cassandraは高い書き込み性能が要求され、整合性よりも可用性が重視されるアプリケーションに適しています。
複数のデータセンターに複製
Cassandraのデータ分割では、ノードを論理的にリング状に配置し、コンシステント・ハッシングによってコーディネイターノードを選び、どのノードにデータを複製するかを決めます。その際、RackUnawareStrategy（ラック非認識戦略）とRackAwareStrategy（ラック認識戦略）という2つの設定パラメータがあります。このRackAwareStrategyを使うと、例えば、複製の2番目を別のデータセンターに配置するといったことを指定できます。
DataStaxからエンタープライズ版を提供
Cassandraの商用サポートを提供するDataStaxでは、DataStax EnterpriseというCassandraの商用パッケージ版を提供しています。このパッケージには、Webベースのインターフェイスを備えた管理ツールや、HadoopのHDFSを置き換えるCassandraFSが含まれています。
バージョン管理にはタイムスタンプ
CassandraはDynamoの影響を受けた他のNOSQLデータベースとは異なり、バージョン管理にベクタークロックを用いず、タイムスタンプを用います。システム内の複製に複数のバージョンが生じた場合、タイムスタンプが新しいバージョンを選ぶことで、バージョン間の差異を仲裁します。運用時には、クライアントのタイムスタンプが常にクラスタ内のサーバと同期を保つよう、十分に配慮する必要があります。さもないと、古いバージョンが上書きされてしまうといったことが起こる可能性があるからです。
初出情報
本連載で抜粋・紹介している原稿の初出は下記書籍です。本連載では詳述していないNoSQLの基本的な考え方、アーキテクチャの詳細などは、書籍でご確認ください。
『NOSQLの基礎知識』
- 【著】 本橋信也、河野達也、鶴見利章
- 【監修】太田洋
- 【発行】リックテレコム
- 【ISBN】978-4-89797-887-1
本書はクラウディアン（旧ジェミナイ・モバイル・テクノロジーズ）の技術者らが監修および執筆を行っています。同社は、国産NOSQL「HIBARI」を開発、その後、Cassandraに自社の「HyperStore」を実装したクラウドストレージ用パッケージソフトウェア「Cloudian」を開発して、現在商用提供を行っているITベンチャー企業です。
Copyright © ITmedia, Inc. All Rights Reserved.