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.''
