Review my software: Keyspace consistently replicated key-value store

We originally had memcached support but discontinued it somewhere on the way. We think supporting the memcached protocol is confusing to our end-users, as there are strong differences between memcached and a consistently replicated (disk-persistent) key-value store. See for example my answer to the post below about safe and dirty reads. Also, we support a much richer set of commands than memcached.

However, we are certainly going to bring back memcache protocol support if users demand it (the old memcache code is still in the source tree right now).

Thanks.

It is accurate and contains no misunderstanding.

Some terminology: we differentiate safe-reads, which go through the master and always reflect previous writes which have been OK'd and dirty-reads, which can go through any server, even if no other servers are up; there are absolutely no guarantees with dirty-reads, but it scales linearly, although this is not the indented primary use-case of Keyspace.

Keyspace does not contain horizontal partitioning aka. sharding, we plan to build such a layer on top of Keyspace. The exact details of this layer are still being debated, so it its exact position in design space is unclear --- it partly depends on input we get from this release.

This sounds much like the way we were using MySQL when I worked on a large consumer site. We both sharded and replicated to scale out. And, we used MemCached to bridge the replication lag. For better or worse, all writes auto-committed independently. What strategies should Keyspace users employ to counteract similar replication delay issues?

I presume Keyspace would offer much better performance because it doesn't have to worry about 95% of the stuff a SQL db does. Drizzle seems like it falls somewhere in the middle of the solution in the above paragraph and Keyspace. Is that a fair assessment?

One thing I wanted (among many) with our solution was the ability to specify async disk forcing (an oxymoron?). I'm willing to allow a database to return control to me before writing if it thinks it will be able to write something to disk within N seconds. The increase in performance for most non-transactional systems (meaning that a few seconds of data loss occurring once a year wouldn't hurt too badly) would more than make up for the risk. Terracotta, Gigaspaces, etc. are interesting to me because they facilitate async persistence.

Our original vision is related to cloud computing. We suspect that Amazon will not be the only player, and other cloud providers will pop up to compete with them. Also, many small-to-medium size companies we talk to don't like Amazon (too expensive) but have a a few ten servers they wish to use as a distributed system (eg. database). We're attacking the distributed system market bottom-up, using open-source software to gain a foothold. Keyspace was originally planned to be a controler/meta-server, a low-level building block for other distributed systems, similar to how Google uses its Chubby server for GFS and BigTable --- Keyspace, like Google's Chubby, has an implementation of Lamport's Paxos consensus algorithm at its heart. As development proceeded, we made it into a more general key-value store that can also be used in eg. web 2.0 scenarios when high-availability is required.

Interesting idea. We're already using EC2 as one of our test platforms anyways. We'll look into it.

Why?

Our intention, with the AGPL, versus the GPL is to close the SaaS loophole, so if you base a service on top of a modified Keyspace, you have to publicize your changes. But you can use it, sell it, distribute it, etc. just as you can with the GPL license.

Also, you can license Keyspace under different terms, ie. under a non-open license, at a reasonable price.