Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "FAQ_JP" page has been changed by MakiWatanabe. The comment on this change is: Translate large_file_and_blob_storage. http://wiki.apache.org/cassandra/FAQ_JP?action=diff&rev1=67&rev2=68 -------------------------------------------------- <<Anchor(large_file_and_blob_storage)>> == Cassandraで巨大なファイルやBLOBを保存できますか? == - Currently Cassandra isn't optimized specifically for large file or BLOB storage. However, files of around 64Mb and smaller can be easily stored in the database without splitting them into smaller chunks. This is primarily due to the fact that Cassandra's public API is based on Thrift, which offers no streaming abilities; any value written or fetched has to fit in to memory. Other non Thrift interfaces may solve this problem in the future, but there are currently no plans to change Thrift's behavior. When planning applications that require storing BLOBS, you should also consider these attributes of Cassandra as well: + 現在のCassandraは巨大なファイルやBlobストレージとしては最適化されていません。しかし64MB前後のファイルまでであれば分割することなく容易に格納できます。これは主にCassandraが公式APIとして使用しているThriftに起因する制約事項です。Thriftではストリーミング機能が提供されていないため、write/readされるデータはメモリに収まらなければなりません。havior. + Cassandraが将来Thrift以外のインターフェースをサポートすればこの問題を解決するかもしれませんが、今のところThrift自体の挙動を変更する計画はありません。Blobを格納するようなアプリケーションを設計する場合、以下のCassandraの特性にも注意して下さい。 - * The main limitation on a column and super column size is that all the data for a single key and column must fit (on disk) on a single machine(node) in the cluster. Because 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. This is an inherent limitation of the distribution model. + * 特定のキーとカラムに含まれるデータは単一ノードのディスクに収まらなければなりません。これがカラムやスーパーカラムの大きさに関する主要な制限になります。キーはレプリカ先のノードを決定するために使用されるため、特定のキーにひもづけられたデータは格納先ノードのストレージサイズによって規定されます。これはCassandraの分散モデルから派生する制限事項です。 - * When large columns are created and retrieved, that columns data is loaded into RAM which can get resource intensive quickly. Consider, loading 200 rows with columns that store 10Mb image files each into RAM. That small result set would consume about 2Gb of RAM. Clearly as more and more large columns are loaded, RAM would start to get consumed quickly. This can be worked around, but will take some upfront planning and testing to get a workable solution for most applications. You can find more information regarding this behavior here: [[MemtableThresholds|memtables]], and a possible solution in 0.7 here: [[https://issues.apache.org/jira/browse/CASSANDRA-16|CASSANDRA-16]]. + * 巨大なカラムを作成したり、読み出したりする場合、カラムのデータはRAMに読み込まれます。このようなケースでは容易にリソース集約的になりがちです。例えばそれぞれ10MBの画像ファイルを格納したカラムを含む行を200行RAMにロードすると小計2GBのRAMを使用することになります。ロードする行数が増えれば増えるほど、RAMの消費は急激に増加します。これを回避することは可能ですが、多くのアプリケーションで有効な解決方法を見いだすには事前の設計と試験が必要です。この挙動に関する情報については[[MemtableThresholds|memtables]]を参照して下さい。また0.7で使用可能な対策については次のリンクを参照してください。 [[https://issues.apache.org/jira/browse/CASSANDRA-16|CASSANDRA-16]] + * 更なる情報については[[CassandraLimitations|Cassandra Limitations]]を参照して下さい。 - * Please refer to the notes in the Cassandra limitations section for more information: [[CassandraLimitations|Cassandra Limitations]] - - 現状のCassandraは巨大なファイルやBLOBに特化した最適化は行われていませんが，対処方法はあります． - * [[CassandraLimitations_JP|Cassandraの制限]]で詳細を確認してください． <<Anchor(jmx_localhost_refused)>>
