cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "MemtableSSTable" by JonathanEllis
Date Tue, 20 Apr 2010 17:50:50 GMT
Dear Wiki user,

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

The "MemtableSSTable" page has been changed by JonathanEllis.
http://wiki.apache.org/cassandra/MemtableSSTable?action=diff&rev1=6&rev2=7

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

  
  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 thresholds.
  
+ SSTables that are obsoleted by a compaction are deleted asynchronously when the JVM performs
a GC.  You can force a GC from jconsole if necessary but this is not necessary; Cassandra
will force one itself if it detects that it is low on space.  A compaction marker is also
added to obsolete sstables so they can be deleted on startup if the server does not perform
a GC before being restarted.
+ 
+ CFStoreMBean exposes sstable space used as getLiveDiskSpaceUsed (only includes size of non-obsolete
files) and getLiveDiskSpaceUsed (includes everything).
+ 
  (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 [[http://labs.google.com/papers/bigtable.html|Google's
Bigtable paper]], although some of the terminology around compaction differs.)
  
  http://wiki.apache.org/cassandra/ArchitectureSSTable

Mime
View raw message