Restores stopped writing 2 GB for a 2 MB backup
Summary: Restores stopped writing 2 GB for a 2 MB backup (v0.6.0b15).
A point-in-time restore used to write 2 GB to disk no matter how little data it was restoring. WiredTiger preallocates its log file to 2 GiB, that file is almost entirely zeros, and zeros compress to nothing but expand to everything — so a database holding 100 documents archived to 2.0 MB and restored to 2.0 GB. Restores now write sparsely: the same bytes, holes instead of zero-runs, a restored directory of 276 KB, and a restore that took 858 seconds on a busy disk now takes under three.
The second thread in this release is how performance gets measured at all. The
published figures used to be whatever someone last remembered to re-run, on a
developer laptop — where a background build or an OS indexer shifts every
column at once and nothing in the output says so. They are now measured on
dedicated cloud instances as part of cutting the release they describe, against
a current mongod. Tail latency relative to mongod improved from 2.04x to
1.48x, three per-operation workloads now beat it outright, and the numbers
on the site are the numbers for the build you can download.
The rest is correctness work across both servers: $avg on Decimal128,
_id: NaN lookups, $arrayElemAt inventing nulls, array-field sorts that
depended on whether an index happened to exist, a first batch that ignored
mongod's 16 MB reply cap, IPv6 binding, top on the Rust server, and
replSetGetStatus agreeing with hello.