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 "MemtableThresholds" by FlipKromer
Date Tue, 31 Aug 2010 03:43:03 GMT
Dear Wiki user,

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

The "MemtableThresholds" page has been changed by FlipKromer.
The comment on this change is: two tweaks, overall contents signed off by driftx.
http://wiki.apache.org/cassandra/MemtableThresholds?action=diff&rev1=16&rev2=17

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

  
  '''Larger Memtables don't improve write performance: '''Increasing the memtable capacity
will cause less-frequent flushes but doesn't improve write performance directly: writes go
directly to memory regardless. (Actually, if your commitlog and sstables share a volume they
might contend, so if at all possible, put them on separate volumes)
  
- '''Larger memtables do absorb more overwrites''': If your write load sees some rows written
more often than others (eg upvotes of a front-page story) a larger memtable absorbs more overwrites,
which creates more efficient sstables and thus better read performance.  If your write load
is batch oriented or if you have a massive row set, rows are not likely to be rewritten for
a long time, and so this benefit will pay a smaller dividend.
+ '''Larger memtables do absorb more overwrites''': If your write load sees some rows written
more often than others (eg upvotes of a front-page story) a larger memtable will absorb those
overwrites, creating more efficient sstables and thus better read performance.  If your write
load is batch oriented or if you have a massive row set, rows are not likely to be rewritten
for a long time, and so this benefit will pay a smaller dividend.
  
- '''Larger memtables do lead to more effective compaction''': Since compaction is tiered,
large sstables are prefereable: turning over tons of tiny memtables is bad. Again, this impacts
read performance (by improving the overall io-contention weather), but not writes.
+ '''Larger memtables do lead to more effective compaction''': Since compaction is tiered,
large sstables are preferable: turning over tons of tiny memtables is bad. Again, this impacts
read performance (by improving the overall io-contention weather), but not writes.
  
  Listed below are the thresholds found in `storage-conf.xml`, along with a description.
  
@@ -41, +41 @@

  === MemtableObjectCountInMillions ===
  This directive sets a threshold on the number of columns stored.
  
- Left unconfigured (missing from the config), this defaults to 0.1  (or 100,000 objects),
but the config file's inital setting of 0.3 (or 300,000 objects) is reasonable.
+ Left unconfigured (missing from the config), this defaults to 0.1  (or 100,000 objects).
The config file's inital setting of 0.3 (or 300,000 objects) is a conservative starting point.
  
  ''Note: The value is applied on a per column-family basis.''
  

Mime
View raw message