151–160 of 172 posts
Earlier quoted context omitted.
Even as a JSON document store I'd rather use postgres with a jsonb column.
Why is that? I found Postgres's JSONB a pill to work with beyond trivial SELECTs, and even those were less ergonomic than Mongo.
Earlier quoted context omitted.
Most regular inserts and regular selects: https://medium.com/serpapi/mongodb-benchmark-3-4-vs-4-4-vs-5... We have internally a benchmark with MongoDB 8.x, but same pattern of disappointing results.
As someone that has ran every version from 3.2 to 8 on small nodes and large clusters (~100+ nodes)... 8 is waaay faster in the real world. It's not really comparable. Your micro benchmark is comparing the few nanoseconds of the heavier query planner, but in the real world that query planner gives real benefits. Not to mention aggregations, memory management improvements, and improvements when your working set size i…
Here's another dataset about performance regression doing `$inc`s as fast as possible on the same object.
Mongo 3.4.24:
332,037 stats update in 100s. (3,321 stats updates per s)
287,553 stats update in 100s. (2,876 stats updates per s)
Earlier quoted context omitted.
> It's 2025 these features are not-negotiable for most use cases. Excuse me? I do enterprise apps, along with most of the developers I know. We run like 100 transactions per second and can easily survive hours of planned downtime. It's 2025, computers are really fast. I barely need a database, but ACID makes transaction processing so much easier.
100? I had a customer with 10k upserts incl merge logic for the upserts while serving 100k concurrent reads. Good luck doing that with a SQL database trying to check constraints across 10 tables. This is what Nosql databases are optimized for... There's some stand-out examples of companies scaling even mysql to ridiculous sizes. But generally speaking, relational databases don't do a great job at synchronous/transact…
Earlier quoted context omitted.
As someone that has ran every version from 3.2 to 8 on small nodes and large clusters (~100+ nodes)... 8 is waaay faster in the real world. It's not really comparable. Your micro benchmark is comparing the few nanoseconds of the heavier query planner, but in the real world that query planner gives real benefits. Not to mention aggregations, memory management improvements, and improvements when your working set size i…
Can you share some data about this? Here's another dataset about performance regression doing `$inc`s as fast as possible on the same object. Mongo 3.4.24: 332,037 stats update in 100s. (3,321 stats updates per s) Mongo 8.0.4: 287,553 stats update in 100s. (2,876 stats updates per s) (higher is better)
Do you often do that many independent $incs (or any query) in a single second? I have gotten much better performance by using `BulkWrite` to do a bunch of small updates in a batch.
To go to a specific example from the "Driver Benchmark" on the link from your first reply:
client[:users].insert_one(name: Digest::MD5.hexdigest(index.to_s))
For me the limiting factor is mostly around the performance of BulkWrite. I haven't hit any performance bottlenecks there that would merit benchmarking different ways to use it, but I would mostly be trying to fine tune things like how to group the items in a BulkWrite for optimal performance if I did.
Even in the case of one-off queries it almost always feels faster on 7+ than earlier versions. As I mentioned the one bottleneck we hit with migration was that we had some queries where we were querying on fields that were not properly indexed and in those cases performance tanked horribly to the point where some queries actually stopped working. However, once we added an index the queries were always faster than on the old version. When we did hit problems, it took only a few minutes to figure out what to index then everything was fine. We didn't have to make changes to our application or the queries themselves to fix any issues we had.
Earlier quoted context omitted.
> It's 2025 these features are not-negotiable for most use cases. Excuse me? I do enterprise apps, along with most of the developers I know. We run like 100 transactions per second and can easily survive hours of planned downtime. It's 2025, computers are really fast. I barely need a database, but ACID makes transaction processing so much easier.
MongoDB has had ACID transactions for many years. I encourage folks to at least read up on the topic they are claiming to have expertise in
granted, the failures were pretty minor, especially compared to previous reports (like the first one [1], that was a fun read), but they still had bad defaults back then (and maybe still do)
I would not trust anything MongoDB says without independent confirmation
Earlier quoted context omitted.
Mongo is Web scale.
instagram use postgresql and still web-scale (unless this was satire)
Earlier quoted context omitted.
sigh See https://jepsen.io/analyses for how MongoDB has a tradition of incorrect claims and losing your data. Distributed databases are not easy. Just saying "it is web scale" doesn't make it so.
Are you aware: 1. That PgSQL also has issues in jepsen tests? 2. of any distributed DB which doesn't have jepsen issues? 3. It is configurable behavior for MongoDB: can it lose data and work fast, or work slower and do not lose data. There is no issues of unintentional data loss in most recent(5yo) jepsen report for MongoDB.
MongoDB defects were, let's say, somewhat more severe
[2.4.3] "In this post, we’ll see MongoDB drop a phenomenal amount of data."
[2.6.7] "Mongo’s consistency model is broken by design: not only can “strictly consistent” reads see stale versions of documents, but they can also return garbage data from writes that never should have occurred. [...] almost all write concern levels allow data loss.
[3.6.4] "with MongoDB’s default consistency levels, CC sessions fail to provide the claimed invariants"
[4.2.6] "even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations"
let's not pretend that Mongo is a reliable database please. Fast? likely. But if you value your data, don't use it.
Earlier quoted context omitted.
As someone that has ran every version from 3.2 to 8 on small nodes and large clusters (~100+ nodes)... 8 is waaay faster in the real world. It's not really comparable. Your micro benchmark is comparing the few nanoseconds of the heavier query planner, but in the real world that query planner gives real benefits. Not to mention aggregations, memory management improvements, and improvements when your working set size i…
Can you share some data about this? Here's another dataset about performance regression doing `$inc`s as fast as possible on the same object. Mongo 3.4.24: 332,037 stats update in 100s. (3,321 stats updates per s) Mongo 8.0.4: 287,553 stats update in 100s. (2,876 stats updates per s) (higher is better)
Setup a clone of prod and build a tool to replay your traffic to it.
I have lots of data from datadog and ops manager but not going to take the time to publish ATM.
I just moved a 4tb deployment from 3.2 to 7. It cut max query time by about half. I actually went to instances with half the cpus, too (although I switched from ebs to ssds).
Earlier quoted context omitted.
Why is that? I found Postgres's JSONB a pill to work with beyond trivial SELECTs, and even those were less ergonomic than Mongo.
Because you get the convenience of having a document store with a schema defined outside of the DB if you want it, along with the strong guarantees and semantics of SQL.