RCC：使用重做日志的推测写版本控制
RCC: Speculative Write Versioning with Redo Logs
浏览论文内容
中文总结 AI 辅助
研究现代OLTP引擎写写冲突并发受限问题，提出RCC利用重做日志解决冲突，通过创建推测写版本实现事务流水线化及懒更新，还有提交时死锁检测和列级RCC等技术，在数据库上实现后性能显著提升。
中文摘要 AI 辅助
现代OLTP引擎依靠多版本控制来消除读写冲突，但其并发能力在写写冲突方面严重受限。传统的就地立即更新记录的方式导致一次只有一个事务能更新记录，其他冲突事务需等待。我们提出RCC，利用重做日志解决写冲突。事务通过重做日志创建推测写版本来异地更新记录，多个推测版本允许并发事务在更新冲突点后流水线化。事务提交时懒更新，通过丢弃推测版本实现轻量级回滚。为发挥推测版本控制的性能潜力，RCC提出提交时死锁检测和列级RCC（RCC-C）两项新技术。RCC通过基于锁的访问时间冲突排序和依赖图跟踪保证可串行性。我们在MySQL和PostgreSQL上实现RCC，将并发控制机制与它们的缓冲区管理器、锁管理器和恢复模块集成。在128核机器上运行64个并发线程时，RCC相比原始版本将TPC-C的事务吞吐量和延迟提高了一个数量级。RCC-C通过避免错误冲突导致的死锁和不必要的中止进一步提高了吞吐量和延迟。对于高竞争的YCSB基准测试，提交时死锁检测使RCC能扩展到128个客户端，而竞争方案在超过32个线程时无法扩展。
英文摘要
Modern OLTP engines rely on multi-versioning to eliminate read-write conflicts, yet their concurrency is severely limited for write-write conflicts. The conventional wisdom of updating records in place and immediately causes only one transaction to update a record at a time, and other update-conflicting transactions to wait for the former to commit or abort. Thus, conflicting transactions are serialized. We propose RCC, which leverages redo logs to resolve conflicting writes. A transaction updates a record out of place by creating a speculative write version using the redo log. With multiple speculative versions, RCC allows concurrent transactions to be pipelined after the update-conflicting point. Each update made by a transaction is installed to its record upon commit. This lazy update policy enables lightweight rollback: a transaction aborts by discarding its speculative versions. To realize the performance potential of its speculative versioning, RCC proposes two novel techniques: commit-time deadlock detection and columnar RCC (RCC-C). The former detects cycles only once lazily at commit time and the latter eliminates record-level false WW conflicts by leveraging column-granule redo logs. RCC guarantees serializability using lock-based access-time conflict ordering and dependency graph tracking. We implement RCC on MySQL and PostgreSQL, integrating the concurrency control mechanism with their buffer managers, lock managers, and recovery modules. RCC improves TPC-C's transaction throughput and latency over Vanilla versions by an order of magnitude when running 64 concurrent threads on a machine with 128 cores. RCC-C further boosts throughput and latency by avoiding false conflict-induced deadlocks and unnecessary aborts. For a high-contention YCSB benchmark, commit-time deadlock detection enables RCC to scale to 128 clients while competing schemes do not scale beyond 32 threads.
