From my understanding of key/value stores, one can put documents on the other side of the key, but any and all parsing/processing of that value happens outside of the database. In CouchDB, the entire document is query-able from within map/reduce views. After being querying on, those keys are indexed for faster future queries. So, in that way, CouchDB jumps over the key/value limitations and becomes a document database.

In addition to map/reduce output, there's also a handy _update system that can be used to validate a JSON document prior to it's insertion in the database--again, something not possible with key/value storage.

You can, though, use CouchDB in a key/value fashion by storing binary data (or HTML, XML, RDF, etc) as attachments or JSON encoded strings (where possible). In that case, you would just be retrieving them by id (or URL), but you could store all kinds of ad hoc metadata about those attachments and use those to query with later.

Also, the blog article Ryan Eby just posted, is a great (and quick) overview of the varied noSQL ecosystem. In many ways, these systems are as different as they are similar.

Hope you (re)search goes well,

P: 864.232.9553

On 4/12/10 2:42 PM, Jonathan Rochkind wrote:
Yeah, I may have gotten it completely wrong.

Okay, help this grasshopper (possibly by pointing me to relevant documentation), what's the difference between "document-based" and "key-value store"? When I've looked at CouchDB before, despite it describing itself as "document based", I haven't been able to tell what the difference is between it and a "key value store". It seemed to support storing a "document" by key, and retrieving it by key. It didn't seem to _do_ anything special with the document other than storing it there (maybe it DOES, but I missed it?). So you can call it a "document" instead of a "value", but I couldn't figure out how that differed from a key-value store.

I guess it's that CouchDB _does_ let you build indexes on values other than the key? Wacky, wonder how I missed that when I reviewed it last.


Ross Singer wrote:
On Mon, Apr 12, 2010 at 12:22 PM, Jonathan Rochkind <> wrote:
The thing is, the NoSQL stuff is pretty much just a key-value store.
There's generally no way to "query" the store, instead you can simply look
up a document by ID.

Actually, this depends largely on the NoSQL DBMS in question.  Some
are key value stores (Redis, Tokyo Cabinet, Cassandra), some are
document-based (CouchDB, MongoDB), some are graph-based (Neo4J), so I
think blanket statements like this are somewhat misleading.

CouchDB and MongoDB (for example) have the capacity to index the
values within the document - you don't just have to look up things by
document ID.


Reply via email to