3 ms·

This suggests you don't commit transactions individually, but buffer them for some time and then write them to disk at once. There are plenty scenarios where yo

by gizmo 5y ago

This suggests you don't commit transactions individually, but buffer them for some time and then write them to disk at once. There are plenty scenarios where you don't need all ACID properties, but in many cases what makes databases slow is adhering stringently to those ACID constraints.

bob1029 5y ago
Correct. I can achieve multiple transactions per I/O. I do not believe this actually breaks any ACID properties. Reads and writes are serialized to a single thread for all processing.
- imtringued 5y ago
  >I do not believe this actually breaks any ACID properties. You must send the write ACK after your transaction has been written, which could increase latency in the worst case but you will still have much higher throughput.
wiz21c 5y ago
ACID is what makes it possible to write parallel applications and stay sane. I'm always in awe when I realize how crucial it is.
- jstrong 5y ago
  it's often not particularly crucial for timeseries data, though, and the performance tradeoffs of syncing every insert to disk are significant.
  - wiz21c 5y ago
    yes I was seeing from my CRUD applications point of view :-)