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
I can promise you it is not a matter of not being interested in performance
enhancements, but there is a trade off between stability, backwards
comparability, etc. Some of the changes you are proposing have merit but they
fundamentally change some decisions that have been made and Jonathan
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
You have to use the same function if you want to do streaming i/o for
repair and node movement instead of random.
On Thu, Feb 14, 2013 at 7:48 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
real leveldb is better in lot of areas:
L0 are 1/10 of L1 sstable size
tables can be promoted to upper levels if no merging is needed (there is
hole)
variable number of sstables per level, but it tries to keep 1:10:100
sstable ratios. Not hard requirement
very important - better hash function.
The only point here that would make a difference in practice is
leveldb using a worse hash function. For us it's not worth making
partitioning worse to make compaction better.
On Mon, Feb 11, 2013 at 12:53 PM, Radim Kolar h...@filez.com wrote:
real leveldb is better in lot of areas:
L0 are
