A different, unified look at the data model of the key-value stores, document databases, and column-family stores from Martin Fowler:

there’s a big similarity between the first three - all have a fundamental unit of storage which is a rich structure of closely related data: for key-value stores it’s the value, for document stores it’s the document, and for column-family stores it’s the column family. In DDD terms, this group of data is an aggregate.

The aggregate approach was present in the relational databases world for quite a while. It came in two flavors: views and denormalization. The first one worked well for non-distributed deployments, while the second is used everywhere the speed or the usage of joins was not an option.

Original title and link: Key-Value Stores, Document Databases, and Column Stores as Aggregate Oriented Databases (NoSQL database©myNoSQL)

via: http://java.dzone.com/articles/aggregate-oriented-database

[…] implementing Auto Save in the RDBMS system could be a problem because of multiple reasons:

• The schema and overall logic changes to save versioned data in the RDBMS system will be non-trivial
• There might be validation checks that fail because users kept didn’t fill out some fields at that point.
• Making periodic (30 second) transactional updates to any live system is not good for overall performance.

A work around would be saving your Object Model to RavenDB directly and if user visits the document after a time out, load both Transactional Data and Object data, compare the timestamp and use the freshest set of data.

By far the best document database usecase I have read about in quite a while.

Original title and link: Implementing Auto Saves Using RavenDB: NoSQL Tutorials (NoSQL database©myNoSQL)

via: http://www.dotnetcurry.com/ShowArticle.aspx?ID=784

Daniel Lang presents 6 solutions for dealing with relations in RavenDB:

If you’re coming from the sql world, chances are you will be confused by the lack of relations in document databases. However, if you’re running RavenDB you’ve got plenty of options to address this trade-off. I personally cannot think of any situation where I’d wish back SQLServer because of this (there could be other reasons).

Two not recommended:

• go to the database twice
• include one document inside the other

Two RavenDB specific solutions:

• implement a read trigger to do server-side joins
• implement a custom responder

Two recommended solutions:

• use the .Include<T>() method
• denormalize your references

Couple of comments:

• the difference between “include one document inside the other” and “denormalize your references” is very subtle—the latter suggests including only the information needed for the presentation layer.
• I think one should consider both “include one document inside the other” and “denormalize your references” and choose one of them depending on the chances of the embedded documents being updated often vs the chances of having the presentation layer changing often
• except RavenDB, all other document databases seem to offer only two options: “go to the database twice” and “denormalize your references”
• when Redis will release its version embedding server-side Lua, that could be used as a form of stored procedure

Original title and link: 6 Ways to Handle Relations in RavenDB and Document Databases (NoSQL database©myNoSQL)

via: http://daniellang.net/how-to-handle-relations-in-ravendb/

Sven Schmidt:

Since CouchDb is inherently unstructured, there’s no global schema that you manage to control your data’s structure. That’s often a good thing, because it gives you flexibility, but it can also cause problems, for example when you want to access documents without handling against all sorts of different “versions” of your document you might have.

When we first talked about document databases we said:

1. no more ORM. Do a search or take a quick look at this list of NoSQL libraries and see if that still stands.
2. no more schema constraints. The moment the structure of the data showed signs of evolving too rapidly, we started to look for ways to test document structure for inconsistency
3. no more data migrations. Maybe no data migrations, but data versioning might be needed long term.

I think I’ve already written this once, but here it is again: the sum of constraints in a system is constant. The more relaxed the rules are on a component, the more constraints the rest of the components will need to support.

Original title and link: Document Databases and Data Migrations (NoSQL database©myNoSQL)

via: http://catbrainblog.wordpress.com/2011/12/19/couchdb-migrations/

A post rehashing PostgreSQL hstore capabilities:

I will be focusing on a key value store that is ACID compliant for real! Postgres takes advantage of its storage engine and has an extension on top for key value storage. So plan is to have a table can have a column that has a datatype of hstore; which in turn has a structure free storage. Thinking of this model multiple analogies throw themselves in. It can be a Column Family Store just like Cassandra where row key can be PK of the table, and each column of hstore type in table can be imagined like a super column, and each key in the hstore entry can be a column name. Similarly you can imagine it some what like Hash structures in Redis (HSET, HDEL), or 2 or 3 level MongoDB store (few modifications required). Despite being similar (when little tricks are applied) to your NoSQL store structures, this gives me an opportunity to demonstrate you some really trivial examples.

