Rather than listen to unqualified nonsense, they run tests. And gather facts to guide technology decisions.
and yes, I work for MongoDB - just before anyone starts whining about disclosure
You're welcome
I posted my problems with it as a response to a sibling comment. Since this was four or five years ago now, maybe all of this has been fixed, but that's not something I'm going to depend on in production any time soon.
Also, the MongoDB users you list must be taken with a grain of salt. For example, you list Facebook on that page. Nope. The description is "...adapted the storage engine API, extending MongoDB into new workloads and new capabilities." That is, Facebook acquired Parse, which used Mongo. Facebook ported MongoDB to run on RocksDB. Facebook shut down Parse. End of MongoDB at Facebook. You list Google, and the mouseover is basically that you can run MongoDB on GCE. I'm not saying that Mongo is unusual in this behavior. It's how most people listing "who uses X" build their lists.
Hi
Have you tried using MongoDB Atlas for your Mongo database? It's an on-demand, fully managed database service that you can provision on Azure, AWS, or GCP (so no lock in to any 1 cloud provider)
https://www.mongodb.com/cloud/atlas
It includes a free tier for experimentation and evaluation (currently only available on AWS)
And as this is real MongoDB, rather than a Cosmos shim of the APIs, all the features of MongoDB actually work....
You're aware that the vendor will post gospel about their product on their own website? I'm not using Postgres, I use MySQL, but I can assert with 100% certainty that most of the "comparison" on that URL is just marketing bullshit. You're a prime example that this new-age bullshit works and that's what's worrying.
How's that relevant? You're neither lead architect nor does your employment at MySQL / Oracle mean anything. Many incapable developers score positions at big companies. Without facts, maths and measurement you can be Linus Torvalds for all I care. The article at the URL provided is simply marketing ploy. I'm experienced enough to notice what's wrong with the comparison, but I won't take that article apart to prove anything. If you believe Mongo is a product that helps you - perfect. Now, if you're thinking you'll convince me that it's great by berating another great product - well, that raises a red flag. Who says I've to use a single software vendor anyway?
it was the reference to me as "You're a prime example that this new-age bullshit works and that's what's worrying". The same statements were leveled at anyone from mysql 10-15 years ago. I'm glad mysql works well for your use-case
Are you the Mat Keep who is Director of Product Marketing at MongoDB? If so then, FWIW, people don't often respond well to marketing links posted without identifying your connection to the company.
When users have evaluated DocumentDB against MongoDB, they see major shortcomings in Microsoft's offering:
"As we were developing our new financial benchmarking service last year, we evaluated Microsoft’s Azure DocumentDB, but MongoDB offered much richer query and indexing functionality"
Cassandra had a minor bug with timestamps which was fixed relatively fast and now it passes Jepsen fully. There were also a few implementation issues around LWT (Paxos) but at that time Paxos was very new. There were no architectural / fundamental changes needed to correct these issues. Also, even before fixing, Cassandra was losing only a tiny fraction of data than Mongo was losing. So, yes, this is what I call "far better", even if not initially perfect.
Pretty sure Cassandra still uses local timestamps and last-write-wins, which means you can't do safe updates. Also pretty sure they didn't fix the timestamp-collision row-isolation issue I talked about, because it was on HN's front page a few months ago. ;-)
Using timestamps and last write wins is a well known and well documented behavior, so you must assume updates can be sometimes applied in a different order than they were submitted. However, reordering updates is not the same as rolling back writes as was in case of Mongo. Cassandra does not promise linearizability in this mode of operation (if not using LWTs), and this is a tradeoff to get better availability. There is no better way than last write wins if you want high availability and partition tolerance and don't want to pay the performance and availability price for a consensus algorithm like Paxos or Raft. And no, vector clocks do not solve this problem in practice at all.
As for the post on HN from a few months ago, I remember only one guy who mixed LWT and non LWT updates and was surprised with lack of linearizability. Not a Cassandra fault if somebody doesn't know what he's doing.
> assume updates can be sometimes applied in a different order than they were submitted
I suggest you re-read the analysis. Some databases can offer safe, generalized commutative updates; e.g. Riak. Cassandra can't: updates, in general, can be lost through reordering.
> There is no better way than last write wins if you want high availability and partition tolerance and don't want to pay the performance and availability price for a consensus algorithm like Paxos or Raft.
You can have safe updates through clustering columns or if you really insist on destructive updates - through LWTs. With clustering columns you can easily achieve whatever is possible with vector clocks.
As for the research you posted, there is no free lunch. Each of these strategies come with their own set of drawbacks. That's why Cassandra offers choice at a query level.
Clustering columns do not make Cassandra updates any safer: they only reduce the scope of conflicts. It's still last-write-wins--the approach that Cassandra's own blog recognizes as "a high potential for data loss".
That's why Cassandra offers choice at a query level.
It doesn't give you a choice: you get last-write-wins, or some limited merge functions with CQL types. You can't get generalized CRDTs in Cassandra, because they won't expose conflicts to the user layer. Cassandra gives up on a whole class of safe AP datatypes as a consequence of this restriction.
Now you are arguing about a lack of a particular builtin feature. Riak is last-write-wins by default with optional vector clocks and builtin CRDTs. Cassandra is last-write-wins by default with clustering columns allowing to implement an equivalent of Riak vector clocks and CRDTs in the application. If you include a client id in the primary key and use client-side timestamps, you essentially are doing vector clocks and there are no conflicts guaranteed - users of Cassandra have been doing it for years.
A lot of MongoDB users who wouldn't be considered a "joke" https://www.mongodb.com/who-uses-mongodb
Rather than listen to unqualified nonsense, they run tests. And gather facts to guide technology decisions. and yes, I work for MongoDB - just before anyone starts whining about disclosure You're welcome