[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-dev
Subject:    Re: real leveldb vs cassandra leveldb
From:       Jonathan Ellis <jbellis () gmail ! com>
Date:       2013-02-22 16:17:00
Message-ID: CALdd-zjN+4msu3v-9xjuRDyT8peFcJpPBYASqPRkATw7aNsO4Q () mail ! gmail ! com
[Download RAW message or body]

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 <hsn@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
[prev in list] [next in list] [prev in thread] [next in thread]