3 ms·
> the data gets written only once This is essentially never true. It _could_ be true if you disabled many safety features in an RDBMS, but you then lose ACID g
by sgarland 3y ago
> the data gets written only once
This is essentially never true. It _could_ be true if you disabled many safety features in an RDBMS, but you then lose ACID guarantees.
MySQL (with InnoDB), for example, undergoes the following for an INSERT/UPDATE:
1. Write current state of pages to the undo log
2. Write changes to the buffer pool
3. Write changes to the redo log
4. Write changes to the binary log
5. Write changes to the double write buffer
6. Write changes to disk
There are a dizzying amount of variables affecting each of those, including delays, maximum allowable size, sync/async flushing, outright disabling of some steps (most commonly the double write buffer – which is only safe for CoW filesystems like ZFS – but you can also disable the redo log if you really want to), etc.
To your point of writes to disk, most (all?) of the disk writes are batched. Even if InnoDB wasn't doing so, the kernel can and will batch writes on its own.
> so there is never a time when the database can be inconsistent
If the hardware suffers a failure during a write, inconsistency can occur. This is precisely why the double write buffer (for InnoDB) and full page writes (for Postgres) exist. Also, the hardware usually reports back that it's flushed before it's actually done durably written it. If you have SSDs with Power Loss Protection capacitors, this isn't a problem, but no consumer drives that I'm aware of have those.
> downside with many storage engines is that an entire row must be read and rewritten
Actually, it can be even worse than this: if you're using UUIDv4 (or anything else random) as your PK, any UPDATE on more than one row is going to touch _a lot_ of pages. All of those pages have to be written out. This affects not only RDBMS with clustered indices (InnoDB, SQL Server) but also Postgres due to its WAL. Changing one byte can result in a 16 KiB (InnoDB) or 8 KiB (Postgres) write, which is quite a bit of amplification.
- Tostino 3y agoYup, switching to sequential uuids reduced the wal traffic in my SaaS database significantly when we did it ~6 years ago.
- sgarland 3y agoI'm a big fan of UUIDv7 if you need them. I maintain most places could just use an auto-incrementing int, and rewrite the API to not expose it, but barring that UUIDv7s are great.