Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: unknown -allip4:64.6.108.239 (athena.apache.org: encountered
 unrecognized mechanism during SPF processing of domain of hsn@filez.com)
Message-ID: <51275DC7.8060302@filez.com>
Date: Fri, 22 Feb 2013 13:00:07 +0100
From: Radim Kolar <hsn@filez.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
 rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: dev@cassandra.apache.org
Subject: Re: real leveldb vs cassandra leveldb
References: <51193E1D.3080902@filez.com>
 <CALdd-zjQZGxivdL4mZFbsyhuHFUGfZ7mZJFn-U5mS9PKmzM-nw@mail.gmail.com>
In-Reply-To: 
 <CALdd-zjQZGxivdL4mZFbsyhuHFUGfZ7mZJFn-U5mS9PKmzM-nw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.