From the intro page[1]... Many of the descriptions comparing to NoSQL are wrong. There are plenty of NoSQL options that have similar features, though it isn't universal, it can and often is there. Cassandra, for example, probably does just as well in multi-zone/dc concurrency. Consistency options are also similarly tunable. Cockroach 1.0 was announced earlier as well.
It's not that I don't appreciate the option. This seems far closer to what DocumentDB should have been earlier on. Though tbh, I think Storage Tables are already pretty useful.
Good to see a complaint about NoSQL that is at least targeted in a reasonable direction. Personally I see a lot of success coming from flexible document schemas but obviously it's not perfect for every app.
I've got some developer PTSD from a previous project where the solution architect decided to use CosmosDB for the entire domain model that was very relational and very transactional, all because "NoSQL is easy to learn and allows rapid development".
Yeah it is, until you're trying to manually create and maintain relations between documents in different schemas owned by different microservices.
If that's the case, it wouldn't make sense to talk about NoSQL tradeoffs as if all NoSQL dbs were actually similar in any way.
Eg:
Fauna is considered a NoSQL database and doesn't have any of the drawbacks the article mentions. It has ACID guarantees, a relational model, and strong consistency.
Mongo and Dynamo also offer transactions with ACID guarantees these days.
And that's why we have the "NewSQL" movement, though a bit slow. The benefit of NoSQL in some cases (Cassandra and HBase for me) is that it restricts developers from using non-scalable data structuring and querying. RDBMS's have a bad reputation primarily because how they were used via unrestricted queries that came back to haunt the product owners.
And even then, some local DB approaches are fundamentally unsolvable in a distributed way (CAP, exactly-once-sends, etc) without trading something, even with cockroach.
It's not the best wording but I'm sure the author is contrasting it with the previous generation of Nosqls such as Mongodb, Cassandra, and dynomo-style KV stores.
Even ignoring much of the buggy pre-history of some of these projects. They were all built with eventual consistency in mind to hit perf/availability goals.
It is a NoSQL database with a novel architecture. It uses schemas, supports transactions, historical queries, and it doesn't use a client server model.
I tried to say 'no NoSQL alternatives'. And I noticed that while there's node middleware for most libraries, the ease of use is different for each database.
I agree with you! And on that note I would like to see more articles that describe problems that NoSQL stuff is good at. This is probably the main reason why there is so much confusion. Everybody is talking about how great cassandra/mongodb/couchdb/... is, but nobody tells you where and how to actually use it.
The author is an SQL language and MySQL database consultant, and he writes an article questioning NoSQL. Fair enough, and I agree with his point that different NoSQL datastores have different strengths and weaknesses and it can be difficult on a new project to know up front which CAP tradeoffs may be OK to make (e.g., HBase may have better tuning for faster consistency but Cassandra is likely easier to set up across different data centers; MongoDB is very easy to use in simple master slave or replica sets setups if no sharding is required; etc.)
Personally, I use PostgreSQL and MongoDB for most of my work but make a real effort keep up to speed on CouchDB (actually, BigCouch is more interesting), HBase, Cassandra and a few RDF datastores.
Exactly this, „non-traditional“ and noSQL is as inexact as it gets. It includes an incredibly wide range of architectures, from Spanner and CockroachDB which deliver ACID guarantees equal and even surpassing relational systems to pure performance tuned systems such as Aerospike which have few guarantees and features but are blazingly fast. There are pretty much all shades of consistency in between, like Cassandra and Scylla with tunable consistency amd LWT. Lumping them all together into a single category will yield poor results.
NoSQL is just a poor term. It lumps together a number of radically different approaches. Imagine a term like NoCar that would lump together airplanes, bicycles, boats, trains, and scooters, just because they are means of transportation which are not a car.
Things like Redis, Kafka, Consul, FoundationDB, RRDTool, git, S3, and plain files are all NoSQL databases of sorts. They all are useful in certain areas, all have very different features and guarantees, and each would be a poor substitute for each other or for an SQL database. (Likely even MongoDB can be useful in some areas, even though I have a hard time imagining that.)
I wish the whole "NoSQL" moniker would go away, replaced by a few terms that make more sense.
That said, the original article is a good one, laying out the upsides and downsides of a document database, and why it makes sense as a local, per-app database.
I applaud this effort to compare NoSQL databases, but I'd like to inject a word of caution. The various NoSQL databases are _amazingly_ different, and it's hard to compare them properly using a single scenario.
Adrian Cockcroft's scenario, for example, favors a simple key/value store with good partition tolerance. (It also contains some design decisions that fit together poorly: He asks about partition tolerance, but his application is designed to write to one availability zone and immediately read consistent data from another availability zone. He should either combine these two operations into a single operation, give up partition tolerance, or look for better load-balancing options.)
I could easily describe other scenarios which favored S3, MongoDB, CouchDB, or offline Hadoop/Hive queries of S3 buckets. And that's just the systems I've used. We need much better NoSQL comparisons, but we won't get there without investigating a wide mix of use cases. Otherwise, we're going to wind up with the equivalent of a comparison of Clojure, Haskell, Mozart and F# written by a "Blub" programmer: All the genuinely interesting questions will fall outside the basis of comparison.
It's not that I don't appreciate the option. This seems far closer to what DocumentDB should have been earlier on. Though tbh, I think Storage Tables are already pretty useful.
[1] https://docs.microsoft.com/en-us/azure/cosmos-db/introductio...
reply