I am developing an application for my universities student research symposium around the idea of polyglot persistence. I have read Martin Fowlers book and done some other research online about the verious different types of NoSQL db’s. I am curious as to what the different use cases are for the different NoSQL databases?
Currently I have what Fowler has pointed out (other research was mostly done into API’s).
Key/Value:
- session data
- user profile
- shopping cart
- basically anything that has a single unique key that can be easily generated and replicated
Document:
- event logging
- CMS/blogging
- e-commerce (after the transaction has been completed)
- web analytics
Column Family:
- event logging
- CMS/blogging
- counters
- expiring usage
Graph:
- connected data
- location based services
- recommendation engine
So what other use cases are there? More specifically what are the use cases for each type of NoSQL db that are better than a relational model?
1
A Very Large List of NoSQL Use Cases
That list comes in handy now and then, and also points out when a certain NoSQL solution is specialized for that specific use case. The original HackerNews thread (linked at the bottom of that page) is useful for extended commentary as well.
I think you have covered almost everything. I can offer you one more about Graph database I have seen people or researchers use graph database for semantic analysis or storing ontology for Natural Language Processing as well.
And as I have been using a lot of Graph db I think what Graph db offers is much more than relational model can offer. For example, if I have a web application and I to connect all my friends from Facebook and Twitter based on location or interests. I can do it in one query. However, you can do that in SQL as well if you really want to, but the SQL can be an A4 long or more than that if you want to do it properly.
Why not go about this more axiomatically? For example, why is “CMS/blogging” better suited to document databases (or whatever)? What are the common properties of these applications that make you think they’re better suited to one or another technology?
Consider the strengths of each DBMS technology and, indeed, the theory each one is based on. What data model do they implement? (Does each one in fact have a data model?) What are the properties of each data model, and how do the properties of the application map onto those of the data model? If you develop such a map, you’ll have a way of characterizing any application, even one you’ve never heard of or one that hasn’t been invented yet.
Codd defined a data model as comprising three interlocking features: structure, operations, and constraints. The relational model has all three in spades. If you look closely at the alternatives, you’ll find they’re missing at least one and usually two of those. Any technology not based on the relational model is ipso facto less functional. For that reason it’s safe to say every application can be supported the the relational model (if not by extant relational products). The relational model is still more fully developed, more powerful, and yet simpler than any other yet devised. It will be hard to improve on because it rests on predicate logic and set theory.
Perhaps you can identify applications for which, say, well defined operations don’t matter. But you want to be very sure you first understand why they matter in general before you can say with any certainty why they’re not necessary (or even just useful) for a particular application.
Sooner or later, someone will tell you “relational doesn’t scale” and that technology X is fast. When they do, remember that they’ve implicitly given up features that technology X lacks relative to the relational model, features that might well matter. Besides, a data model isn’t fast or slow, only an implementation is. Whenever there are more programmers than machines, it’s cheaper to buy faster hardware than to hire more programmers.
2