蘋果FoundationDB事務宣言

什麼是事務？
事務是一組資料庫讀寫操作，它能夠將一個涉及一些關鍵屬性的操作過程作為一個單元操作進行處理。首先，事務中的所有讀取都會立即看到相同的資料庫快照（但是不會看到其他同時執行的事務實現的資料更改結果）；其次，事務中的寫入操作要麼全部成功要麼全部失敗。（失敗可能是由網路連線丟失引起的。）最後，事務成功（提交）後，寫入結果將永久儲存。事務的這些屬性（稱為原子性、一致性、隔離性和永續性）是“ACID”保證的基礎。我們FoundationDB認為支援ACID事務不僅僅是一個很好的附加功能，而且事務對於以高效地、以簡單地方式構建穩健系統是至關重要。

大家都需要事務
每個需要支援併發客戶端的應用程式都應該使用具有ACID屬性的事務來構建。事務是處理併發性的最簡單和最強大的程式設計模型，隨著NoSQL技術的成熟，它將扮演越來越重要的角色。

一個常見的誤解是，事務僅適用於處理金融交易的電子商務或銀行業務。但是，事務的力量來自於他們對應用程式構建的工程影響，而不是來自任何特定應用程式的細節。由於ACID屬性，可以組合事務以建立新的抽象，支援更高效的資料結構，並執行完整性約束。因此，使用事務構建應用程式比任何其他方法都更容易，更可靠，更具可擴充套件性。

也許您的系統設計上的平衡折衷迫使您放棄事務的優勢以獲得速度，可擴充套件性和容錯性。以這種方式構建的系統通常很脆弱，難以管理，並且通常幾乎不可能適應不斷變化的業務需求。這種犧牲事務的做法很少會帶來收益，特別是如果競爭者的方案可以提供大規模的事務完整性。

事務使併發性變得簡單
只要多個客戶端、使用者或應用程式的某些部分同時讀取和寫入相同的資料，就會產生併發。事務使開發人員可以輕鬆管理併發。這通常可以透過事務很簡單地實現，主要是由事務的特性隔離性完成，即ACID中的“I”。當一個系統保證事務是完全隔離的（稱為“可序列化”）時，開發人員可以將每個事務看作是按順序執行的，儘管它可能實際上是同時執行的。來自不同事務的操作之間潛在相互影響的推理與擔心的負擔就沒有了。

略勝於無：本地交易
一些系統為有限的一組預定義操作提供ACID事務，通常受到資料模型結構的限制。例如，文件資料庫可以允許在事務中更新單個文件。

但是，事務的真正威力來自於應用程式開發人員可以透過任何一組資料元素來定義它們。使用鍵值儲存的應用程式開發人員應該能夠定義讀取和寫入任意數量的鍵值對的事務。當開發人員可以自由定義事務而沒有任何限制時，他們可以使用事務作為應用程式的基本構建模組。

事務啟用抽象
應用程式定義的事務是可組合的。隔離性與原子性（ACID中的“A”）一起確保一個事務的執行不會影響另一個事務的可見性。這種保證使事務可以相互組合，從而可以將它們組合起來以建立新的抽象。抽象可以分層封裝。例如，一個常見的抽象是維護一個索引以及主資料，以便快速查詢匹配某個約束的資料項。在任何鍵值儲存中，只要資料第二個副本（指定期望的索引欄位作為key）即可輕鬆實現此功能。 但是，併發更新資料可能會使這個簡單的設計複雜化。如果沒有事務，很難確保隨著資料的變化，資料和索引都會一致地更新。透過事務處理，索引層可以在一個事務中更新資料和索引，從而保證資料和索引的一致性並允許強大的抽象。

事務允許簡單高效地構建抽象，提供高度可擴充套件的功能來支援多種資料模型。針對分層文件，列導向資料或關係資料進行最佳化的資料模型都可以在有序的鍵值儲存之上分層實現。在大多數情況下，高階模型中的單個資料物件將對映到多個鍵值對。事務透過以原子單位包裝多個鍵值更新來可靠地實現這些對映。

事務處理實現高效的資料表示
事務的好處不只是可以更靈活選擇高階資料模型，它們還可以在指定的模型中實現更高效的資料表示。例如，想想在面向文件的資料庫中常用的嵌入資料的設計模式。（來自關聯式資料庫領域的人可能會認為這是非規範化）。在嵌入模式中，您將資料巢狀在單個文件的層次結構中（通常是複製它），而不是儲存對其他可共享文件的引用。

採取嵌入做法往往是因為缺乏全域性事務支援。由於大多數面向文件的資料庫只允許對單個文件進行原子操作，因此開發人員必須將資料“擠”到單個文件中以啟用原子更新。生成的嵌入資料文件將更大，更復雜，並且通常訪問和更新的效率更低。

