Does CouchDB use SQL? No. So it may be mentioned in a post about "NoSQL".
> Description of Cassandra is misleading.
Defend your claim.
> He also misses the fact that Cabinet has real master-to-master replication.
When you start to need real master-to-master replication, the kind that Tokyo Tyrant offer is simply insufficient. It has no versioning, no way to resolve inconsistencies, no quorum write/read, etc. By the time you're at that scale, you had better be looking at Cassandra, HBase, or Hypertable IMO.
> Feature overlap between Redis, Cassandra and Tokyo C/T is too big.
Maybe I can buy that Redis and Tokyo Cabinet/Tyrant have too great of feature overlap (and note that I'm only interested in Redis as a high performance count server), but Cassandra is in a completely different realm with completely different sets of tradeoffs. To suggest that it is similar to the others is simply naive.
All "document-oriented" means in the Couch context is that the db's data model is "you have a key and a collection of attributes associated with it."
> CouchDB shares a basic concept of a document oriented database with views that Notes Domino has.
> In this model "documents" are just arbitrary collections of values that are stored some how. In CouchDB the documents are JSON objects of arbitrary complexity. In Notes the values are simple name value pairs, where the values can be strings, numbers, dates or arrays of those.
He disses Tokyo Cabinet table feature which is in fact _not_ like typical tabular data but behaves more like a second level hash (hash of hashes) — which he raves about as an awesome feature of other storages.
"None of these really set CouchDB apart, because you could just encode JSON data and store it in Tokyo Cabinet, you can maintain your own indexes of data fairly easily, and you can build a simple REST API in a matter of days, if not hours."
Except you'd be missing the querying features in Tokyo Cabinet. He also misses the fact that Cabinet has real master-to-master replication.
Redis' batch-disk-dumping-from-memory strategy is interesting and theoretically allows it memcached speed with persistance. I'll be looking out for this one.
Finally the statement on using each one for a different use case is crazy. Feature overlap between Redis, Cassandra and Tokyo C/T is too big.