ACID 和 BASE 資料庫之間有何差異？
ACID 和 BASE 是資料庫交易模型，可決定資料庫組織和操控資料的方式。在資料庫語境中，交易是資料庫視為單一工作單位的任何操作行為。交易必須全部執行成功，才能保持資料庫一致。舉例來說，當您從一個銀行帳戶轉帳到另一個銀行帳戶時，錢必須離開您的帳戶，且必須增加至第三方帳戶中。若未執行這兩個步驟，交易便無法稱之為完成。
ACID 資料庫會讓一致性優先於可用性 - 如果交易中的任何步驟發生錯誤，即整個交易失敗。反之，BASE 資料庫會讓可用性優先於一致性。使用者可以暫時存取不一致的資料，且不會造成交易失敗。資料一致性可以實現，但非立即實現。
為什麼 ACID 和 BASE 十分重要？
現代資料庫是分散式資料儲存區，可在經網路連接的多個節點上複製資料。其允許使用者在單一交易中執行多個資料操作，例如讀取和寫入。使用者希望在交易結束時，所有節點之間的資料可維持一致。然而，在理論電腦科學中，布魯爾定理（亦稱為 CAP 定理）認為任何分散式資料儲存區僅能提供以下三個保證中的兩個：
- 一致性：每個讀取操作皆會收到最近更新的資料或錯誤。
- 可用性：每個資料庫請求皆會收到成功回應，但不保證其中包含最近更新的資料。
- 分區容限：儘管分散式節點之間的訊息已中斷或延遲，系統仍會繼續運作。
例如，若客戶在電子商務網站上將商品新增至購物車，則所有其他客戶都應看到產品庫存量的減少程度。若客戶將最後一件商品新增至購物車中，所有其他使用者應看到該商品為缺貨。若交易中有任何操作發生失敗，則資料庫設計師必須有所選擇。資料庫可執行以下其中一項操作：
- 取消交易並傳回錯誤，降低可用性，但確保一致性。在新增至購物車成功之前，客戶將無法將商品新增至購物車，或其他客戶將無法為所有產品載入詳細資訊。
- 繼續操作並藉此提供可用性，但風險將不一致。客戶將商品新增至購物車，但其他客戶會看到不正確的庫存量，至少暫時會如此。
在部分使用案例中，一致性十分重要，因此 ACID 資料庫廣受喜愛。但是，也有一致性並非關鍵要素的其他使用案例。例如，在您於社群媒體上接受好友請求時，其他使用者是否會暫時在您的社群媒體個人檔案中看到不正確的朋友數量，便不甚重要。但是，您不會想在資料排序時失去存取社群媒體動態的權限。在此情況下，BASE 便變得十分重要。
主要原則：ACID 與 BASE 的比較
ACID 和 BASE 是不同資料庫屬性的縮寫詞，代表資料庫在線上交易處理期間的行為方式。
ACID
ACID 代表原子性、一致性、隔離性和耐久性。
原子性
原子性可確保單一資料庫交易中的所有步驟皆完成或恢復到原始狀態。例如，在預訂系統中，須在單一交易中完成預訂座位和更新客戶詳細資訊等兩項任務。您無法為不完整的客戶個人資料預訂座位。若交易中有任何部分失敗，則系統將不會更改資料。
一致性
一致性可確保資料符合預先定義的完整性限制和業務規則。即使有多個使用者同時執行相似操作，系統仍維持所有人的資料一致性。例如，一致性會確保在從一個帳戶轉移資金至另一個帳戶時，交易前後的總餘額維持不變。若帳戶 A 有 200 USD，帳戶 B 有 400 USD，則總餘額為 600 USD。在 A 將 100 USD 轉移至 B 後，A 有 100 USD，B 有 500 USD。總餘額仍然是 600 USD。
隔離
隔離會確保在上一筆交易完成後，才開始進行存取特定記錄的新交易。其會確保並行交易不會互相干擾，藉此維持其正在按順序執行的錯覺。另一個範例是多使用者庫存管理系統。若有一位使用者更新產品數量，在確認更新之前，存取相同產品資訊的另一個使用者將看到一致且受隔離的資料檢視，不會受持續更新影響。
耐久性
即使系統發生故障，耐久性會確保資料庫維持所有已提交的記錄。其會保證在 ACID 交易經確認後，所有變更皆為永久性變更，且不受後續系統故障影響。例如，在訊息傳送應用程式中，在使用者傳送訊息並收到成功傳送確認時，耐久性屬性會確保訊息永不遺失。即使應用程式或伺服器發生故障，依然不會有所改變。
BASE
BASE 代表基本上可用、軟性狀態，和最終一致性。該首字母縮略詞強調 BASE 與 ACID 相反，如同其化學當量一樣。
基本上可用
基本上可用是指使用者隨時都可並行存取資料庫。單一使用者無需等待其他人完成交易，便可更新記錄。例如，在電子商務平台上的流量突然驟增時，系統可能會優先提供產品清單和接受訂單。即使更新庫存數量會有一點延遲，但使用者仍可繼續結帳商品。
軟性狀態
軟性狀態是指資料可能具有臨時或暫時狀態，即使沒有外部觸發條件或輸入，這些狀態也可能會隨時間變化而改變。其會描述多個應用程式同時更新記錄時的過渡狀態。僅在所有交易完成後，記錄的值最終才會完成。例如，若使用者編輯社群媒體貼文，則其他使用者可能無法立即看到該變更。但稍後，即使沒有使用者觸發，該貼文仍會自行更新（反映較舊的變更）。
最終一致性
最終一致性表示在所有並行更新完成後，記錄將達一致性。此時，查詢記錄的應用程式將會看到相同的值。例如，試想一個多個使用者可以同時編輯文件的分散式文件編輯系統。若使用者 A 和使用者 B 同時編輯文件的相同區段，則在變更受到傳播和同步之前，兩者的本機複本可能會暫時不同。但是，隨時間變化，系統會利用傳播和合併不同使用者所做之變更來確保最終一致性。
主要差異：ACID 與 BASE 的比較
在 ACID 和 BASE 資料庫交易模型之間進行選擇時，會需要有所取捨。
擴展
由於 ACID 資料庫交易模型著重於一致性，因此較難以擴展。在任何時候，任一記錄僅允許一筆交易，這使水平擴展變得更具挑戰性。
或者，由於 BASE 資料庫模型無需嚴格維持一致性，因此您可以將其水平擴展。在資料庫叢集中新增多個節點可讓 BASE 模型改善其資料可用性，這正是驅動資料庫架構的原則。
靈活性
在處理資料時，ACID 資料庫較不具有彈性。其必須保證立即一致性，若 ACID 資料庫發生斷網或斷電，ACID 資料庫可能會限制存取部分應用程式。同樣地，如果其他軟體模組正在處理特定記錄，則應用程式必須等待其改為更新資料。相反地，BASE 資料庫更具有彈性。BASE 允許應用程式在可用時修改記錄，而非嚴格限制。
效能
在處理龐大資料量或並行處理請求時，ACID 資料庫可能會發生效能問題。由於系統會以嚴格的順序處理資料，因此每筆交易都會產生延遲，這會影響所有存取記錄的應用程式。
相反地，存取 BASE 資料庫的應用程式則可隨時處理記錄。這可減少過多的等待時間，並改善資料庫輸送量。
同步
ACID 資料庫需要同步機制來承諾交易中的變更，並將其反映在所有相關聯的記錄中。同時，其必須鎖定其他方的特定記錄，直到交易完成或放棄為止。而 BASE 資料庫則會在不鎖定記錄的情況下執行，最終同步記錄，且無需保證時間。在使用 BASE 資料庫操作時，開發人員知道在處理特定記錄時可能會發生不一致情況，並在應用程式中採取必要的預防措施。
使用時機：ACID 與 BASE 之比較
儘管有所差異，但 ACID 和 BASE 資料庫系統在不同的應用程式中皆有所相關。針對需要資料一致性、可靠性和可預測性的企業應用程式，ACID 會是理想選擇。例如，由於資料完整性是具有最高優先性，因此銀行會使用 ACID 資料庫來儲存客戶交易。而 BASE 資料庫則是針對結構鬆散但大量的資料執行線上分析處理的較佳選擇。例如，電子商務網站會使用 BASE 資料庫來更新經常變動的產品價格。在此情況下，與允許所有客戶即時取得產品價格相比，定價準確性便較不重要。
資料庫可以同時是 ACID 和 BASE 嗎？
根據 CAP 定理，資料庫可滿足一致性、可用性和分區容限等三項保證中的兩項。ACID 和 BASE 資料庫模型皆提供分區容限，這表示其無法同時保有高度一致性和始終可用性。因此，資料庫會依賴 ACID 或 BASE，但不能同時依賴兩者。例如，SQL 資料庫為根據 ACID 模型進行結構化，而 NoSQL 資料庫則使用 BASE 架構。然而，部分 NoSQL 資料庫可能會顯示特定 ACID 特徵，但無法作為與 ACID 相容的資料庫進行操作。
差異摘要：ACID 與 BASE 的比較
| ACID |
BASE |
|
| 擴展 |
垂直擴展。 |
水平擴展。 |
| 靈活性 |
不太靈活。處理時，封鎖其他應用程式的特定記錄。 |
比較靈活。讓數個應用程式同時更新相同的記錄。 |
| 效能 |
處理大量資料時效能會降低。 |
能夠以高輸送量處理大型非結構化資料。 |
| 同步 |
是。同步時會延遲。 |
資料庫層級無法同步化。 |
AWS 如何支援您的 ACID 和 BASE 資料庫要求？
AWS 雲端資料庫提供每種類型的資料使用案例一系列 ACID 和 BASE 資料庫服務。組織在 AWS 上部署資料庫，藉此節省佈建、擴充和管理資料儲存基礎架構的時間。例如：
- Amazon DynamoDB 是快速的 BASE 資料庫服務，可提供雲端應用程式的毫秒資料處理。
- Amazon MemoryDB for Redis 是另一個 BASE 資料庫，讓開發人員為網頁和行動應用程式部署耐用且高可用性的 Redis 資料庫。
- AWS RedShift 是 ACID 雲端資料倉儲，可讓您針對商業智慧使用案例執行複雜的 SQL 分析查詢。
立即建立帳戶，開始使用 ACID 和 BASE 資料庫。
