如何在組織中共享數據

Question

組織在許多部門和應用程序之間共享關鍵數據有哪些好方法？

舉個例子，假設有一個主應用程序和數據庫來管理客戶數據。 組織中有十個其他應用程序和數據庫讀取該數據並將其與自己的數據相關聯。 目前，這種數據共享是通過混合數據庫（DB）鏈接，物化視圖，觸發器，登台表，重新鍵入信息，Web服務等完成的。

有沒有其他好的方法來共享數據？ 而且，您的方法與上述問題相比如何：

重復數據

容易出錯的數據同步過程

緊密耦合與松散耦合（減少依賴性/脆弱性/測試協調）

建築簡化

安全

性能

定義良好的接口

其他相關問題？

請記住，共享客戶數據的使用方式很多，從簡單的單記錄查詢到復雜的，多謂詞，多排序，與存儲在不同數據庫中的其他組織數據的連接。

感謝您的建議和意見......

Answer 1

我相信你看到了這個，“它取決於”。

這取決於一切。 與部門A共享客戶數據的部門A共享客戶數據的解決方案可能完全不同。

多年來我最喜歡的概念是“最終一致性”的概念。 這個詞來自亞馬遜談論分布式系統。

前提是雖然分布式企業中的數據狀態現在可能不完全一致，但它“最終”將是。

例如，當客戶記錄在系統A上更新時，系統B的客戶數據現在已過時且不匹配。 但是，“最終”，來自A的記錄將通過某個過程發送給B. 所以，最終，這兩個實例將匹配。

當您使用單個系統時，您沒有“EC”，而是擁有即時更新，單一的“事實來源”，以及通常用於處理競爭條件和沖突的鎖定機制。

您的操作能夠使用“EC”數據的能力越強，分離這些系統就越容易。 一個簡單的例子是銷售使用的數據倉庫。 他們使用DW來運行他們的日常報告，但他們不會在清晨運行他們的報告，他們總是查看“昨天”（或更早）的數據。 因此，DW不需要與日常運營系統完全一致。 對於一個進程來說，完全可以接受，比如說，關閉業務，並在一個大型的單一更新操作中大量移動日期交易和活動。

您可以看到此要求如何解決許多問題。 事務數據沒有爭用，不用擔心某些報告數據會在累積統計數據的過程中發生變化，因為報告對實時數據庫進行了兩次單獨的查詢。 白天不需要高細節聊天來吸收網絡和CPU處理等。

現在，這是EC的極端，簡化和非常粗略的例子。

但考慮像谷歌這樣的大型系統。 作為搜索的使用者，我們不知道Google收集搜索結果的時間或時間長度，以及搜索頁面上的搜索結果。 1ms的？ 1秒？ 10秒？ 10小時？ 如果您使用Googles West Coast服務器，您可以很容易地成像，如果您使用東海岸服務器，您可能會獲得不同的搜索結果。 這兩個實例在任何時候都不完全一致。 但在很大程度上，它們大多是一致的。 而對於他們的用例，他們的消費者並沒有真正受到滯后和延遲的影響。

考慮郵件。 A想要向B發送消息，但在此過程中消息通過系統C，D和E進行路由。每個系統都接受該消息，承擔完全的責任，然后將其交給另一個。 發件人看到電子郵件正在發送。 接收器並沒有真正錯過它，因為它們不一定知道它的到來。 因此，有一個很長的時間窗口可以讓該消息在系統中移動而無需任何人知道或關心它的速度。

另一方面，A本來可以和B一起打電話。“我剛發過它，你明白了嗎？現在？現在？現在就來吧？”

因此，存在某種潛在的，隱含的表現和反應水平。 最后，“最終”，A的發件箱與B收件箱相匹配。

這些延遲，接受陳舊數據，無論是一天之前還是1-5歲，都可以控制系統的最終耦合。 這種要求越松散，聯軸器越松散，您在設計方面就越靈活。

這適用於CPU中的核心。 在同一系統上運行的現代多核，多線程應用程序可以具有“相同”數據的不同視圖，只有幾微秒過時。 如果你的代碼可以正確地處理可能彼此不一致的數據，那么快樂的一天，它就會拉長。 如果不是，您需要特別注意確保您的數據完全一致，使用諸如易失性存儲器資格或鎖定構造等技術。所有這些都以其成本方式實現。

所以，這是基本考慮因素。 所有其他決定都從這里開始。 回答這個問題可以告訴您如何跨機器分區應用程序，共享哪些資源以及如何共享它們。 有哪些協議和技術可用於移動數據，以及在執行傳輸的處理方面將花費多少。 所有基於此概念的復制，負載平衡，數據共享等。

編輯，以回應第一條評論。

