cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cassandra Wiki] Update of "MemtableSSTable_JP" by yukim
Date Thu, 01 Apr 2010 13:21:35 GMT
Dear Wiki user,

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

The "MemtableSSTable_JP" page has been changed by yukim.


  ## page was copied from MemtableSSTable
- Cassandra writes are first written to the !CommitLog, and then to a per-!ColumnFamily structure
called a Memtable.  A Memtable is basically a write-back cache of data rows that can be looked
up by key -- that is, unlike a write-through cache, writes are batched up in the Memtable
until it is full, before being written to disk as an SSTable.
+ Cassandraの書き込みはまずコミットログ(!CommitLog)に対して行われます。そして!ColumnFamilyごとにMemtableと呼ばれる構造体に対して書き込まれます。Memtableは基本的にキーで参照可能なデータ行のライトバックキャッシュです。つまりライトスルーキャッシュと違ってSSTableとしてディスクに書き込まれる前に、Memtableが一杯になるまで書き込まれます。
- The process of turning a Memtable into a SSTable is called flushing.  You can manually trigger
flush via jmx (e.g. with bin/nodetool), which you may want to do before restarting nodes since
it will reduce !CommitLog replay time.  Memtables are sorted by key and then written out sequentially.
+ MemtableをSSTableへ変換するプロセスをフラッシュ(flushing)と呼びます。JMX経由で(例えばnodetoolを使用して)手動でフラッシュを実行することも可能です。コミットログのリプレイ時間を短くするためにノードを再起動する前に行った方が良いでしょう。Memtableはキーでソートされ、シーケンシャルに書き出されます。
- Thus, writes are extremely fast, costing only a commitlog append and an amortized sequential
write for the flush!
+ したがって書き込みは超高速に行われます。コミットログへの追記とフラッシュ時のシーケンシャルな書き込みしかコストがかかっていません!
- Once flushed, SSTable files are immutable; no further writes may be done.  So, on the read
path, the server must (potentially, although it uses tricks like bloom filters to avoid doing
so unnecessarily) combine row fragments from all the SSTables on disk, as well as any unflushed
Memtables, to produce the requested data.
+ 一旦フラッシュされると、SSTableのファイルは変更不可能になります。それ以上の書き込みはできません。したがって読み込み時には、要求されたデータを生成するためにサーバーは(潜在的にはブルームフィルタなどのトリックを使用して余計な読み込みは回避しているのですが)すべてのディスク上のSSTableとまだフラッシュされていないMemtableから行の断片を組み合わせる必要があります。
- To bound the number of SSTable files that must be consulted on reads, and to reclaim [[DistributedDeletes|space
taken by unused data]], Cassandra performs compactions: merging multiple old SSTable files
into a single new one. Compactations are triggered when at least 4 SStables has been flushed
to disk. Since the input SSTables are all sorted by key, merging can be done efficiently,
still requiring no random i/o.  Once compaction is finished, the old SSTable files may be
deleted: note that in the worst case (a workload consisting of no overwrites or deletes) this
will temporarily require 2x your existing on-disk space used.  In today's world of multi-TB
disks this is usually not a problem but it is good to keep in mind when you are setting alert
+ 読み込む必要があるSSTableファイルの数を制限するため、また[[DistributedDeletes|使用されていないデータによって埋められているスペース]]を取り戻すために、Cassandraはコンパクションを行います。コンパクションとは複数の古いSSTableファイルをひとつの新しいファイルにマージすることです。コンパクションは少なくとも4つのSSTableがディスクにフラッシュされた場合に実行されます。入力元となるSSTableはすべてキーでソートされているため、マージは効率良く行われランダムI/Oを必要としません。コンパクションが終了すると古いSSTableファイルは削除されます。注意点としては、最悪の場合(上書きや削除がないデータで構成されている場合)今使用している容量の倍のディスク容量が一時的に必要になります。数TBのディスクが主流の現在はあまり問題になりませんが、警告のための閾値を設定する場合には注意しておくと良いでしょう。
- (The high-level memtable/sstable design as well as the "Memtable" and "SSTable" names come
from Cassandra's sections 5.3 and 5.4 of [[|Google's
Bigtable paper]], although some of the terminology around compaction differs.)
+ (Memtable/SStableの高レベルな設計と名前は、[[|GoogleのBigtableに関する論文]]のセクション5.3と5.4を参考にしています。ただしコンパクション周りの用語は若干異なります。)

View raw message