Keyspace - a distributed key value store(scalien.com)
scalien.com
Keyspace - a distributed key value store
http://scalien.com/keyspace/
4 comments
To get critical mass, a new project has to present a plug-n'-play install. First impressions are everything. That is not the case here. I've read the docs and an initial install looks to need several different languages/compilers to get going. And then some.
Even Tokyo Cabinet/TT are more aligned and straightforward than this project. It will be interesting to see what happens here, But please oh please you Scaliens, give some more realistic and complete benchmarks to whet one's appetite.
Even Tokyo Cabinet/TT are more aligned and straightforward than this project. It will be interesting to see what happens here, But please oh please you Scaliens, give some more realistic and complete benchmarks to whet one's appetite.
How does this compare to say, cassandra, which also is a distributed key-value store?
Keyspace is replicated; when consistent, every node has a complete copy of the data. Cassandra distributes the keyspace across many nodes; in a reasonably-sized cluster a node will have only a fraction of the data. A write-heavy workload will scale horizontally with Cassandra but will probably be as slow as the slowest server in the cluster with keyspace.
Cassandra is tolerant of partitions in the cluster; if communication between two parts of a cluster are cut off, read and write operations that don't demand consistency will not fail. Keyspace has "dirty" reads that will continue to return inconsistent data when this occurs but all write operations require a majority of nodes to be up and in communications with one another.
Cassandra's data model is more sophisticated than Keyspace's. You can have multiple column families (essentially, namespaces) in Cassandra that can be ordered arbitrarily, given a plugin to compare two keys. Supercolumns are (this is a very simplified explanation) columns with tuples (key1, key2) as keys. Keyspace is a simple key/value store.
Both Cassandra and Keyspace support ranged gets; Cassandra supports multi-gets of a list of arbitrary keys as well. Keyspace supports increment and compare-and-swap operations that Cassandra does not.
Cassandra is used in production by a good number of places; I don't know who, if anyone, is using Keyspace.
All my knowledge of Keyspace comes from reading the thorough and clear whitepaper they offer at http://scalien.com/pdf/Keyspace.pdf.
Cassandra is tolerant of partitions in the cluster; if communication between two parts of a cluster are cut off, read and write operations that don't demand consistency will not fail. Keyspace has "dirty" reads that will continue to return inconsistent data when this occurs but all write operations require a majority of nodes to be up and in communications with one another.
Cassandra's data model is more sophisticated than Keyspace's. You can have multiple column families (essentially, namespaces) in Cassandra that can be ordered arbitrarily, given a plugin to compare two keys. Supercolumns are (this is a very simplified explanation) columns with tuples (key1, key2) as keys. Keyspace is a simple key/value store.
Both Cassandra and Keyspace support ranged gets; Cassandra supports multi-gets of a list of arbitrary keys as well. Keyspace supports increment and compare-and-swap operations that Cassandra does not.
Cassandra is used in production by a good number of places; I don't know who, if anyone, is using Keyspace.
All my knowledge of Keyspace comes from reading the thorough and clear whitepaper they offer at http://scalien.com/pdf/Keyspace.pdf.
Ha. Scalien is a great name.
How does a startup that develops database software plan to make money? Selling support?
How does a startup that develops database software plan to make money? Selling support?
That said, it appears this might be an interesting project. It appears it uses Paxos (http://en.wikipedia.org/wiki/Paxos_algorithm) to achieve high availability. This is a good deal more sophisticated than naive replication like MySQL. Also, reads can be specified as "dirty" or not, meaning they are more performant and tolerant of failure or network partition, but also possibly inconsistent. It appears to largely sacrifice the "partition-tolerant" part of the CAP triangle.
Also interesting are ranged get, atomic increment, and compare-and-swap operations.