透過事務處理，不需要使用嵌入這種方式來實現原子更新。可以對資料元素進行建模，以最佳化訪問效率，並在適當的時候使用多個文件，並在一個事務中進行更新以保證一致性。而且，資料可以被多個客戶共享並且同時更新。同樣，事務提供安全管理共享狀態所需的併發控制。

事務可實現靈活性
支援重要業務功能的大多數應用程式都會遇到需求變化 （當然，他們通常需要做更多的事情，而不是更少！）您可能會想把事務完整性看作是一個很好的功能，但這對於您的應用程式來說並不重要。可以肯定的是，透過仔細設計特定的簡單訪問模式的資料模式，可以構建許多應用程式以避免全域性事務的需要。但是，當這些應用程式發展時，靈活地修改資料模型和全域性事務的能力可以使簡單更改和重新設計之間的區別變得容易。

想象一下，您可以執行一個Web應用程式，在該應用程式中使用者既可以生成帖子，也可以接收其他使用者的帖子 所有帖子都儲存在後端資料庫中。管理層要求您建立一個用於做基本分析的儀表板。雖然您的資料儲存是可讀寫的，但儀表板最初旨在執行只讀查詢。這些資料僅用於分析，因此如果結果有時會過時，則使用者介面中沒有人會注意到。總的來說，你不需要事務。您將一些優秀的資料視覺化放在一起，讓您的公司以新的方式分析和檢視帖子。

另一方面，儀表盤證明非常受歡迎。不利的一面是，您開始聽到對新功能的需求：使用者希望儀表板支援使用分析找到的帖子的編輯和稽核。另外，廣告投放部門希望透過API訪問儀表板資料來驅動他們的計費系統。您現在有一種情況，儀表板的簡單隻讀模型已經消失，您的新API需要能夠為其提供的結果提供強有力的可靠性保證。

這種需求的演變是一種自然且頻繁發生的模式。事務處理能夠輕鬆新增這些功能。

事務並不像您想象的那麼昂貴
您可能不願意使用事務，因為認為這是基於一種在效能和事務之間取捨的技術權衡，特別是針對NoSQL資料庫所針對的各種高效能應用程式。但是，當您更仔細地檢查這種權衡時，使用者的成本是非常低。（但是，資料庫工程師的成本相當高;分散式事務系統難以建立！）

效能和可擴充套件性？
我們知道對支援事務的系統實際上是沒有可擴充套件性或效能的限制的。當朝著NoSQL資料庫的方向發展時，早期的系統（例如Google Bigtable）採用了最小化的設計，並將重點放在可伸縮性和效能上。從關聯式資料庫中熟悉的特點已經大量流失，並且總是假設放棄的特點對於追求可伸縮性和效能的目標是不必要的或者甚至是有害的。

這些設想其實是錯誤的。支援事務是工程努力的問題，而不是設計領域的折衷結果，這一點正變得日益明顯。維護事務完整性的演算法可以像許多其他問題一樣進行分發和擴充套件。事務完整性確實出現在CPU成本上，但根據我們的經驗，成本低於總系統CPU的10％。這是事務完整性的一個小代價，可以很容易地在其他地方得到補償。

寫延遲？
事務保證中有寫入的永續性（ACID中的“D”）。這個保證伴隨著寫入延遲的增加。永續性意味著已經提交的寫入必須保持提交狀態，即使後續遭遇硬體故障。因此，永續性是容錯的重要組成部分。不支援永續性的NoSQL系統在容錯方面必然較弱。由於真實容錯的重要性，持久事務所需的寫入延遲通常是值得的。對於那些要求儘量減少寫入延遲的應用，可以在不犧牲“ACI”屬性的情況下關閉耐久性。

事務是NoSQL的未來
隨著NoSQL資料庫越來越廣泛地用於各種各樣的場合，構建於其上的更多應用程式可以應對大量客戶端的併發。如果沒有足夠的併發控制，所有傳統的併發問題都會重新出現，並給應用程式開發人員帶來沉重的負擔。ACID事務透過提供可序列化的操作來簡化併發性，這些操作可以用來正確設計應用程式軟體。如果您構建的應用程式需要擴充套件並且您沒有事務，那麼您最終會被毀掉。幸運的是，NoSQL資料庫的可伸縮性，容錯性和效能仍然可以透過事務來實現。隨著技術的成熟，對事務的選擇最終將不是設計基本權衡問題，而是實施工程的問題。

Transaction Manifesto — FoundationDB 5.1

相關文章：

YugaByte DB：高效能的分散式ACID事務的開源資料庫

蘋果開源其分散式強一致性資料庫FoundationDB