The Element Missing from NoSQL
Join the DZone community and get the full member experience.Join For Free
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
Opinions expressed by DZone contributors are their own.