公司如何從資料庫轉移到事件流，以及為什麼事件流本身不足以支援您的應用程式

> Provided By Author

當我們考慮資料時，我們經常認為資料可以使人類獲得洞察力，從而做出更好的決策。因此，存在諸如資料庫之類的應用程式來與UI應用程式互動以瞭解當前狀態。

但是，資料可以幫助我們做出更好的決策，並幫助其他軟體做出更好的決策，從而將人員從系統的關鍵路徑中剔除。

業務變得越來越自動化-業務流程變得更像自動駕駛儀。

我們還開始看到許多應用程式，其中使用者介面是整個程式包的較小部分。我們看到公司創造了為終端使用者和人類服務的軟體，並開發了與另一個系統對話的系統。

當我們考慮資料管理系統時，有兩件事：流處理和資料庫。瞭解兩者之間的差異可以幫助我們瞭解如何為自己建立更好和有效的系統。

主動和被動資料

資料庫和流處理的相似之處在於它們是儲存資料的容器。但是，它們的資料移動方式不同。

如果要儲存大量資料以儲存資料庫所累積的記憶體，則將使用Cassandra。如果要儲存包含實體之間關係的資料，則可以使用Neo4J之類的圖形資料庫；如果您想擁有主動查詢功能，則可以使用彈性搜尋。

該資料庫為我們有關資料的問題提供了答案。它們被構建為與包含UI的使用者互動。因此，儲存在該資料庫中的資料是被動的，它等待您對它們進行一些處理，而我們對它們進行的查詢是主動的。如果我們（人類）在特定時間停止與資料庫進行互動，那麼它將無濟於事。

另一方面，流處理是非同步的。他們的終端使用者不是我們（人類），而是其他軟體。它們也像資料庫一樣儲存資料，但是資料是活動的。通常觸發的操作基於資訊本身。它們幫助我們在系統中自動化流程。換句話說，查詢（操作）被動地等待被觸發。

您去過哪裡與現在去過哪裡

該資料庫可幫助我們回答有關我們處於應用程式當前狀態的位置的問題。資料庫表表示單個時間點的當前狀態。您不知道以前發生了什麼。一個英語語法的比喻將資料庫表更像一個名詞。它有助於告訴您當前的位置。

另一方面，事件流更像動詞。事件流回答了狀態發生的歷史。它記錄您手機中的移動，滑鼠懸停或訂單進度。它將每個動作記錄到事件中，可以及時回放。您會獲得有關發生的更多資訊。如果是國際象棋遊戲，您可以知道對手的舉動是否明智。

事件流中的每個事件都像一個事實。如果您訂購商品而要取消。系統將取消狀態附加在訂單狀態之上-您可以倒回歷史記錄以檢視已完成的操作。它就像一個分類帳。只追加的好處之一是因為我們與之互動的資料快速移動。到您要更新當前狀態時，另一個服務已經使用了它並執行了一些操作。因此，它需要建立一個補償事件鏈，以將所有這些動作傳播到其訂戶。

資料庫和事件流服務於具有不同目的的應用程式，這些應用程式具有不同的受眾。對於資料庫，我們（人類）是其終端使用者。因此，將資料庫設計為同步，被動資料並將其標記為單個真值源是有意義的。對於事件流，終端使用者不是人類，而是軟體。如果終端使用者不是人類，我們可以利用非同步性來最佳化我們的資源。資料成為觸發其他軟體執行特定操作的資料。

儘管事件流和資料庫在不同的用例中表現不同，但是團隊不需要採用任何一種。更多的應用程式需要流和資料庫，以更好地瞭解其內部系統。這意味著我們在需要處理同步和非同步的現代應用程式中會看到更多。因此，更多的企業應用程式使用面向流的資料庫的混合方法。有幾個活動資料庫，例如MongoDB，CouchbaseDB和RethinkDB。也有可以用作資料庫表的流處理器，例如Flink和Hazelcast Jet。無論您的應用程式使用哪種混合方法，瞭解它們之間的差異都可以幫助我們瞭解擁有我們系統之一的體系結構的含義。

資源資源在資料庫之外，在流處理器之外：資料管理的下一步是什麼？影片版本

最初在https://edward-huang.com上釋出。