OO databases have had similar modeling primitives and architectures for quite some time. What makes now different? Is separating behaviour from data the key difference or is there something else?

However, the concrete form and domain of the data has great potential for graph sharding optimization, as the example of document stores shows – collecting related information in a non-generic shard – the document.

Cheers,

/peter

I actually disagree that most NOSQL stores are moving in the opposite direction from graphs. I think there’s two main focuses in the NOSQL space today: projects oriented around scaling to SIZE and projects oriented around scaling to COMPLEXITY.

Scaling to size then means coping with large volumes of relatively simple data (for example username / password) and the key-value stores and bigtable clones live here.

Scaling to complexity means coping with data that is semi-structured and that is connected. Here’s where the document databases and graph databases live.

Scaling to size get a lot of attention because scaling to hundreds and thousands of machines is very sexy. But for the majority of the use cases out there that don’t need Google or Amazon scale, then coping with complexity through a rich data model that can easily represent most or all domains, is much more important.

And in this group we can certainly see that there’s a move towards more graph-like structures. Couch was the pioneering document database that set the ground and already Mongo added references to their data model. Now recently Riak came along and took the next step with its support for links.

In a graph database like http://neo4j.org (disclaimer: /me is involved) then relationships — how two nodes are related to one another — are first class citizens. They have a mandatory type (KNOWS, OWNS, CONTAINED_IN, etc) and an arbitrary amount of key-value properties. Our experience is that it makes modeling any domain a WHOLE lot easier and over time I think other models will start adding similar features.

–
Emil Eifrem
http://twitter.com/emileifrem
http://neo4j.org

Sam

I won’t predict what is the future of NoSQL, but it is obvious relational databases needs some freshness.

For us who still loves to experiment with academic experiments here are some links: http://www.openrdf.org http://sparql.sourceforge.net http://razor.occams.info/code/semweb
But as already Aleksander mentioned a lot of those projects stale or “taking an indefinite hiatus”.

I mean, something that scales as good as Big Table but can be queried with SPARQL would be… a dream come true :)

I have to admit, though, that the main reason I’d like to see document oriented dbs become more graph like is not because I would think that there’s anything wrong with them, but because I’d like to see diversity in the graph db space. I spent last 3+ years working with a graph db emulated on top of a relational db and you can probably imagine it was a less than ideal experience.