這是我參與8月更文挑戰的第10天,活動詳情查看:8月更文挑戰算法
正如這篇文章的標題所問,什麼是事務數據庫?簡短的回答是,它是一個支持全有或全無數據操做的存儲系統,一般稱爲事務。這意味着,若是要執行的某些可能很長的數據操做列表(例如,建立、更新或刪除信息)的任何子集因任何緣由失敗,則全部操做都將被放棄,而且數據庫將恢復到任何操做以前的狀態。的行動開始了。數據庫
此功能提供了可靠的信息存儲和處理,由於它能夠防止錯誤的數據操做,從而確保數據庫始終處於正確狀態。事務數據庫爲數據完整性提供保證,即便在系統故障的狀況下也是如此,這對於許多用例來講多是關鍵任務。安全
考慮一個銀行客戶使用移動設備上的應用程序將資金從一個賬戶轉移到另外一個賬戶的快速而常見的示例。完整且正確的交易須要借記來源賬戶和貸記目的地賬戶。服務器
可是,若是斷電,數據庫服務器後原點賬戶還沒有扣除以前的目標帳戶貸記?一個真正的事務數據庫確保在這種狀況下整個事務的第一部分被取消(或「回滾」),由於第二部分沒有經過,儘管發生故障,數據庫仍保持正確和一致的狀態。markdown
在本文中,咱們將更詳細地研究數據庫事務及其重要性,解釋「ACID 合規性」的四個要素及其重要性,討論當數據和事務分佈在現代系統中時維護這些要素所涉及的常見困難,並提供一些關於選擇知足您需求的事務性數據庫系統的具體建議。網絡
簡而言之,數據庫事務是由數據庫管理系統 (DBMS) 針對給定數據庫執行的工做單元,執行數據操做並更新各類存儲介質上的底層文件。事務數據庫將確保此類工做單元是全有或全無的,由於任何操做中的任何失敗都將致使全部操做暫停和回滾,使數據庫處於事務開始以前的狀態。架構
使用事務數據庫有兩個主要緣由,第一個是它使工做單元在全部狀況下均可靠。回顧一下咱們的銀行業務示例,客戶能夠放心,當他們的錢從原始帳戶中扣除時,將記入目的地帳戶。若是在此過程當中出現任何問題(例如,網絡故障、服務器故障等),客戶但願他們的賬戶保持不變,而不是簡單地因偶然事件而賠錢。分佈式
第二個緣由是咱們所描述的事務數據庫始終處於正確且一致的狀態,而無論所涉及的全部技術可能發生何種故障。沒有人願意將信息存儲在一個系統中,該系統的數據可能會由於容許無效操做而變得不連貫,或者在服務器宕機時可能會丟失信息。固然,並不是每一個用例都是關鍵任務,但不少都是,在這些狀況下,事務數據庫能夠提供巨大的業務價值。svn
固然,並非每一個數據庫系統本質上都是事務性的。一些系統只專一於記錄丟失的信息或不須要支持事務功能的信息。在考慮您的用例時,重要的是密切關注您須要這些功能的程度,並將您的指望與潛在數據庫系統遵照事務數據庫原則的程度相匹配。post
ACID 是「Atomicity、Consistency、Isolation 和 Durability」的首字母縮寫,它是一組確保數據庫事務可靠、正確處理的原則。下表解釋了這四個不一樣元素所涉及的內容。
元素 | 意義 |
---|---|
原子性 | 事務中的全部數據操做以全有或全無的方式完成或回滾。 |
一致性 | 數據庫中的信息在全部狀況下都必須在語義上有意義(例如,在沒有有效父級的狀況下不插入子數據,必填字段沒有空值等) |
隔離 | 每一個事務必須獨立於同時進行的任何其餘事務運行;即,不能容許信息從一項交易「泄漏」到另外一項交易。 |
耐用性 | 任何成功完成的交易都會以不可磨滅的方式記錄下來,這意味着它的數據不會在軟件甚至硬件故障的狀況下丟失。 |
讓咱們考慮一個更復雜的例子來講明爲何 ACID 保證很重要。想象另外一種常見的狀況,其中兩我的 A 和 B 正在爲電影院的同一場演出預訂同一排的座位。A 只預訂了一個座位,而 B 則試圖爲家庭出遊預訂整排。
若是A先預訂了座位,那麼B的交易就會失敗,由於網上購物車中的一個座位已經被預訂了,不能重複預訂。這說明了原子性,由於 B 人的數據操做之一失敗了,他們都作了,以及一致性,由於系統不會容許無心義的數據,例如兩我的保留相同的座位。
只有當 A 的預訂成功完成並寫入數據庫時,B 的交易纔會被取消。然而,在這種狀況發生以前,隔離的特性是容許兩我的同時嘗試對同一個席位進行交易,確保雙方都將有爭議的席位視爲可用,直到它被實際保留。
最後,即便在 A 成功預訂座位後整個預訂系統崩潰,持久性確保在從新啓動時正確的數據仍然存在。這使得 A 能夠根據須要打印票並享受演出,不管在交易正確完成後發生什麼系統故障。
現代應用程序在本質上愈來愈分散,一般在全球範圍內可用,這使得事務數據庫的問題變得更加困難。緣由是 ACID 保證對於分佈式系統與在單個服務器上運行的單個數據庫軟件同樣重要,可是涉及多個服務器或節點會使問題顯着複雜化。
想一想看。當單個數據庫軟件能夠「決定」在第一個事務失敗後當即取消事務中的全部其餘數據操做時,這很簡單。當數據庫軟件在分散在世界各地的數十個(甚至數百個)節點上運行時,這徹底是另外一回事。任何這些服務器上任何數據操做的任何元素的任何故障都要求必須取消整個事務並在任何地方安全回滾。相似地,即便事務成功,整個系統也必須確保全部操做都是正確且持久的,不管哪一個或哪些服務器執行它們。
實際上,分佈式事務數據庫很難正確實現,但幸運的是一些供應商作到了。例如,因爲其架構和數據存儲算法,Fauna可以提供嚴格可序列化、外部一致的事務。
與其餘系統不一樣的是,Fauna 不須要全部服務器之間嚴格的物理時鐘同步來提供一致性,這避免了副本服務器之間一般的距離限制,所以對於以典型的全球 Internet 延遲在世界各地進行部署是實用的。當系統時鐘或網絡流量相差幾毫秒時,確實須要同步的方法可能會致使故障,而 Fauna 更寬鬆的要求則不會遇到此類問題。
這是可能的,由於 Fauna 提供了受 Calvin 啓發的事務引擎,這是一種跨分區數據庫系統實現快速分佈式事務的方法。Fauna 事務引擎能夠經過其分佈式事務協議實現「沒有時鐘的一致性」 。實際上,在任何數據庫寫入以前,Fauna 會預先決定事務應以何種順序執行。而後,Fauna 執行引擎以這樣一種方式處理它們,即最終結果與按照該順序一次處理一個相同。
實際上,您能夠得到在多臺服務器上並行執行的分佈式事務的全部速度和功能,同時享受事務數據庫的全部數據優點,就好像它們在單個服務器上串行執行同樣。
Fauna 以徹底分佈式的方式將非事務性數據庫的全部靈活性和性能與事務性數據庫的關係查詢和功能以及 ACID 保證相結合。事實上,因爲 Fauna 處理其分佈式事務的方式,用戶能夠避免其餘系統可能發生的那種數據異常。經過不限制鍵、文檔或分區數量的嚴格可序列化的多區域事務,能夠防止不朽寫入、陳舊讀取、因果反轉和其餘此類問題。
還值得注意的是,Fauna不是一般託管的「數據庫即服務」(DBaaS),甚至不是一些集羣雲產品,二者都須要管理。相反,Fauna 是一個真正的「數據 API」,這意味着開發人員能夠根據須要簡單地進行調用,而無需花時間擔憂配置或擴展,具備事務數據庫和 ACID 合規性的全部好處。
由於它是一個真正的數據 API,因此 Fauna 沒有全部常見的配置和配置問題,而且能夠當即做爲無服務器實用程序使用。開發人員只須要一個賬戶便可開始使用,無需支付任何費用並提供豐厚的起步津貼。沒有常見的頭痛問題:沒有配置實例,沒有普遍的配置等。
在本文中,咱們檢查了事務數據庫,解釋了它們提供的 ACID 保證,說明了它們在關鍵任務用例中的價值,討論了現代對分佈式事務的需求如何使狀況複雜化,並提供了一些具體的建議,以輕鬆得到 ACID合規的數據優點。
最後,Fauna 經過輕鬆分佈式數據庫事務、自動配置和輕鬆擴展來提供全部價值。它能夠免費註冊,易於上手,並提供清晰簡單的訂價——只需爲您實際使用的內容付費。若是您認爲 Fauna 能夠管理您的數據需求,爲何不當即嘗試一下呢?
以上就是本篇文章的全部內容了
我已經寫了很長一段時間的技術博客,這是個人一篇技術文章/教程。但願大家會喜歡!這裏彙總了個人掘金博客主頁:海擁
若是你真的從這篇文章中學到了一些新東西,喜歡它,收藏它並與你的小夥伴分享。🤗最後,不要忘了❤或📑支持一下哦。