[
https://issues.apache.org/jira/browse/CASSANDRA-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13709056#comment-13709056
]
Jonathan Ellis edited comment on CASSANDRA-5727 at 7/15/13 10:21 PM:
-
Don't be a troll. If you have constructive feedback, make it here or in
another ticket. Multiple Cassandra developers have read the leveldb source;
there is no magic there.
For the record, leveldb is designed for low concurrency embedded purposes.
Everyone who tries to use it for a multiuser database (riak, hyperdex, probably
others) has to do some serious surgery of the kind we've done. (Don't block
writes for L0, concurrent compactions, etc.)
was (Author: jbellis):
Don't be a troll. If you have constructive feedback, make it here or in
another ticket. Multiple Cassandra developers have read the leveldb source;
there is no magic there.
Evaluate default LCS sstable size
-
Key: CASSANDRA-5727
URL: https://issues.apache.org/jira/browse/CASSANDRA-5727
Project: Cassandra
Issue Type: Task
Components: Core
Reporter: Jonathan Ellis
Assignee: Daniel Meyer
What we're not sure about is the effect on compaction efficiency --
larger files mean that each level contains more data, so reads will
have to touch less sstables, but we're also compacting less unchanged
data when we merge forward.
So the question is, how big can we make the sstables to get the benefits of
the
first effect, before the second effect starts to dominate?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
