Data consistency

With lack of a “transaction” when data is committed to the data store, especially into multiple entities, there is a possibility of an inconsistent state due to exceptions, etc. What approaches do people take to handle these scenarios?

This is a very common question coming from developers who are used to RDBMS and are considering moving to document databases.

When writing/updating a single document, that transaction is atomic, so you don’t need anything special to handle that. Often times, a data model that spans multiple relational tables can be collapsed/denormalized into a single document, so you need to rely less often on transactions.

In the case that you really do need a multiple-document transaction, currently the only thing I can think of is following a two-phase commit pattern (here’s an example:

Note that this isn’t just true for Couchbase, but for all the popular document databases and nosql databases that I can think of.

Hi Matthew, thanks for the response. I certainly understand the gap between relational to NoSQL. My case is definitely not unique, perhaps it’s just massaging the workflow or looking at the data again.

I have the following

  • Parent object with some metadata and a summary of its children of type A. Also has children of type B and C
  • Object A with its own metadata, could be millions of these, for each parent though it’s possible to have ~ 100. I made these as it’s own document
  • Object B and Object C with own metadata could be lots of these on their own but upwards of maybe 10-50 as children of the Parent. B and C are also their own documents.

During creation of the Parent its children also get created and this is where the potential issue comes in as all the Documents are created. I could bring some of the objects into the Parent but I’d rather not risk the 20 MB limit and it’s easier to manage queries and aggregations on a documents vs collection items.

I am open though.