Summary of serial execution
Serial execution of transactions has become a viable way of achieving serializable isolation within certain constraints:
- • Every transaction must be small and fast, because it takes only one slow transaction to stall all transaction processing.
- • It is limited to use cases where the active dataset can fit in memory. Rarely accessed data could potentially be moved to disk, but if it needed to be accessed in a single-threaded transaction, the system would get very slow.[1]
- • Write throughput must be low enough to be handled on a single CPU core, or else transactions need to be partitioned without requiring cross-partition coordination.
- • Cross-partition transactions are possible, but there is a hard limit to the extent to which they can be used.
- [1] If a transaction needs to access data that’s not in memory, the best solution may be to abort the transaction, asynchronously fetch the data into memory while continuing to process other transactions, and thenrestart the transaction when the data has been loaded. This approach is known as anti-caching, as previouslymentioned in “Keeping everything in memory” on page 88.