事件溯源將顛覆關聯式資料庫！ - Remy

大多數學習事件溯源的人都是將其作為應用程式設計模式，當然這是事實。但是，使用事件溯源的主要原因是該模式啟用了事件資料模型。

我很早在80年代中期關係型資料開始興起時就在關係型資料庫領域工作。關聯式資料庫採用的一個主要推動力是關係（相對於層次結構）不需要您鎖定查詢訪問模式。

當業務需求發生變化時，關係型模型提供了保證，您可以通過原始設計中未曾預期設計的方式查詢資料。技術長，架構師，開發人員甚至執行長都得到了資訊，大多數人都知道企業的成敗取決於其應對變化的能力。

事件資料模型（底層的事件儲存和事件源）使我想起了關係引發的思想上的同一型別的變化。事件資料模型又向前邁進入了一個更基本的核心資料模型元件。

事件資料模型將狀態的更改作為基本資料模型，然後允許您“投影”到需要在查詢端利用該資料的任何其他資料模型，可以是關係型，文件型，圖形型（隨您命名）。當業務需求更改時，您可以更改或重新生成查詢模型以滿足您的需求。

關係資料模型及其所有功能都是有損失的。它捕獲的資料可證明雖是可查詢的，但是它的重點是保持資料的當前狀態。刪除和更新後就丟失原來資料..一旦資料消失，就無法查詢。

關係資料模型基礎狀態的更改“摺疊”為特定的當前狀態資料模型，該模型靈活但並未針對查詢或寫入進行特別優化。

關係型“標準化”資料模型會將邏輯業務實體分解為多個表，必須將它們同時寫入並從中讀取以獲取資料……正如我們中許多人所知道的，當需要常見查詢時會進行10個多表聯接join。

事件儲存和事件資料模型代表著關注點的分離，事件儲存專注於優化僅將事件流追加並“實時”提供給那些最適合您的用例的查詢引擎。

事件儲存資料庫和事件資料模型在某些方面看似新穎且具有革命性，但它們仍在不斷髮展。大多數資料庫技術以及分散式共識演算法都將“日誌 log”作為其基礎資料結構。

事件儲存將這種日誌開啟開放，並建議將其作為資料庫本身。

事件資料模型日趨成熟的一個標誌是事件資料設計方法論從分析到實施（事件風暴，事件建模等）的出現。

從另外一個方面看，事件資料模型在db級別實現的基礎事件往往與設計工件同構。換句話說，資料庫中的事件往往代表業務可理解的事件和語言。這可能會產生深遠的影響，您的系統監視也將是對業務監視。

事件儲存有潛力成為下一代可操作的“真相之源”，事務性資料庫技術。它們具有一流的流API的無損特性，使它們處於多種巨集觀趨勢的匯合處，例如（微）服務，強大的分析和整合技術的爆炸式增長，區塊鏈和AI。

事件源作為應用程式開發模式是用於構建現代系統（尤其是分散式非同步系統）的強大工具。這是一個重要的考慮因素，會讓您決定選擇事件來源模式。但是，還有一個強有力的考慮因素，可以說是最重要的，它是基礎資料的價值和事件資料模型本身。

banq注：eventsourcing = domanEvents + eventstorming + eventModel + blockchainData + dataScience！

相關：

由亞馬遜內部禁止使用SQL資料庫引出的想法 

arxiv文獻：事件溯源系統及其圖式演變的經驗表徵-行業經驗教訓