在談論數據庫系統時，什么構成事務層？

Question

例如， LevelDB不支持多語句事務。 我在某處讀到，您必須在“事務層”中處理那些問題。

該層必須做什么才能將事務支持添加到不支持事務的較低級別的庫中？

Answer 1

鑒於您的數據庫是單線程的，您可以執行以下操作：

1. 使用 leveldb 批處理功能：不是覆蓋舊密鑰，而是創建一個新密鑰。 還記錄鍵的舊值和新值。

2. 如果此時數據庫崩潰，請查找日志記錄並通過將作為事務一部分的鍵恢復為它們的舊值來回滾事務。 刪除日志完成回滾。

3. 如果事務已提交，則刪除舊密鑰並刪除日志條目以完成提交。

然后你有一個使用多個版本的單線程鍵/值存儲事務。

如果數據庫是多線程的，則必須使用 MVCC（請參閱 Yahoo 的 Omid、PostgreSQL、Wiredtiger、bsddb...）和諸如 Precisely Serializable Snapshot Isolation (PSSI) 之類的東西。

Answer 2

定義事務的方法多種多樣，實現它們的方法也多種多樣。 事務的一個共同屬性是它是 ACID：

• 原子性——全有或全無。 必須完成數據庫事務的所有任務； 如果由於任何可能的原因不完整，則必須中止數據庫事務。
• 一致性- 可序列化和完整性。 state 數據庫事務前后數據庫必須處於一致或合法的狀態。 這意味着數據庫事務不得破壞數據庫完整性約束。
• 隔離數據庫事務執行期間使用的數據在執行完成之前不得被另一個數據庫事務使用。 因此，在事務成功提交之前，不完整事務的部分結果不能用於其他事務。 這也意味着一個事務的執行不會受到其他並發事務的數據庫操作的影響。
• 持久性 即使在事務完成后發生系統故障，事務對數據庫的所有修改也將永久保留。

一個事務可能有幾種狀態：

• Active State ：分為兩個階段。 初始階段：數據庫事務在其語句開始執行時處於此階段。 部分提交階段：數據庫事務在其最終語句已執行時進入此階段。 在此階段，數據庫事務已完成執行，但事務仍有可能中止，因為執行中的 output 可能仍暫時駐留在主 memory 中 - 硬件故障等事件可能會擦除 output。
• Failed State : 數據庫事務進入失敗 state 當其正常執行由於硬件或程序錯誤而無法繼續進行時）。
• Aborted State ：一個數據庫事務，如果被DBMS判斷為失敗，則進入aborted state。一個中止的事務一定對數據庫沒有影響，因此它對數據庫所做的任何更改都必須被撤銷，或者用技術術語來說， 回滾。 當中止的事務被回滾時，數據庫將返回到其一致的 state。 DBMS 的恢復方案負責管理事務中止。
• Committed State ：數據庫事務在成功完成執行后將足夠的信息寫入磁盤時進入committed state。 在這個 state 中，有太多的信息被寫入磁盤，以至於交易產生的影響無法通過中止來撤銷； 即使發生系統故障，提交的事務所做的更改也可以在系統重新啟動時重新創建。

LevelDB 不支持事務，但是它有一些 ACID 屬性：

• 批量寫入是原子的。
• 一致性取決於您。
• 隔離支持有限。
• 耐用性是一個可配置的選項。

---

所以......回到你的問題：

問：

該層必須做什么才能將事務支持添加到不支持事務的較低級別的庫中？

A：這取決於你如何定義交易。 如果您使用上述屬性定義一個事務，並且您希望您的事務是 ACID，那么您必須弄清楚 LevelDB 是否可行（大多數 ACID 屬性已集成）然后您必須圍繞 LevelDB 編寫一個包裝器，以確保正確維護事務的狀態。 但是，我不完全確定單獨的包裝器是否可以做到這一點，因此您可能必須實際獲取源代碼並對其進行修改才能真正支持事務。