Its a different way of doing things than traditional RDBMS (which very successfully served us well for over 20 years). Why cant we just choose the best tool for the job, after looking at pros and cons?
I contend NoSQL is the introduction of nailguns to scaling up large projects with few consistancy constraints where priorly there were only screwdrivers and hammers.
It's useful in it's arena. As are SQL based solutions in their arena. And there are tons of projects that can be done in either. Anyone who contends either is the only way hasn't spent enough time using the other.
IMO, its the equivalent of panting as opposed to sweating: a functional way to get something done that fits some things quite well.
NoSQL is very much alive and kicking, it’s just past the peak in the hype curve. There is a FAANG in particular who is notorious for banning relational databases outright because of their maintenance and scaling problems for their use cases.
As others have said, if you operate at a certain scale and can get away without complex joins and aggregations (which you should avoid anyway if you’re operating a high availability service), then NoSQL is a great option. It’s easier to scale out (often you just turn a knob) and its behavior is simpler and easier to predict.
NoSQL databases (in the sense of key/value stores) are a very old idea. I never understood why that was such a hotness. The pendulum never stops I guess.
I think a lot of the hate for NoSQL comes from 2 places:
1. Imperfect implementations. For example Mongo with it's lack of transactional safety (if that's still an issue, haven't worked with Mongo in a long time). Since then several different ideas and implementations have come forward and if you're looking for NoSQL right now and you have a good use case for it, you will almost certainly find a product that does just what you need.
and 2. People not understanding what NoSQL is good for and when to use it over relational. If you try to use a document store to store heavily relational data you're going to quickly give yourself a headache. The real use case of document stores is that they let you have the immense scalability of key-value stores (due to the nature of key-value stores) while also giving you some nested data and basic relational abilities.
In our stack we use a combination of SQL (Postgres), key-value store (Redis), and document store (DynamoDB), each picked to solve a certain problem and not go out of the bounds of what it's good for.
That's a really good point. Saying that NoSQL is about picking the right tool for the job makes it easy to dismiss. There are lots of programmers out there that just refuse to look at any other tools than the very small set that they already know. I think it would be beneficial to change that attitude across the spectrum of programming tools.
I looked at NoSQL when it was all the hype 5 years back and realized this sort of thing was going to be the case without ever needing to try it. NoSQL has its place, but the majority of apps don't seem to need it.
What is your exact question? To me it makes sense that you’d not want to use NoSQL if you’re dealing with data that’s already relational, and heavily leveraging features common in relational DBs that may not come out of the box with NoSQL DBs.
They’re saying basically that NoSQL DBs solve a lot of horizontal scaling problems but aren’t a good fit for their highly relational data, is my understanding. Not that they can’t get NoSQL functionality at eg the query level in relational DBs.
That's an overly simplistic framing of 'NoSQL'. Despite every piece of FUD to the contrary, 'NoSQL' is a stupid name for a set of tools designed to solve an entirely different set of problems.
I don't want some data in a relational model. Yes, I could put it there, but I would be doing so solely so that it fits in the relational model. Which is pretty pointless.
The fact that the relational model is "sound" doesn't mean that everything belongs in it. Plus, I'm not holding my breath waiting for an "intelligent data store that will be able to translate a fully normalized schema into a high performance, distributed, persistent representation that is queryable by this language". That's the description a mythical database panacea that solves all problems with no downsides.
The continual pitting of NoSQL vs SQL is a gross mis-characterization perpetuated out of holy-war fervor, yet based on few facts or even understanding of the differences.
I can't but help agreeing with this. However, I think NoSQL is an important tool when dealing with 'big' data (billions of records). NoSQL is also awesome for 'accelerating'/caching standard SQL (memcache to cache sql results, etc).
At the end of the day, both have important roles to play and, in many respects, compliment each other.
Tell me about it. I have been hauled into a project, where we are reimplementing a relational database using NoSQL. No idea why, other than the fact that they want to use NoSQL.
Personally, I'm drawn to Mongo, etc. because I can develop in my language of choice, and not have to write/debug SQL of any dialect to store and retrieve my data.
reply