[Cassandra Wiki] Update of "CassandraLimitations_JP" by MakiWatanabe

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "CassandraLimitations_JP" page has been changed by MakiWatanabe.
http://wiki.apache.org/cassandra/CassandraLimitations_JP?action=diff&rev1=27&rev2=28

--------------------------------------------------

  ## page was copied from CassandraLimitations
- = Limitations =
  
+ = 制約 =
- == Stuff that isn't likely to change ==
-  * All data for a single row must fit (on disk) on a single machine in the cluster. Because row keys alone are used to determine the nodes responsible for replicating their data, the amount of data associated with a single key has this upper bound.
-  * A single column value may not be larger than 2GB.
  
+ == 変わりそうもないこと ==
- == Artifacts of the current code base ==
-  * Cassandra has two levels of indexes: key and column.  But in super columnfamilies there is a third level of subcolumns; these are not indexed, and any request for a subcolumn deserializes _all_ the subcolumns in that supercolumn.  So you want to avoid a data model that requires large numbers of subcolumns.  https://issues.apache.org/jira/browse/CASSANDRA-598 is open to remove this limitation.
-  * <<Anchor(streaming)>>Cassandra's public API is based on Thrift, which offers no streaming abilities -- any value written or fetched has to fit in memory.  This is inherent to Thrift's design and is therefore unlikely to change.  So adding large object support to Cassandra would need a special API that manually split the large objects up into pieces. A potential approach is described in http://issues.apache.org/jira/browse/CASSANDRA-265.  As a workaround in the meantime, you can manually split files into chunks of whatever size you are comfortable with -- at least one person is using 64MB -- and making a file correspond to a row, with the chunks as column values.
  
+  * 一つの行に含まれるデータはクラスタの一つのノードのディスクに収まる大きさでなければなりません。行キーはその行をレプリケートするノードを決定します。このためある単一のキーに関連づけられるデータはこの上限に制限されます。
+  * 単一の列のデータは2GBを超えることはできません。
- == Obsolete Limitations ==
-  * Prior to version 0.7, Cassandra's compaction code deserialized an entire row (per columnfamily) at a time.  So all the data from a given columnfamily/key pair had to fit in memory, or 2GB, whichever was smaller (since the length of the row was serialized as a Java int).
-  * Prior to version 0.7, Thrift would crash Cassandra if you send random or malicious data to it.  This made exposing the Cassandra port directly to the outside internet a Bad Idea.
-  * Prior to version 0.4, Cassandra did not fsync the commitlog before acking a write.  Most of the time this is Good Enough when you are writing to multiple replicas since the odds are slim of all replicas dying before the data actually hits the disk, but the truly paranoid will want real fsync-before-ack.  This is now an option.
  
+ == 現在のコードベースに基づく制約 ==
+ 
+  * Cassandraは二つのレベルのインデックスを持ちます。即ちキーとカラムです。しかしスーパーカラムファミリには第三のレベル、サブカラムが存在します。サブカラムはインデックス化されていないため、サブカラムに対する要求はスーパーカラムに含まれる'''すべての'''サブカラムをシリアライズされた状態から復元（デシリアライズ）します。これを理解すれば、大量のサブカラムを必要とするようなデータモデルは避けたくなるでしょう。この制約を取り除くために https://issues.apache.org/jira/browse/CASSANDRA-598 が作成されています。
+ 
+  * <<Anchor(streaming)>>Cassandraの公開APIはThriftベースであり、ストリーミング機能を持ちません。このため書き込むデータ、読み出すデータはすべてメモリに収まらなければなりません。これはThriftのデザインに起因しており、変更は困難です。Cassandraにラージオブジェクトのサポートを追加するには、ラージオブジェクトを分割して処理するような特別のAPIが必要になるでしょう。一つのアプローチが http://issues.apache.org/jira/browse/CASSANDRA-265 で解説されています。現時点でのワークアラウンドとしては、巨大なデータをマニュアルで適当なサイズ（少なくともある人は64MBを選択しています）のチャンクに分割することが考えられます。データチャンクをカラムの値として使用し、行でラージオブジェクトを表現するわけです。
+ 
+ == 解消された制約 ==
+ 
+  * バージョン0.6以前は、Cassandraのデータ圧縮コードはカラムファミリごとに一度に行全体をデシリアライズしていました。このため指定されたカラムファミリのすべてのデータとキーのペアはメモリ内あるいは2GB（行の長さがJava intとしてシリアライズされていたため）のいずれか小さい値に収まる必要がありました。
+ 
+  * バージョン0.6以前は、Thriftでランダムなデータや異常なデータを送るとCassandraがクラッシュする場合がありました。このため、Cassandraのアクセスポートを直接Internetに公開するのは賢明ではありませんでした。
+ 
+  * バージョン0.3以前は、Cassandraはwrite aceを返す前にcommit logをsyncしていませんでした。複数のレプリカに書き込みを行う場合、すべてのレプリカがデータをディスクに保存する前にクラッシュする可能性は非常に低いため、ほとんどの場合は問題がありません。しかし真性のパラノイアなら、write ackの前にfsyncをすることを期待するでしょう。現在 fsync before ack はオプションとして提供されています。
+