Hudson build is back to normal: Cassandra #29
See http://hudson.zones.apache.org/hudson/job/Cassandra/29/changes
Re: could cassandra be split into two parts?
Depends on what exactly you have in mind ... Almost all of the storage engine logic is in the db package. I don't think it would be too hard to make this pluggable so you could slide in your own DB, say based on Derby/MySQL/BDB etc... I can see how specialized implementations of the database part could be useful for different apps. Do you expect that the API will still be the same put/get style thrift API ? Or are you hoping to expose the additional abilities of the underlying db through the thrift API ? That makes the question more interesting (and complicated). On Sat, Apr 11, 2009 at 6:33 PM, Ian Holsman i...@holsman.net wrote: hey. I was wondering how feasible it would be to de-couple the P2P layer of cassandra from the storage engine. I'd like to be able to plug in a non-column DB underneath, and use the DHT layer of cassandra. Is this something anyone else has considered doing? -- Ian Holsman i...@holsman.net
Re: could cassandra be split into two parts?
I implemented the pluggable storage layer into Dynamo. It really depends on what you want to establish. But theoritically it should be possible. Avinash On Sat, Apr 11, 2009 at 6:33 PM, Ian Holsman i...@holsman.net wrote: hey. I was wondering how feasible it would be to de-couple the P2P layer of cassandra from the storage engine. I'd like to be able to plug in a non-column DB underneath, and use the DHT layer of cassandra. Is this something anyone else has considered doing? -- Ian Holsman i...@holsman.net
Re: [jira] Commented: (CASSANDRA-68) Bloom filters have much higher false-positive rate than expected
On Sat, Apr 11, 2009 at 9:53 PM, Prashant Malik pma...@gmail.com wrote: The results are a bit counter intuitive here I would have expected it to be faster with the same FP rate but I am not sure why it is slower if you are just using a couple of hash functions and using double hashing. Murmur is a higher-quality hash and takes more operations to achieve its better key distribution. But since the new implementation always uses two calls to Murmur no matter how many hashes are needed it is virtually constant time. I am sorry I haven't looked at the test code but have you tried it with large strings as keys ? e.g 128 byte keys , also with Longs. The random strings generated are 128 bytes. -Jonathan