正確，准確。 比如這里的游戲，如果B無法改變客戶數據，那么改變客戶數據的危害是什么？ 你可以“冒險”它在短時間內過時嗎？ 也許您的客戶數據進展緩慢，您可以立即將其從A復制到B. 假設變化被放在一個隊列中，由於體積很小，很容易被接收（<1s），但即使它仍然是原始變化的“超出事務”，所以A會有一個小窗口B沒有的數據。

現在頭腦真的開始旋轉了。 在那個“滯后”1期間會發生什么，最糟糕的情況是什么。 你可以圍繞它工程嗎？ 如果你可以設計大約1秒的滯后，你可以設計大約5s，1m甚至更長的滯后。 您在B上實際使用了多少客戶數據？ 也許B是一個旨在促進從庫存中挑選訂單的系統。 很難想象除了簡單的客戶ID和名稱之外還有什么必要。 在組裝時，只需要嚴格確定訂單的用戶。

揀選系統不一定需要打印出所有客戶信息，直到揀選過程結束，到那時訂單可能已經轉移到另一個可能更新的系統，特別是發貨信息，所以最后，揀選系統根本不需要任何客戶數據。 實際上，您可以在揀配順序中嵌入和反規范化客戶信息，因此以后不需要或期望同步。 只要客戶ID是正確的（無論如何都不會改變）和名稱（這很少變化，不值得討論），這是您需要的唯一真正的參考，並且您的所有選擇單都是完全准確的。創建。

訣竅是思維方式，打破系統並專注於任務所必需的基本數據。 您不需要的數據不需要復制或同步。 人們對非規范化和數據縮減這樣的事情感到不滿，特別是當他們來自關系數據建模世界時。 有充分理由，應該謹慎考慮。 但是一旦你分發了，你就會隱含地反規范化。 哎呀，你現在正在批發它。 所以，你也可以更聰明一點。

所有這些都可以通過可靠的程序和對工作流程的透徹理解來緩解。 識別風險並制定處理這些風險的政策和程序。

但是，困難的部分是在開始時打破中央數據庫的鏈條，並指導人們，如果你有一個單一的，中央的，完美的信息存儲，他們就不能“擁有一切”。

Answer 2

這絕對不是一個全面的答復。 對不起，對於我的長篇文章，我希望它會增加在這里提出的想法。

我對你提到的一些方面有一些看法。

duplicate data

根據我的經驗，這通常是部門化或專業化的副作用。 一個部門開創了某些數據的集合，這些數據被其他專業團體認為是有用的。 由於它們與其他數據集合混合在一起並不具有對該數據的唯一訪問權限，因此為了利用它們，它們也開始收集/存儲數據，固有地使其復制。 這個問題永遠不會消失，就像重構代碼和刪除重復一樣需要不斷努力，需要不斷地為重復訪問，存儲和修改提供重復數據。

well-defined interfaces

大多數接口的定義都是為了保持其他約束。 但是，我們只是習慣於擺脫先前定義的接口所帶來的限制。 再一次是連續重構的一個案例。

tight coupling vs loose coupling

如果有的話，大多數軟件都會受到這個問題的困擾。 考慮到我們所面臨的時間限制，緊耦合通常是有利解決方案的結果。 松耦合會產生一定程度的復雜性，當我們想要完成任務時，我們不喜歡這種復雜性。 網絡服務的口頭禪已經進行了多年，我還沒有看到一個完全緩解這一點的解決方案的好例子

architectural simplification

對我來說，這是解決你在問題中提到的所有問題的關鍵。 SIP vs H.323 VoIP故事在我腦海中浮現。 SIP非常簡化，易於構建，而H.323就像典型的電信標准一樣，試圖設想地球上關於VoIP的每個問題並為其提供解決方案。 最終結果，SIP增長得更快。 成為H.323兼容解決方案是一件痛苦的事。 事實上，H.323合規性是一個巨大的降壓行業。

On a few architectural fads that I have grown up to.

多年來，我開始喜歡REST架構，因為它很簡單。 它提供了對數據的簡單唯一訪問，並且易於圍繞它構建應用程序。 我已經看到企業解決方案比重復，隔離和訪問數據更容易受到任何其他問題（如性能等）的影響。對我來說，REST可以為這些問題提供靈丹妙葯。

Answer 3

為了解決其中的一些問題，我喜歡中央“數據中心”的概念。 數據中心代表特定實體的“單一事實來源”，但僅存儲ID，沒有名稱等信息。事實上，它只存儲ID映射 ​​- 例如，這些映射將系統A中的客戶ID映射到系統B中的客戶端編號，以及系統C中的客戶編號。系統之間的接口使用集線器來了解如何將一個系統中的信息與另一個系統中的信息相關聯。

這就像是一個中心翻譯; 而不是必須編寫從A-> B，A-> C和B-> C映射的特定代碼，隨着您添加更多系統，其出勤率呈指數增長，您只需要轉換到集線器或從集線器轉換：A- > Hub，B-> Hub，C-> Hub，D-> Hub等