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 shot6. http://wiki.apache.org/cassandra/FAQ_JP?action=diff&rev1=54&rev2=55 -------------------------------------------------- <<Anchor(i_deleted_what_gives)>> == Cassandraからデータを削除したのにディスク使用量は同じです.何が起こってるのでしょうか? == - Cassandraに書き込まれたデータは[[MemtableSSTable_JP|SSTables]]に書き込まれます．SSTablesはイミュータブルで、データ削除を実行してもマーカー(tombstoneといいます)が書き込まれるだけで実際には削除されません．でも大丈夫．GCGraceSeconds後の最初のコンパクションでデータは完璧に抹消され、ディスクスペースはそのときに軽減されます．詳しくは[[DistributedDeletes_JP|DistributedDeletes]]を参照してください． + Cassandraに書き込まれたデータは[[MemtableSSTable_JP|SSTables]]に書き込まれます． + + SSTablesはイミュータブルで、データ削除を実行してもマーカー(tombstoneといいます)が書き込まれるだけで実際には削除されません．でも大丈夫．GCGraceSeconds後の最初のコンパクションでデータは完璧に抹消され、ディスクスペースはそのときに軽減されます． + + 詳しくは[[DistributedDeletes_JP|DistributedDeletes]]を参照してください． <<Anchor(reads_slower_writes)>> + == 何故書き込みより読み込みのほうが遅いのでしょうか? == - == Why are reads slower than writes? == - Unlike all major relational databases and some NoSQL systems, Cassandra does not use b-trees and in-place updates on disk. Instead, it uses a sstable/memtable model like Bigtable's: writes to each ColumnFamily are grouped together in an in-memory structure before being flushed (sorted and written to disk). This means that writes cost no random I/O, compared to a b-tree system which not only has to seek to the data location to overwrite, but also may have to seek to read different levels of the index if it outgrows disk cache! - The downside is that on a read, Cassandra has to (potentially) merge row fragments from multiple sstables on disk. We think this is a tradeoff worth making, first because scaling writes has always been harder than scaling reads, and second because as your data corpus grows Cassandra's read disadvantage narrows vs b-tree systems that have to do multiple seeks against a large index. See MemtableSSTable for more details. + メジャーなRDBMSやNoSQLシステムと違い、Cassandraはb-treeやin-placeアップデータを使っていません． + その代わりに、BigTableと同じようにsstable/memtableモデルを採用しています：ソートしディスクに書き込む前にメモリ上の構造に各カラムファミリをグループ化して書き出します．どういうことかというと、このやり方だとb-treeのようにデータを上書きするためにシークしたりディスクキャッシュ上に溜まりにたまったインデックスからシークしたりせず、書き込みでランダムIOが発生しないということです． + + + この方式の弱点としては、読み込みで複数のSSTablesから読み込んでマージしなくてはいけなくなる可能性があるということです． + これは十分に検討できるトレードオフだと私たちは考えています． + その理由として、 + 1. スケールする書き込みは常にスケールする読み込みよりも難しい + 1. データの集合体が増加するにつれ、Cassandraの読み込みの弱点は弱まってくる(b-tree形式の巨大なインデックスのシークに比べて) + + 詳細は[[MemtableSSTable_JP|MemtableSSTable]]をご覧ください． + + <<Anchor(cloned)>> + == |各ノード間でジョインしたとログが残っているのにnodeprobe ringは何故1つのエントリしか見えないのでしょうか? == - == Why does nodeprobe ring only show one entry, even though my nodes logged that they see each other joining the ring? == - This happens when you have the same token assigned to each node. Don't do that. - Most often this bites people who deploy by installing Cassandra on a VM (especially when using the Debian package, which auto-starts Cassandra after installation, thus generating and saving a token), then cloning that VM to other nodes. + この現象は各ノードに同じトークンを割り当てたときに起こります．基本的にそのようなことはしないでください． - The easiest fix is to wipe the data and commitlog directories, thus making sure that each node will generate a random token on the next restart. + + この現象はCassandraを仮想マシン(Debianパッケージ、自動的にCassandraインストール後に起動、トークンの生成と保存を行う)を使って、そのVMをコピーした場合に発生します． + + + もっとも簡単な対処方法はデータとコミットログをクリアすると、各ノードは次のリスタート時にランダムなトークンを生成します． + + <<Anchor(range_ghosts)>> - == Why do deleted keys show up during range scans? == + == レンジスキャンで削除したはずのキーが残っているのは何でですか? == + + Because get_range_slice says, "apply this predicate to the range of rows given," meaning, if the predicate result is empty, we have to include an empty result for that row key. It is perfectly valid to perform such a query returning empty column lists for some or all keys, even if no deletions have been performed. So to special case leaving out result entries for deletions, we would have to check the entire rest of the row to make sure there is no undeleted data anywhere else either (in which case leaving the key out would be an error). @@ -213, +235 @@ This is what we used to do with the old get_key_range method, but the performance hit turned out to be unacceptable. <<Anchor(change_replication)>> - == Can I change the ReplicationFactor on a live cluster? == + == 動いているCassandra上でReplicationFactorを変更することは出来ますか? == Yes, but it will require restarting and running repair manually to change the replica count of existing data. * Alter the ReplicationFactor for the desired keyspace(s) in the storage configuration on each node in the cluster. @@ -226, +248 @@ * Run "nodetool repair" to run an anti-entropy repair on the cluster. This is an intensive process so may result in adverse cluster performance. <<Anchor(large_file_and_blob_storage)>> + == Cassandraで巨大なファイルやBLOBを保存できますか? == - == Can I Store BLOBs in Cassandra? == - Currently Cassandra isn't optimized specifically for large file or BLOB storage, however there are ways to work around this. - * Please refer to the notes in the Cassandra limitations section for more information: [[CassandraLimitations|Cassandra Limitations]] + 現状のCassandraは巨大なファイルやBLOBに特化した最適化は行われていませんが、対処方法はあります． + * [[CassandraLimitations|Cassandraの制限]]で詳細を確認してください． +
