正確使用資料架構的五條規則 - infoworld

通過在資料架構過程的早期解決關鍵考慮因素，您可以避免將來出現嚴重問題。

構建合適的資料架構對於所有現代架構的長期成功至關重要。為了協助您的應用程式現代化過程，在構建或重新構建應用程式資料時，請遵循以下五個規則。

使用正確型別的資料庫

構建資料的第一個也是最重要的決定是瞭解儲存和訪問資料所需的資料庫型別。您是否需要：

• 儲存高度結構化的資料還是簡單的鍵值資料？
• 永久保留資料還是僅保留一小段時間？
• 隨機或順序訪問資料？
• 使用固定模式、靈活模式還是簡單的平面檔案？
• 使用支援 SQL 查詢的關聯式資料庫？

您需要回答這些問題來確定您需要使用的資料庫型別。根據這些答案，您可以選擇 SQL 資料庫、簡單的鍵值儲存、記憶體駐留快取、簡單的物件儲存或高度結構化的資料儲存。

您選擇的資料庫型別將決定您的資料庫最終能夠做什麼以及它在您的應用程式用例中的表現如何。確定您的可擴充套件性和可用性要求等對您的應用程式來說不可或缺的事情會受到您的資料庫選擇的顯著影響。

將資料儲存在正確的位置

一個看似簡單但很重要的問題是，資料應該儲存在哪裡？根據資料和您的應用程式，您是否需要儲存資料，例如，在您的應用程式的前端還是在後端？您可以將資料儲存在消費者本地，還是需要與許多其他消費者共享資料？

從一開始就考慮擴充套件

現代應用程式必須能夠擴充套件以滿足企業客戶不斷增長的需求。這適用於所有企業和所有應用程式。

構建可擴充套件以滿足您不斷擴充套件的需求的應用程式絕對最困難的部分是擴充套件資料儲存。無論是擴充套件以增加您需要為不斷增長的客戶群儲存的資料量，還是擴充套件以允許更多人同時使用您的應用程式而不會降低效能，除非您從一開始就計劃好，否則資料擴充套件很難。

然而，大多數應用程式架構似乎將資料縮放視為可以留待以後使用的副需求。一旦建立了主要的應用程式架構，應用程式開發人員就會考慮這一點。

稍後將強制擬合擴充套件到資料架構中是一項極其困難的任務，並且隨著資料集規模的增長變得更加困難。到目前為止，構建可擴充套件性最簡單的時間是在開始時，在您的應用程式需要擴充套件之前。如果沒有主要的資料重構，等到以後可能會使擴充套件變得更加困難，並且可能是不可能的。

跨服務分發資料

許多雲專家建議集中應用程式資料是管理大型應用程式的大型資料集的正確模型。他們認為，集中資料可以更輕鬆地應用機器學習和其他高階分析，從資料中獲取更有用的資訊。

但這種策略是錯誤的。集中式資料是無法輕鬆擴充套件的資料。擴充套件資料的最有效方法是將其分散並將其儲存在擁有資料的單個服務中。您的應用程式，如果由數十個或數百個分散式服務組成，會將您的資料儲存在數十個或數百個分散式位置。

此模型可以更輕鬆地擴充套件並支援完整的服務所有權模型。服務所有權使開發團隊能夠更加獨立地工作，並鼓勵服務之間建立更強大的 SLA。這促進了更高質量的服務，並通過本地化使資料更改更安全、更高效。

但是，如果您的企業需要對所有這些資料執行分析或機器學習怎麼辦？我仍然推薦這裡描述的分散式資料模型。但是，為了使您的資料對分析和機器學習有用，請將相關資料的副本傳送到後端資料倉儲系統。在該資料倉儲系統中，以適合您的分析目的的方式構建資料，並將此版本用於您的分析和機器學習演算法。此資料倉儲版本與您的應用程式記錄資料分開且不同，後者仍儲存在各個服務中。

在地理上分佈您的資料

最後，確定誰將使用資料，以及他們將在地理上的位置。隨著全球商業帶來更多機會，而區域資料治理限制使管理全球資料變得更加困難，確定資料和使用者位置變得越來越重要。

在建立資料架構之前，您必須回答以下關鍵問題：

1. 您的資料在全球範圍內可用是否重要，還是區域版本的資料對您的業務更重要？例如，您希望在美國和德國獲得相同還是不同的資料？許多應用程式發現兩種模型的混合很重要，這個答案是可以接受的，只要您知道哪些資料必須全球化，哪些必須區域化。
2. 您是否對可以儲存的資料和儲存位置有區域限制？一些地方有限制，防止客戶資料離開客戶所在的國家/地區。其他人對可以跨越國家和地區邊界傳輸的資料有限制。某些區域比其他區域具有更嚴格的隱私限制。哪些資料限制適用於您資料的哪些部分？
3. 對於跨區域共享的資料，在每個區域顯示完全相同的資料有多重要？換句話說，資料是否必須在區域之間完全同步？不同的模型給你的資料集帶來了不同的負擔。最終一致性模型與符合[url=https://en.wikipedia.org/wiki/ACID]ACID 的[/url]事務完整性模型具有非常不同的效能特徵。

這些問題的答案將決定您是提供全球資料還是區域資料，可以和不可以在何處使用這些資料，以及何時以及如何在區域之間同步資料。

資料架構是構建高度可擴充套件、高度可用、全球可訪問的現代應用程式的關鍵部分。資料架構中的錯誤可能會導致可擴充套件性、可用性甚至法律一致性問題。在應用程式增長後更改資料架構既困難又痛苦。預先解決關鍵資料需求要容易得多。

通過在資料架構過程的早期遵循這五個規則，您可以避免將來出現嚴重問題。