Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Element Missing from NoSQL

DZone's Guide to

The Element Missing from NoSQL

· Cloud Zone ·
Free Resource

Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.

I'm a big fan of NoSQL products. MongoDB, Redis, CouchDB– it's really awesome stuff. However, I almost always just use a relational database. I feel much more comfortable with RDBs actually.

My favorite DB design is when you have a relational database for businessy things (users, money, content) and a fast, scalable store for relationships, transient data and whatever other application logic would benefit best from NoSQL.

NoSQL is all about the right tool for the job. My assumption is that this implies a system could use several stores.

I know how to make a system like that work, what the pro's and con's of using various db's are, but there's one element I am not sure how to handle: Backup.

I write this article as a question to you: how do you backup two systems? When I have architected this type of design, I have to have one of the following be true:

  • I don't care about backup as one of the stores isn't critical
  • The data in one of the stores can be regenerated
  • Concurrency between stores isn't important

For a reasonably complex system, I doubt any of these would be true. Is there a good, general way to snapshot a whole system across multiple DB's?

Source:  http://jeffdickey.info/the-element-nosql-is-missing

TrueSight Cloud Cost Control provides visibility and control over multi-cloud costs including AWS, Azure, Google Cloud, and others.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}