討論數據庫系統時，什麼構成事務層？

Question

例如，LevelDB不支持多語句事務。我在某處讀到，你將不得不在「交易層」處理這些問題。

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

Answer 1

define transactions有多種方式，並且有各種方式來實現它們。交易的共同財產是它的ACID：

• 原子性 - 全有或全無。數據庫事務的所有任務都必須完成;如果由於任何可能的原因而不完整，則數據庫事務必須中止。
• 一致性 - 可串行性和完整性。在數據庫事務之前和之後，數據庫必須處於一致或合法的狀態。這意味着數據庫事務不能破壞數據庫完整性約束。
• 隔離在執行數據庫事務期間使用的數據在執行完成之前不能被其他數據庫事務使用。因此，一個未完成事務的部分結果必須不能用於其他事務，直到事務成功提交。這也意味着事務的執行不受其他併發事務的數據庫操作的影響。
• 耐用性即使交易完成後發生系統故障，交易的所有數據庫修改都將永久生效。

事務可以有幾種狀態：

• 活動狀態：它分爲兩個階段。初始階段：數據庫事務處於此階段，而其語句開始執行。部分承諾階段：數據庫事務在其最終語句執行時進入此階段。在這個階段，數據庫事務已經完成了它的執行，但仍然有可能中止事務，因爲執行的輸出可能會暫時駐留在主內存中 - 硬件故障等事件可能會擦除輸出。
• 失敗狀態：當數據庫事務由於硬件或程序錯誤而無法繼續正常執行時，將進入失敗狀態）。
• 中止狀態：數據庫事務如果由DBMS確定失敗，則進入中止狀態。被中止的事務對數據庫不會產生任何影響，因此對數據庫所做的任何更改都必須撤消或以技術術語回退。當中止的事務已被回滾時，數據庫將返回到其一致狀態。 DBMS的恢復方案負責管理事務中止。
• 承諾狀態：在完成成功執行後，有足夠的信息寫入磁盤後，數據庫事務進入提交狀態。在這種狀態下，如此多的信息被寫入磁盤，交易產生的影響不能通過中止撤消;即使發生系統故障，當系統重新啓動時，已提交事務所做的更改也可以重新創建。

LevelDB does not support transactions，但它確實有一些ACID屬性：

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

---

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

問：

什麼會這層必須做的事務支持添加到較低級別的庫，不支持交易？

答： 這取決於你如何定義一個事務。如果你用上述屬性定義一個事務，並且如果你希望你的事務是ACID，那麼你必須弄清楚是否可以用LevelDB（大多數ACID屬性被集成），然後你必須在LevelDB上編寫一個包裝器，確保事務狀態得到正確維護。但是，我不完全確定一個包裝器本身會這樣做，所以您可能不得不真正採用源代碼並將其修改爲支持事務處理的真正。

Answer 2

鑑於你的數據庫是單線程的，你可以做到以下幾點：

1. 使用性LevelDB批處理功能：除了覆蓋舊鑰匙的，創建一個新的。還記錄密鑰的舊值和新值。

2. 如果此時數據庫崩潰，請查看日誌記錄，並通過將作爲事務一部分的鍵重新設置爲舊值來回滾事務。刪除日誌以完成回滾。

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

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

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