3 ms·

It's par the course for MongoDB. 10 years later and they still use sales tactics to lie about the capabilities of their database. MongoDB might be a solid datab

It's par the course for MongoDB. 10 years later and they still use sales tactics to lie about the capabilities of their database. MongoDB might be a solid database when properly used, but their marketing material, again, promises things that the software just doesn't support. This is literally their "we are the fastest database just turn off commits" claim, but now in a distributed manner.

threeseed 6y ago
> This is literally their "we are the fastest database just turn off commits" claim I don't recall them ever saying this.
- rrdharan 6y ago
  They said they were the fastest. They shipped with syncs turned off by default. EDIT: actually it was journaling of writeconcerns. Later they backtracked and enabled it by default, but by then their reputation was cemented (or bifurcated into fast, or terrible, I suppose). https://shekhargulati.com/2011/12/08/how-mongodb-different-write-concern-values-affect-performance-on-a-single-node/ https://shekhargulati.com/2011/12/08/how-mongodb-different-w...
  - threeseed 6y ago
    It seems quite similar to what MySQL/PostgreSQL is doing with its WAL. Those don't sync to disk on every write.
    - pritambaral 6y ago
      PG fsyncs on every commit. By default. It will let you delay commits — if you ask it to — so it may batch multiple commits together on a single fsync, but it will NOT report to you that it has saved data durably when it hasn't. Because this is a safe operation, PG will let you do this easily: even on a per-session or per-transaction basis. Similarly, you can ASK it to commit eagerly without waiting for fsync, again on a per-session or per-transaction basis. But it will never turn on by default, and the documentation of this option clearly calls out the risk: "an operating system or database crash might result in some recent allegedly-committed transactions being lost" Or more too: you can ask it to turn off fsync (and all other kinds of sync) entirely and risk total database inconsistency — say, because you are running it on a filesystem that guarantees consistency, like ZFS — but it strongly recommends against it just on the off-chance that some over-eager user carelessly turns it off. Because this is generally not a safe thing to do, PG will NOT let you do this easily: you MUST change the server config on disk and restart the cluster. I don't know about MySQL, but I'd be greatly surprised if they did anything like what MongoDB used to do. There's a reason MongoDB got that reputation, in a world where MySQL — and its surprising data-eating behaviours — already were popular.

threeseed 6y ago

> This is literally their "we are the fastest database just turn off commits" claim I don't recall them ever saying this.

rrdharan 6y ago
They said they were the fastest. They shipped with syncs turned off by default. EDIT: actually it was journaling of writeconcerns. Later they backtracked and enabled it by default, but by then their reputation was cemented (or bifurcated into fast, or terrible, I suppose). https://shekhargulati.com/2011/12/08/how-mongodb-different-write-concern-values-affect-performance-on-a-single-node/ https://shekhargulati.com/2011/12/08/how-mongodb-different-w...
- threeseed 6y ago
  It seems quite similar to what MySQL/PostgreSQL is doing with its WAL. Those don't sync to disk on every write.
  - pritambaral 6y ago
    PG fsyncs on every commit. By default. It will let you delay commits — if you ask it to — so it may batch multiple commits together on a single fsync, but it will NOT report to you that it has saved data durably when it hasn't. Because this is a safe operation, PG will let you do this easily: even on a per-session or per-transaction basis. Similarly, you can ASK it to commit eagerly without waiting for fsync, again on a per-session or per-transaction basis. But it will never turn on by default, and the documentation of this option clearly calls out the risk: "an operating system or database crash might result in some recent allegedly-committed transactions being lost" Or more too: you can ask it to turn off fsync (and all other kinds of sync) entirely and risk total database inconsistency — say, because you are running it on a filesystem that guarantees consistency, like ZFS — but it strongly recommends against it just on the off-chance that some over-eager user carelessly turns it off. Because this is generally not a safe thing to do, PG will NOT let you do this easily: you MUST change the server config on disk and restart the cluster. I don't know about MySQL, but I'd be greatly surprised if they did anything like what MongoDB used to do. There's a reason MongoDB got that reputation, in a world where MySQL — and its surprising data-eating behaviours — already were popular.