

The four categories of NoSQL databases - wspruijt
http://rebelic.nl/engineering/the-four-categories-of-nosql-databases/?utm_source=twitter&utm_medium=twitter-publisher-main&utm_campaign=twitter

======
michh
Imho this article is too much of an oversimplification. It's forcing artifical
labels on some things that don't really fit very well.

It's fairly useless if you've already heard about most of these and it's a
false start if you haven't.

If you do want such a list, a much more accurate and complete one is at
<http://nosql.mypopescu.com/kb/nosql>

~~~
antirez
You could be surprised about the efforts many folks do to try to put the
different DB solutions into some kind of schema. The reason for this is mostly
opaque for me...

~~~
_delirium
It can be useful to have a sort of map of the landscape if you're looking
around. Sort of how in PLs, it's nice to be able to have a categorization
better than "there are thousands of programming languages". Coming up with a
_good_ map is hard, though, and any categorization does tend to emphasize some
factors and gloss over others...

------
strlen
Categorizing the stores by their data model is misleading. Tokyo Tyrant and
Voldemort are very different: later is a multi-master, partitioned,
distributed system; former is a network attached database. In fact, one could
easily use Tokyo Cabinet as the persistence engine in Voldemort in place of
BerkeleyDB.

A far better classification should be done along the lines of the distribution
models and handling of failures. Do they use consistent hashing or range based
partitioned? Under failure, is consistency or availability given up? Are there
barriers to nodes rejoining after recovering from a failure? Is there an
ordered, distributed commit log, etc...

It's much harder to change the distribution model than it is change the query
model. Riak, HBase and Voldemort also have support for running custom code
against which queries may be made. On the other hand, adding a totally ordered
commit log (via serializing through a floating master or using consensus) to
Voldemort or Riak, or adding multi-master (in the sense of multiple region
servers taking reads and writes for the same partition) support to HBase is
going to be far more difficult.

Creating a "grand classification scheme" that ignores the most important
aspect suggests a dilettante approach (not saying the author is a dilettante,
but it's a much more complex topic which requires more than dabbling).

------
btilly
I'm puzzled by their describing Riak as a column oriented database. It is a
key/value store. Perhaps they are thinking of the highly beta Riak Search?
<http://wiki.basho.com/Riak-Search.html>

~~~
Fluxx
Key/value store or _maybe_ a document database. But it certainly has nothing
to do with being column oriented.

~~~
sjs
Basho themselves have complained about being called a document DB. Probably
because you can store absolutely anything in Riak. Regardless of the reason I
think we can safely call it a KV store and be done with it.

edit: And by Basho themselves I don't mean some official statement, I just
mean people who work for Basho.

------
simonw
Describing Redis as just another key value store kind of misses the point.

~~~
kennu
I agree. Anybody interested in Redis should get to know its hash tables,
lists, sets, sorted sets, etc. It's sometimes amazing how many problems Redis
can solve out-of-the-box, just because it provides these common data
structures as a persistent service.

~~~
est
redis is key-structured-value db

------
spenrose
I believe his description of document-based databases is mistaken WRT
versioning: it's a central concept for couchdb, but not for mongodb.

------
arkitaip
It would be great if there was a very basic web site that could guide you to
the most suitable storage solution based on the problem you are working on.
Sorta like a guide or wizard.

I think it's a shame that the movement is called NoSQL because it sorta
creates this false dichotomy that the field of web data storage is divided in
two camps. In reality, you need to, as always, pick the right solution for the
problem you are facing. NoSQL databases will never entirely replace SQL
databases and I think it's important to not shoehorn NoSQL in places where it
doesn't really belong.

~~~
andrewl
Philip Greenspun has a short article on the subject at:

[http://philip.greenspun.com/teaching/three-day-
rdbms/beyond-...](http://philip.greenspun.com/teaching/three-day-rdbms/beyond-
the-rdbms)

And there's a discussion about the article on his blog:

[http://blogs.law.harvard.edu/philg/2011/01/13/rdbms-
versus-n...](http://blogs.law.harvard.edu/philg/2011/01/13/rdbms-versus-nosql-
article-drafted/)

------
russell
The article is a summary of this:
[http://blog.monitis.com/index.php/2011/05/22/picking-the-
rig...](http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-
database-tool/)

The review of Cassandra: [http://blog.monitis.com/index.php/2011/05/24/nosql-
databases...](http://blog.monitis.com/index.php/2011/05/24/nosql-databases-a-
look-at-apache-cassandra/)

------
baddox
What about non-relational object databases?

------
est
how about EAV, OOdbms, functional and deductive db?

