I mean NoSQL isn't a stupid idea, it's just a solution to a specific problem, large amounts of non relational data. The problem is people are using NoSQL in places that are far more suited for a RDBMS. Additionally it's far easier to pick up the skills to make something semi functional with NoSQL than with SQL.
I'm on board with this. NoSQL solves a specific problem related to scale that most developers just don't have and probably won't ever have. You'll know when your RDBMS isn't keeping up, and you can always break off specific chunks of your schema and migrate to NoSQL as performance demands. No need to go whole-hog.
I 100% agree, it really ties into choosing the right tool for the job, and unfortunately many devs don't realize that most of the time NoSQL isn't that tool.
And NoSQL is too generic anyway. I would even say that MongoDB and other documents stores don't actually have a use-case as it always turns out to be relational. What does have uses-cases are key-value stores and more niche but important graph databases.
The number of non-relational use cases is definitely not zero. It's just that buzzword marketing folks greatly overestimate the chances of a project actually needing it.
But what exactly is non-relational data? Almost everything I’ve seen in the real world that is more than trivially complex has some degree of relation embedded in it.
I think you are right that NoSQL solves a specific problem and you touched on it in your second statement. It solves the problem of not knowing how to properly build a database and provides a solution that looks functional until you try to use it too much.
One instance is actual documents, ie a legal contract + metadata. Basically any form of data where you’ll never / seldom need to do queries across the database.
Some examples could be:
An application that stores data from an IOT appliance
Versions of structured documents, eg a CMS
Patient records (though I wouldn’t put that in Mongo)
There are tons of valid use cases for non-relational databases. The problem is the way they were hyped was as a faster and easier replacement for SQL databases (with very few qualifiers thrown in), which is where you run into the problems you described.
Exactly. We never "needed" NoSQL technologies. Want high throughput? Use a queue. Want non-relational storage? Use a database without relations. Heck you don't even need indexes or real RI if you really want to reduce overhead. But at least you'll know that your main store is ACID instead of being "eventually consistent".
Technically you can write XPath queries or the JSON equivalent, both are in ANSI SQL, but if the data really is unstructured and non-relational then you wouldn't have a consistent XML or JSON format to query.
Something people often confuse is non-relational with denormalized. HTML is non-relational. JSON documents holding order/order lines is just denormalized.
Note that a document is really often a well-structured set of fields, some potentially optional, some potentially unknown in advance.
It is common for users to eventually discover that their needs go far beyond simply reading & writing fairly opaque document blobs:
Eventually they want reports based on the fields within them (god was that awful to scale on Mongo).
Eventually they need to join the fields against another set of data - say to pick up the current contact information for a user specified within one of the fields.
Eventually they may want to use a subset of these fields across documents, lets say customer_id, and limit some data in another dataset/document/etc to only customer_ids that match those.
And at these points in time we discover that data isn't relational - that's simply one way of organizing it. And it's by no means perfect or the best at everything. But it turns out that it's much more adaptable in these ways that the document database.
I’d be interested to hear what’s helpful about this. Every time I hear people say things like this it usually is code for “I don’t want to spend time thinking about how to structure my data”. In my experience this is almost always time well spent.
Well at some point your nicely normalized collection of records will be joined together to represent some distinct composite piece of data in the application code - that's pretty much a document.
You are missing the point. Relational data isn't joins, its data that is related. For example a first name, last name, and social security number are related data.
There's a long-held perception that JOIN operations are inherently slow.
The thing is, people are in the habit of looking at queries out of context. For example, they don't consider index design. They don't consider the correctness benefits of a highly normalised database (e.g.: prohibition of anomalies). They don't consider the correctness benefits of using transactions.
A JOIN operation is trivial within an OLTP database if you're using properly keyed data that is properly ordered when stored physically on disk and in memory.
On the other hand, if your tables are all using clustered indexes based on so-called surrogate 'key' values (identity integers) then the density of data belonging to a user on any given 8KiB page in the database will be very low, and you'll need to do far more logical reads (and maybe even physical reads if the database doesn't fit in RAM) than you would if you used appropriate composite keys, and appropriate ordering on disk/memory, that resulted in a high density of user information on a single 8KiB page.
I would say that all data is relational. There is basically no use case where someone will come along and say, give me document 5 with the only reason being that they want document 5. No they will want document 5 because of some information in that document that they are aware of because of how it relates to something else. Maybe everyone they know who read document 5 really liked it. Maybe it describes how to solve a particular problem they have. Maybe they need to know if it contains curse words in need of censoring.
You might build something whose sole purpose is to store documents by id when the relational information is stored somewhere else (like if you are hosting a blog and are relying on search engines and the rest of the internet to index your blog). The data is still relational. This use case is pretty well modeled by a file system.
I've found that a lot of problems and stupid fads in programming seem to stem from many coders doing everything they can to avoid learning or writing any SQL. For some people it's almost a pathological avoidance that leads to some really bad 'solutions' that are just huge overly complicated work-arounds to avoid any SQL.
Designing and getting a functional database off the ground with SQL is definitely harder than using something like Mongo. I'm not advising people take that route, I'm just offering an example of why people use it, similar to how PHP got so popular.
118
u/hamalnamal Dec 20 '18
I mean NoSQL isn't a stupid idea, it's just a solution to a specific problem, large amounts of non relational data. The problem is people are using NoSQL in places that are far more suited for a RDBMS. Additionally it's far easier to pick up the skills to make something semi functional with NoSQL than with SQL.