2010/08/26

Summary of "Cassandra" for 3rd nosql summer reading in Tokyo

第3回目となる"nosql summer reading in Tokyo"の論文は、最近注目を集めているCassandraをとりあげました。Cassandraは、以前ご紹介したGoogleのBigTableとAmazonのDynamoの良いところを合わせたと言われているとおり、論文からもそれを伺い知ることができます。

たとえば、分散されたノード間に主従関係を作らず、Gossipプロトコルにより、サーバー相互間で連絡をしあい、あるサーバーに障害が起きていないかと監視するという優れたメカニズムが実装されています。

また、SQL以外という意味で幅広いNo-SQLという分野においてコラム指向と分類されるように、キーに紐づくひとつのrow(行)に対して、いくつにでも増やせるという複数のコラムを持つことができます。そして、そのコラムはコラムファミリーとして、複数のコラムのグループをつくることもできます。このようなコラムのグループを作ることにより、検索を容易に行うことができるというメリットを得ることができます。

そして、この論文には言及されていませんが、データの一貫性(Consistency)のレベルを設定できるという点にもメリットがあります。たとえば、一貫性(Consistency)のレベルを、ゼロと設定すると、データの一貫性を全く確認することなく、書き込み/読み出しを実行します。以前にもご紹介した「Eventual Consistency(結果整合性)」を受け入れることができるアプリケーションの場合には、このトレードオフとして良いレイテンシーを得ることができるはずです。逆に、書き込むノードの数と読み出すサーバーの数の合計が、レプリカ(複製)する数よりも多いQUORUMに設定すれば、「強い一貫性(Strong Consistency)」を得ることもできます。この設定は、クライアント側で、書き込み/読み出しの都度設定します。

Hibariは、この人気が高いCassandraのAPIを利用できるように準備をしているところです。Hibariの場合は、Cassandraのようなコラムを複数持つデータモデルではなく、キーとバリューが対となるキー・バリュー型に分類されます。そのため、複数のコラムを持つCassandraのアプリケーションがHibariを利用する際に、複数のコラムファミリーでグループ化されたコラムを、ひとつひとつのコラムとします。また、HibariはChain Replicationにより「強い一貫性(Strong Consistency)」を保証するように設計されていますので、Cassandraのクライアント側で設定する一貫性(Consistency)のレベルに関する情報は必要が無くなります。

このように、HibariでCassandraのAPIを利用するためには、いくつかの仕組みを用意する必要はありますが、「書き込みを重視するCassandra」と「読み出しを重視するHibari」というように、それぞれの持ち味が異なります。

やがて、数多くのNoSQLのシステムに対する理解が深まり、その特徴が明確になり始めれば、アプリケーションのニーズに応じて、それぞれの特徴にあったシステムを選び使い分けることができるようになると考えています。