transactional

2 месяца назадdiscuss

I strongly hope that the authors are actually using O_DSYNC|O_DIRECT, and not just the O_DIRECT they discuss. The post seems to conflate the 4KB atomicity (support for which is still hit or miss from drives I’ve checked) with 4KB writes being assuredly durable. If there is a write cache on the SSD/NVMe, which is common, one must either issue a FLUSH via fsync or have FUA set on the write via O_SYNC/O_DSYNC. Relying only on O_DIRECT is not a correct solution, as it assumes a drive with sufficient capacitors to always write out all cached data on failure, and that’s not a part of the required drive contract.

transactional

в прошлом годуdiscuss

percona/sysbench-tpcc has been subsequently updated to include a stronger disclaimer that it's "TPC-C-like" and doesn't comply with multiple TPC-C requirements. Fingers crossed that this helps stop vendors from doing non-TPC-C benchmarking without realizing it.

transactional

в прошлом годуdiscuss

...but are they enforceable?

transactional

в прошлом годуdiscuss

(Hi! Post author here.)

It is written with a lean towards serializable, partly because there's a wide variety of easy examples to pull which all implement serializable, but the ideas mostly extend to non-serializable as well. Non-serializable but still MVCC will also place all of their writes as having happened at a single commit timestamp, they just don't try to serialize the reads there, and that's fine. When looking at non-serializable not MVCC databases, it's still useful to just try to answer how the system does each of the four parts in isolation. Maybe I should have been more direct that you're welcome to bend/break the mental model in whatever ways are helpful to understand some database.

The line specifically about MySQL running at serializable was because it was in the Spanner section, and Spanner is a (strictly) serializable database.

transactional

2 года назадdiscuss

I'll rephrase the line sometime, but the intention is to communicate that it's the default choice to go with if you're making this decision in 2024. Most of the projects which aren't using some form of direct IO are doing it because they predate O_DIRECT (e.g. postgres), didn't architect for using async IO (e.g. mongo), or have excessive portability concerns which means they only offer it as an option (e.g. innodb).

comments