ビッグデータ[注]という新しい分野において、Bigtableデータベース技術は非常に注目されています。この技術に詳しい方は、CassandraとHBaseという2つのApacheデータベースプロジェクトをご存知で、よくご存じでしょう。
Googleは、2006年の調査報告書***でBigtableについて説明しています。興味深いことに、このレポートでは、Bigtableをデータベース技術としてではなく、バイトサイズのデータを格納し、商用ハードウェア上で実行するための「疎分散多次元」マッピング技術として説明していました。行はまず非常にユニークな方法でインデックス付けされ、次にBigtableは行キーを使ってデータを分割し、クラスタに分散します。カラムは行で素早く定義できるため、Bigtableはほとんどの非スキーマ環境に適しています。
CassandraもHBaseも、以前のBigtableの定義から大きく借用しています。実際、CassandraのルーツはBigtableとAmazonのDynamo技術であり、HBaseは自らを「オープンソースのBigtableツール」と位置付けています。それ自体、2つのプロジェクトは多くの同じ特徴を共有していますが、同時に多くの重要な違いがあります。
ビッグデータ対応
CassandraとHBaseはどちらもNoSQLデータベースです。一般的に、これはユーザーがSQLデータベースにアクセスできないことを意味します。ただし、CassandraはCQLを使用しており、これは明らかにSQLを模倣した構文を持っています。
どちらも非常に大きなデータセットを管理するように設計されています。HBaseのドキュメントでは、HBaseデータベースは数十億行とは言わないまでも、数億行を持つことができると主張しています。また、ユーザーはリレーショナルデータベースを使い続けることをお勧めします。
どちらも分散データベースであり、データの保存方法だけでなく、アクセス方法も同じです。クライアントはクラスタ内のどのノードにも接続でき、どのデータにもアクセスできます。
どちらもほぼ直線的なスケーラビリティを謳っています。2倍のサイズのデータを管理したいですか？クラスタ内のノードを2倍に拡張するだけです。
クラスタノードの障害によるデータ損失を防ぐため、両方ともレプリケートされます。1つのクラスタノードがデータベースに書き込まれる行を担当します。その後、データは冗長ノードと呼ばれる他のクラスタメンバーにイメージ化されます。プライマリ・ノードに障害が発生しても、他の冗長ノードからデータを読み取ることができます。
どちらもカラム型データベースと呼ばれています。その名前がリレーショナル・データベースのように聞こえるため、ユーザーはそれらにアプローチする際に精神的な調整を行う必要があり、それが認識の混乱につながります。最も混乱しやすい点は、データが最初に表面上の行ごとに配列され、テーブルの主キーが行キーであることです。しかし、リレーショナルデータベースとは異なり、カラム型データベースでは、2つの行が同じカラムを必要としません。前述したように、ユーザはテーブルが作成された後、行にカラムを素早く追加することができます。実際、1つの行に多くのカラムを追加することができます。上限を正確に計算することは困難ですが、ユーザが多くの列を追加しても、そのような上限に達することはほとんど不可能です。
Bigtableの定義に由来するこれらの機能に加えて、CassandraとHBaseには他にもいくつかの類似点があります。
まず、どちらも同じような書き込みパスを使用します。つまり、書き込み操作が最初にログファイルに記録され、永続性が確保されます。書き込みに失敗しても、ログに記録された操作は再開できます。その後、データはメモリ内キャッシュに書き込まれます。***CassandraとHBaseで使用されるメモリとディスクのデータ構造は、ある程度、ログ構造のマージ・ツリーです。Cassandraのディスク・コンポーネントはSSTableで、HBaseのディスク・コンポーネントはHFileです。
どちらもJRuby言語用のコマンドラインシェルを提供します。他の多くのプログラミング言語用のクライアントパッケージもありますが、どちらもアクセスするための主要なプログラミング言語であるJava言語を使って書かれています。
もちろん、CassandraとHBaseはどちらもApache Software Foundationが管理するオープンソース・プロジェクトであり、Apache License version 2.0の下で無料で利用できます。
類似点と相違点
多くの類似点があるにもかかわらず、両者には多くの大きな違いがあります。
CassandraとHBaseのノードは対称的であり、クライアントはクラスター内のどのノードにも接続できますが、この対称性は不完全です。Cassandraでは、一部のノードをシード・ノードとして機能させ、クラスター間通信のセットポイントの役割を担わせる必要があります。HBaseでは、ユーザーは一部のノードをマスター・ノードとして機能させる必要があり、その機能はリージョナル・サーバーのアクションを監視して調整することです。高可用性を確保するために、Cassandraはクラスタ内で複数のシード・ノードを許可するアプローチを取ります。HBaseは、現在のマスター・ノードに障害が発生した場合に新しいマスター・ノードとなるバックアップ・マスター・ノードを使用します。
Cassandraはノード間通信にGossipプロトコルを使用します。Gossipサービスは現在Cassandraソフトウェアに統合されており、HBaseは対応するタスクを処理するために完全に独立した分散アプリケーションであるZookeeperに依存しています。HBaseにはZookeeperが同梱されていますが、ユーザはしばしばHBaseデータベースにあらかじめ組み込まれたZookeeperを使用します。
CassandraもHBaseもリアルタイムのトランザクション制御をサポートしていませんが、どちらもある程度の一貫性制御を提供しています。実際、HBaseは行単位でACIDレベルのセマンティクスをサポートしています。ユーザはHBaseの行をロックすることができますが、この動作は並行性に影響を与えるだけでなく、行のロックにより領域分割操作が不可能になるため推奨されません。さらに、HBaseは "check and write "オペレーションを実行することができます。
無償のDataStax Community Edition for Cassandraには、DataStax Operations Centreが含まれています。このセンターはクラスターの監視および管理機能を提供し、データベース・スキーマの検出、キースペースの編集の可否、カラム・ファミリーの追加または削除の可否を示します。
Cassandraは「***」一貫性を持つと説明されていますが、読み取りと書き込みの一貫性はレベルとゾーンで調整できます。つまり、操作を正常に完了する必要がある冗長ノードの数を設定できるだけでなく、参加する冗長ノードがデータ・センターにまたがるかどうかも設定できます。
Cassandraの軽量トランザクションは、HBaseの「check and write」機能と同等の「compare and set」メカニズムを使用します。HBaseの「check and write」機能は同等です。ただし、HBaseの「read-modify-write」操作については、Cassandraには対応する機能がありません。最終的に、Cassandraバージョン2.0では、別の行レベル書き込み機能が追加されました。クライアントが行の複数の列を更新した場合、他のクライアントは更新されていないすべての部分、または更新されたすべての部分を見ることになります。
前述のとおり、どちらのデータベースにもデータ操作コマンドを発行するためのコマンド・ライン・シェルがあります。HBaseシェルもCassandraシェルもJRubyシェルに基づいているため、ユーザーがJRubyシェルのすべてのリソースを呼び出してデータベースが提供する特定のAPIと対話するスクリプトを書くことができます。さらに、CassandraはSQLを模倣したCQLを定義しており、HBaseで使用されるクエリー言語よりも機能が豊富で、Cassandraシェル内から直接実行できます。
CassandraはまだThrift APIをサポートしていますが、Cassandraは実際にCQLをデータベースの主要な編集インターフェイスにすることを推進しており、CassandraのドキュメントにはCQLバージョン3を使用するJava、C#、Python用のドライバが多数含まれています。最終的には、Cassandra用のJDBCドライバーが利用可能になる予定です。このドライバーは、データ定義およびデータ管理言語としてSQLをCQLに置き換えます。
HBaseはThriftインターフェイスやRESTful Web Servicesインターフェイスもサポートしていますが、HBaseのネイティブJava APIはプログラマに豊富な機能を提供します。HBaseのデータ操作コマンドはCQLほど豊富ではありませんが、HBaseにはセッションのサーバー側で実行できる「フィルター」機能があり、スキャンのスループットを劇的に向上させます。
HBaseは「コプロセッサ」という概念も導入しており、ユーザーコードをHBaseプロセス内で実行できるようにしています。これは基本的にリレーショナル・データベースのトリガー・プロセスとステージング・プロセスと同じです。現在のところ、CassandraにはHBaseコプロセッサのようなものはありません。
CassandraのドキュメントはHBaseよりも目を引き、学習曲線はより平坦です。開発用にCassandraクラスターをセットアップするのは、HBaseクラスターをセットアップするよりも簡単です。もちろん、これは開発およびテスト目的でのみ重要です。
アタッチメント HBaseマスターノードはポート60010でウェブインターフェースをホストしています。ユーザはノードの実行履歴、ノードが管理するテーブル、マスターノードのドメイン内のリージョナルサーバなどの情報を閲覧することができます。
トラブルスポット
特定のアプリケーション用にクラスタをチューニングする必要がある場合、ユーザはいくつかの作業を行う必要があります。データセットのサイズを指定し、マルチノードクラスタの作成と管理の複雑さを考慮すると、チューニングは厄介なものになります。クラスタのメモリキャッシュ、ディスクストレージ、およびノード間通信がどのように相互作用するかを深く理解し、クラスタのアクティビティを注意深く監視する必要があります。
HBaseはZookeeperに依存しているため、障害点がいくつか追加されます。Cassandraはこの問題を回避していますが、Cassandraクラスターのチューニングの難易度が大幅に低下したわけではありません。2つのデータベースのクラスター調整の難易度を比較しました。
ここで注意しなければならないのは、誰が勝者で誰が敗者であるかという決定権はないということです。各データベースの支持者は、自分たちのシステムが他よりも優れているという証拠を見つけるでしょう。通常、ユーザーはターゲットアプリケーションの性能を判断する前に、両方のデータベースをテストする必要があります。では、技術的な見地からもっと良い方法はないのでしょうか？
