Cassandraの制約

変わりそうもないこと

• 一つの行に含まれるデータはクラスタの一つのノードのディスクに収まる大きさでなければなりません。行キーはその行をレプリケートするノードを決定します。このためある単一のキーに関連づけられるデータはこの上限に制限されます。
• 単一の列のデータは2GBを超えることはできません。
• 一つの行に収納可能なカラムの最大個数は20億です。
• 行キーおよびカラム名は64Kbyte以下でなければなりません。

現在のコードベースに基づく制約

• Cassandraは二つのレベルのインデックスを持ちます。即ちキーとカラムです。しかしスーパーカラムファミリには第三のレベル、サブカラムが存在します。サブカラムはインデックス化されていないため、サブカラムに対する要求はスーパーカラムに含まれるすべてのサブカラムをシリアライズされた状態から復元（デシリアライズ）します。これを理解すれば、大量のサブカラムを必要とするようなデータモデルは避けたくなるでしょう。この制約を取り除くために https://issues.apache.org/jira/browse/CASSANDRA-598 が作成されています。

• Cassandraの公開APIはThriftベースであり、ストリーミング機能を持ちません。このため書き込むデータ、読み出すデータはすべてメモリに収まらなければなりません。これはThriftのデザインに起因しており、変更は困難です。Cassandraにラージオブジェクトのサポートを追加するには、ラージオブジェクトを分割して処理するような特別のAPIが必要になるでしょう。一つのアプローチが http://issues.apache.org/jira/browse/CASSANDRA-265 で解説されています。現時点でのワークアラウンドとしては、巨大なデータをマニュアルで適当なサイズ（少なくともある人は64MBを選択しています）のチャンクに分割することが考えられます。データチャンクをカラムの値として使用し、行でラージオブジェクトを表現するわけです。

解消された制約

• 0.7より前のバージョンでは、CassandraのCompactionコードはカラムファミリごとに一度に行全体をデシリアライズしていました。このため指定されたカラムファミリのすべてのデータとキーのペアはメモリ内あるいは2GB（行の長さがJava intとしてシリアライズされていたため）のいずれか小さい値に収まる必要がありました。
• 0.7より前のバージョンでは、Thriftでランダムなデータや異常なデータを送るとCassandraがクラッシュする場合がありました。このため、Cassandraのアクセスポートを直接Internetに公開するのは賢明ではありませんでした。
• 0.4より前のバージョンでは、Cassandraはwrite ackを返す前にcommit logをsyncしていませんでした。複数のレプリカに書き込みを行う場合、すべてのレプリカがデータをディスクに保存する前にクラッシュする可能性は非常に低いため、ほとんどの場合は問題がありません。しかし真性のパラノイアなら、write ackの前にfsyncをすることを期待するでしょう。0.4以降では fsync before ack はオプションとして提供されています。