
The Long Road to Mongo's Durability - craigkerstiens
https://brandur.org/fragments/mongo-durability
======
JoachimSchipper
Indeed, MongoDB (with very careful configuration) has recently passed a round
of Jepsen test, although patches were necessary after -rc3; see
[https://jepsen.io/analyses/mongodb-3-4-0-rc3](https://jepsen.io/analyses/mongodb-3-4-0-rc3).

------
Joeri
How does mongodb benchmark against other db products when you configure it for
durability. Is it still faster?

~~~
brandur
I haven't run any numbers, but here's how I understand it.

Because of the way its journaling is implemented with sync interval, when
you've configured durability with `writeConcern` `j` set to `true`, any write
will have to wait for the next sync interval to commit. This wait will be in
the range of 0 to the configured interval (~100 ms) and that makes the worst
case quite bad.

You can work around it by configuring a lower sync interval and thus less
average wait time, but I doubt you ever reach the level of databases that were
designed to prefer durability by default, and which have heavily optimized
that write path.

~~~
magnetic
Well doesn't that depend on what metric you use to define speed? It sounds
like you are measuring latency... but if you were to measure throughput you
may be getting a different answer. The 100 ms flush may not do much good for
latency, but it can allow some good batching on writes, which would most
likely increase throughput vs having a write flush at every transaction
commit. And it's actually more complex than this, because it depends on the
hardware you have, its cache size and whether you have a BBU with a battery
that will last long enough to flush the contents of the cache to "permanent
and durable storage" in case of power outage. In other words: YMMV

~~~
diziet
Indeed, choice of metrics matte.r To add to what you're saying, there are even
more metrics than that!

Consider latency as an example. There's average latency and nth percentile
latency (and a similar metric of % of requests above certain latency). You can
plot the latency as a CDF (Cumulative distribution function) to visualize it
differently. The amount of time you run the benchmark affects things, as
performance is typically better 5 seconds in compared to 5 hours in.
Performance consistency within a closely bounded temporal interval matters a
lot too, as too spiky performance can be detrimental.

Is the same workload being performed? Are the machines configured similarly,
or is one a replica cluster while another one is a slower NAS? Are the indexes
similar? What is the read workload during that time, as no reads vs high reads
affect write latency rate.

And we're just talking about one metric for a database. There are other
related metrics -- like iops, cpu taken, memory taken, disk taken, disk
writes, disk amplification (io per op), etc, that all 'matter'.

