If you legitimately want to move the ball forward, here's how to do it: - Create one jira ticket per idea - Attach a patch - Post your benchmark results
It's important to consider changes one at a time so we have the clearest picture possible about what we are gaining. On Fri, Feb 22, 2013 at 4:00 AM, Radim Kolar <h...@filez.com> wrote: > Dne 13.2.2013 16:32, Jonathan Ellis napsal(a): >> >> The only point here that would make a difference in practice is >> >> leveldb using a worse hash function. > > how do you know that it would not make difference in practice. i have > implemented some optimalization from leveldb to cassandra - different L0 > level - 12 tables of 1/10 size L1, faster promotion to next level and > variable number of sstables per level and it performs faster for write heavy > workload. > > i do not understand why you are not interested in performance > optimalizations. For example yesterday i did buffered sstable writing and it > turned to be significant perfomance advantage using 1mb buffer changed test > time from 1m50s to 0m40s. Another significant gain is to use read ahead in > compactions and replace bucket based size tiered compaction to compaction > strategy used in lucene - it did not produce immortal sstables like > cassandra does. > > i have quite high demands for perfomance, my test environment for new > project has about 1 bilion new rows per day, in production it will be about > 30 times higher, so what is worth coding for me might not be worth coding > for you. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