A couple of comments:

• you can store key-value pairs in any relational database
• there are quite a few ACID key-value stores available
• hstore is more like a document store. Values are not opaque and it supports queries against them.
• not everyone needs a document database when a key-value store is enough. The most common example is storing web sessions.
• not everyone needs an ACID compliant database. Not in a distributed system requiring high availability.

Anyway, the conclusion remains the same.

Update: there’s a long thread discussing this post on Hacker News .

Original title and link: PostgreSQL Hstore: The Key Value Store Everyone Ignored (NoSQL database©myNoSQL)

via: http://blog.creapptives.com/post/14062057061/the-key-value-store-everyone-ignored-postgresql

One of the advantages with schema-less design is that it works well for prototyping; you can have a collection of documents with each of the documents of variable structure. You can modify the document structure for one, some or all documents within the collection all without requiring a schema for the collection or each and every document.However, this is also a disadvantage during prototyping; there are no constraints to stop documents within the same collection having variable structure

Rules of the game are simple: The sum of all constraints in a system is constant. The more relaxed one of the component is, the more validations other components must perform.

Original title and link: NoSQL Document Databases: Testing Your Document Structure for Inconsistencies (NoSQL database©myNoSQL)

via: http://exceptionallyexceptionalexceptions.blogspot.com/2011/12/testing-your-document-structure-for.html

As it turns out, PostgreSQL has a number of ways of storing loosely structured data/documents in a column on a table.

• hstore is a data type available as a contrib package that allows you to store key/value structures just like a dictionary or hash.
• You can store data in JSON format on a text field, and then use PLV8 to JSON.parse() it right in the database.
• There is a native xml data type, along with a few interesting query functions that allow you to extract and operate on data that sits deep in an XML structure.

I concur. Not knowing your database *must not* be the reason for adopting a NoSQL database.

Original title and link: The Durable Document Store You Didn’t Know You Had, but Did (NoSQL database©myNoSQL)

via: http://robots.thoughtbot.com/post/13829210385/the-durable-document-store-you-didnt-know-you-had-but

Jans Aasman (CEO AllegroGraph) interviewed by Srini Penchikala:

InfoQ: What best practices and architecture patterns should the developers and architects consider when using a solution like this one in their software applications?

Jans: If your application requires simple straight joins and your schema hardly changes then any RDBM will do.

If your application is mostly document based, where a document can be looked at as a pre-joined nested tree (think a Facebook page, think a nested JSON object) and where you don’t want to be limited by an RDB schema then key-value stores and document stores like MongoDB are a good alternative.

If you want what is described in the previous paragraph but you have to perform complex joins or apply graph algorithms then the MongoGraph approach might be a viable solution.

Thinking about the products and projects I’ve been working on, most of them have had to deal with all these aspects in different areas of the applications and with different importance to the final solution. Mistakenly though, in most of the cases they ended up using a relational database only. With polyglot persistence here, this shouldn’t happen anymore. That’s not to say though that every project must use all of these technologies just because they are available. But it could use any of them or all combined.

InfoQ: What are the emerging trends in combining the NoSQL data stores?

Jans: From the perspective of a Semantic Web - Graph database vendor what we see is that nearly all graph databases now perform their text indexing with Lucene based indexing (Solr or Elastic Search) and I wouldn’t be surprised that most vendors soon will allow JSON objects as first class objects for graph databases. It was surprisingly straightforward to mix the JSON and triple/graph paradigm. We are also experimenting with key-value stores to see how that mixes with the triple/graph paradigm.

This topic was also discussed during my NoSQL Applications panel, but due to a panel time constraints we couldn’t reach a conclusion. But it’s definitely an interesting perspective.

Original title and link: NoSQL Databases Best Practices and Emerging Trends (NoSQL database©myNoSQL)

via: http://www.infoq.com/news/2011/12/mongograph-qa