loading...
Microsoft Azure

What every relational database developer needs to know about NoSQL

burkeholland profile image Burke Holland ・2 min read

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.

Data modelling and partitioning in Azure Cosmos DB: What every relational database user needs to know

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.

Discussion

pic
Editor guide
Collapse
rodiongork profile image
Rodion Gorkovenko

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.

Collapse
amrutaranade profile image
Amruta Ranade

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.

Collapse
burkeholland profile image
Burke Holland Author

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.

Collapse
vbilopav profile image
vbilopav

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

Collapse
dansilcox profile image
Dan Silcox

Will definitely give that a look! Thanks for sharing :)

Collapse
kiransabnedev profile image
kiransabne-dev

I use both SQL and NO-SQL database for the projects as per it's advantages

Collapse
shiro_hagen profile image
Andi Elliott

Thanks for sharing, definitely going to check it out 😎

Collapse
buinauskas profile image
Evaldas

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 :)

Collapse
burkeholland profile image
Burke Holland Author

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?

Collapse
buinauskas profile image
Evaldas

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.

Collapse
gklijs profile image
Gerard Klijs

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.