在云中拆分交易服务
Unbundling Transaction Services in the Cloud
摘要：
DBMS引擎的传统体系结构将恢复、并发控制和访问方法代码紧密地绑定在记录的存储引擎中。我们提出了一种不同的方法，其中存储引擎被分解为两层（每一层可能有多个异构实例）。事务组件（TC）只在逻辑层工作：它知道事务及其“逻辑”并发控制和撤销/重做恢复，但它不知道页面布局、B树等。它支持面向记录的接口，提供原子操作，但它不知道事务。提供原子记录操作本身可能涉及DC本地并发控制和恢复，这可以使用系统事务来实现。TC和DC中机制的相互作用导致多级重做（与集成引擎中重做的重复历史范例不同）。这种系统架构的重构可以允许更容易地部署特定于应用程序的物理结构，并且还可以有助于利用多核硬件。特别有前途的是它在云数据库部署中实现灵活事务的潜力。我们描述了必要的原则，分拆恢复，并讨论实施问题。
英文摘要：
The traditional architecture for a DBMS engine has the recovery, concurrency control and access method code tightly bound together in a storage engine for records. We propose a different approach, where the storage engine is factored into two layers (each of which might have multiple heterogeneous instances). A Transactional Component (TC) works at a logical level only: it knows about transactions and their "logical" concurrency control and undo/redo recovery, but it does not know about page layout, B-trees etc. A Data Component (DC) knows about the physical storage structure. It supports a record oriented interface that provides atomic operations, but it does not know about transactions. Providing atomic record operations may itself involve DC-local concurrency control and recovery, which can be implemented using system transactions. The interaction of the mechanisms in TC and DC leads to multi-level redo (unlike the repeat history paradigm for redo in integrated engines). This refactoring of the system architecture could allow easier deployment of application-specific physical structures and may also be helpful to exploit multi-core hardware. Particularly promising is its potential to enable flexible transactions in cloud database deployments. We describe the necessary principles for unbundled recovery, and discuss implementation issues.
机构、总结、中文摘要均由AI分析而来，可能存在错误，请以论文正文为准。
