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,
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
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
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