I'm 41 and I don't really understand NoSQL.
I never have. I have a relational database background. When I came up, understanding how to normalize data was an essential part of application development. So was SQL. I have built a lot of Crystal Reports (dark times) and I can INNER JOIN like it's nobody's business.
NoSQL has always seemed like a toy to me. And a bad toy at that. Data is de-normalized, repetitive, and, frankly, chaotic. It is quite literally the opposite of everything I have ever learned about how to structure data. It feels like I'm telling my children to play in the street.
What I have failed to understand this whole time, is that relational databases were solving a problem that doesn't exist anymore: the cost of storage. Storage is cheap, which means we can use different database types to make our systems much, much faster.
It also means that you are going to need to unlearn everything you know about relational databases. NoSQL is not hard to understand, but you do have to let go of the rules that you were taught about how data should always be structured.
My friend Steve Faulkner on the Azure Cosmos DB team pointed me to an excellent video from Ignite. This session takes a relational database, and moves it into a NoSQL one, walking you though how the concepts do and don't map across.
It's extremely well done, and probably the best presentation I've ever seen on this topic. In addition, you'll get a great intro to new concepts like Partition Keys that don't exist in relational systems, but allow you to do pretty remarkable things in a NoSQL one.
If you come from a relational database background, so much of this will seem wrong. It's OK. Let go of what you know, and I think you'll find NoSQL absolutely fascinating.
Top comments (11)
Hi Friend!
Sorry, nothing personal, but just saying "NoSQL" we don't say anything :)
And if the post is about Azure Cosmos DB, then it's better call it so :) It is not about NoSQL in general, right - rather about specific storage service...
While relational databases are less or more alike, various NoSQL storages are all quite different and with different goals. Often it is about "P" part of CAP-theorem.
There was a hype about NoSQL in recent years, but now it seems to be somewhat subsided. Meanwhile both MySQL and Postgres nowadays can store and process JSON data which makes them "relational databases with NoSQL features".
General rule of thumb for me is don't try substituting relational DB with some "innovative" NoSQL engine just out of curiosity. Unless it is the part which could be easily redesigned and migrated in future if anything goes wrong. Because we all need to learn, surely.
Exactly! Relational databases solve many more problems than just the cost of storage. And the newer databases also provide functionalities that let you partition data. Both NoSQL and relational databases have their pros and cons that need to be weighed for each application. Naively choosing one over the other can get one in trouble as the application matures.
Fair point. I didn't mean to assert that relational databases are irrelevant, but rather that one of the reasons why we normalized data to begin with has fundamentally shifted.
That said - you're absolutely right. Each has its distinct advantages.
Data is always structured in a system one way or another, even in so-called NoSQL just it may be structured differently than some may expect.
If it is not structured then you're in trouble because there is no tangible structure at all whatsoever.
Edit
Also, any so-called SQL database can have non-normalized data that are faster to query and takes more space, so... I don't know
Thanks for sharing, definitely going to check it out 😎
I use both SQL and NO-SQL database for the projects as per it's advantages
Will definitely give that a look! Thanks for sharing :)
Definitely going to watch this!
It's both easy to start and go wrong with a NoSQL database if you don't understand your data :)
So true! I have watched this twice now.
The one thing that still hangs me up is that you need some external process to ensure the integrity of your data. That.....feels wrong. What do you think?
You don't necessarily need external processes for that, although in many cases you will.
I dislike this as well, but this is a tradeoff if you want to operate at massive scale.
You're sacrificing processing time and integrity to speed up response times.
When using Spring Data using either SQL or NOSQL doesn't mean that much a difference, espacially not when de data model is rather flat, which is often with micro services.