如何為下一個閃亮的新事物選擇數據存儲

注意：這是一篇由首席工程師 Silvia Botros 撰寫的技術博客文章，於 2017 年 12 月 25 日首次出現在 Sysadvent 博客上。

數據庫可能很難。 你知道什麼更難嗎？ 一開始就選一個。 無論您是在一家仍在尋找其產品/市場契合度的新公司，還是在一家已經找到其受眾並只是擴大產品供應的公司，這都是具有挑戰性的。

在構建新事物時，設計過程的第一部分是我們應該使用哪些數據存儲，應該是單數還是複數？ 我們應該使用關係存儲還是需要選擇鍵值存儲？時間選項呢？ 我們是否也應該加入一些分佈式日誌重放？

所以。 許多。 選項…

我將在本文中嘗試描述一個有望指導該決策的過程，並在適用的情況下解釋您的組織的規模和成熟度如何影響該決策。

基線要求

數據是任何產品的命脈。 即使我們計劃在設計中使用更多前沿技術來存儲應用程序狀態（因為 MySQL 或 Postgres 不再“酷”了），我們選擇的仍然是數據存儲，因此需要我們在做出我們的選擇。

要記住的重要一點是，沒有什麼是免費的。 所有數據存儲都存在妥協，如果您沒有明確說明您將採取哪些妥協作為業務風險，那麼您將承擔未知風險，該風險將在最糟糕的時候顯現出來。

您的產品經理不太可能知道甚至不需要關心您用於數據存儲的內容，但他們會推動縮小選項列表的需求。 不過，有時即使這樣也需要開發團隊的一些推動。 以下是您需要要求產品團隊幫助推動您的選擇的清單：

• 增長率：隨著時間的推移，數據本身或對數據的訪問預計會發生怎樣的變化？
• 計費團隊將如何使用這些新數據？
• ETL 團隊將如何使用這些數據？
• 此新功能的預期準確性/一致性要求是什麼？
• 這種一致性的時間跨度是可以接受的？ 後期處理校正是否可以接受？

找到沒有說的上下文

數據存儲的選擇不是為 DBA 或 Ops 團隊或什至只是編寫代碼的工程師保留的選擇。

具有已知潛在市場的成熟組織需要來自整個組織的利益相關者的決定。

如果產品團隊的需求適合十幾個數據存儲，您如何確定未明確調用的需求？

您需要盡快提出未說出口的要求，因為這是導致預期失敗的道路。

很多隱含的東西會讓你在這個“太多選擇”的陷阱中失敗。 這包括但不限於：

• 不完整的功能列表
• 未明確列出的性能要求
• 假定的一致性需求
• 未指定的增長率
• 尚不可用/未知的計費或 ETL 查詢需求

這些都是可能的方式，可能會讓工程團隊在審查一長串數據存儲選擇的時間過長，因為他們使用的明確標準過於寬鬆或不完整。

正如我之前提到的，對於更多“未開發”產品，您的目標是靈活性。 因此，一個更通用、質量已知的數據存儲將幫助您更接近可交付成果，並且知道您可能需要遷移到更適合您的新規模的數據存儲。

列出你的清單

是時候根據您的需求列表過濾潛在的解決方案了。 結果列表需要不超過少數可能的數據存儲。 如果您可以使用的潛在數據庫列表不止這些，那麼您的要求過於寬鬆，您需要返回並查找更多信息。

對於年輕、不太成熟的公司來說，數據存儲需求是最未知的領域。 您可能正在構建一種尚未有人提供的新事物，因此諸如總可尋址市場規模和增長率之類的事物可能相對未知且難以量化。

在這種情況下，您需要的是不要在新公司的生命週期中過早地使用 one trick pony 數據存儲來約束自己。 是的，在某些時候，您的數據會以新的和意想不到的方式增長，但您現在需要的是靈活性，因為您試圖找到自己的市場利基並了解數據的增長方式以及哪些特定的可擴展性功能將變得至關重要你的成長。

如果您是一家擁有越來越多付費客戶的大公司，那麼您的任務是將選項列表縮小到您已經擁有並維護的最好的數據存儲。 當您已經有很多付費客戶時，添加您的團隊不熟悉的新數據存儲的風險會變得更高，並且根據數據的上下文，這簡直是不可接受的。

要記住的另一件事是數據存儲已經存在哪些工具，以及就團隊必須做的前期工作而言，採用新工具意味著什麼。 配置管理、備份腳本、數據恢復腳本、新的監控檢查、構建和熟悉的新儀表板。 無論風險如何，新數據存儲的運營成本清單都不是微不足道的。

選擇你的毒藥

因此，這裡有一個 DBA 保守的秘密。 數據庫在某些方面都很糟糕。 甚至有一個完整的定理。 不僅僅是傳統意義上的數據庫，任何存儲狀態的技術都會以你使用它的方式獨特的方式變得可怕。

這只是你現在最好內化的生活事實。 不，我並不是說你應該避免使用這些技術中的任何一種，我是說保持你的期望，並知道你，只有你和你的團隊最終擁有兌現你做出的承諾。

這在非抽象術語中意味著什麼？ 一旦你對哪些數據存儲將成為你正在構建的東西的一部分有了一個明確的想法，你應該從了解這些數據存儲的弱點開始。 這些弱點包括但不限於：

• 此數據存儲在掃描查詢下是否運行良好？
• 該數據存儲是否依賴 gossip 協議進行數據複製？ 如果是這樣，它如何處理網絡分區？ 該八卦涉及多少數據？
• 此數據存儲是否存在單點故障？
• 社區中的驅動程序有多成熟可以與之交談，還是您需要自己動手？
• 這個列表可能很大

仔細考慮仍然在您的列表中的潛在解決方案的弱點應該會從列表中剔除更多選項。 現在，這已成為現實，滿足了科技的崇高承諾。

電子表格和烘烤！

一旦您的選擇列表減少到一小部分，是時候將它們全部放入電子表格並開始更深入地挖掘。 您需要一個優點列和一個缺點列，此時，您將需要在每個數據庫文檔中花費一些時間，以找出有關如何執行某些任務的基本細節。

如果這是您期望具有較大增長率的數據，您需要知道哪些選項更容易橫向擴展。 如果這是一個進行大量模糊搜索的功能，您需要知道哪個數據存儲可以更好地處理掃描或搜索大量行以及採用什麼設計。 此階段的目標是僅通過文檔將列表縮減為理想的 2 或 3 個選項，因為如果此新功能對公司成功至關重要，您將必須對所有三個選項進行基準測試。

為什麼要進行基準測試？ 因為沒有 2 家公司以相同的方式使用相同的數據存儲。 因為有時文檔意味著只有在其他人的戰爭故事中才會暴露的警告。

因為除了您之外，沒有人擁有此數據存儲的穩定性、可靠性和可預測性。

提前設計基準。 理想情況下，您在列表中使用生產級別規範設置數據存儲的完整實例，並生成不會太小以使負載測試無用的測試數據。 確保不僅要對“正常負載”進行基準測試，還要測試一些故障場景。

希望通過基準測試，您可以發現任何嚴重到足以導致您現在重新訪問選項列表的警告，而不是稍後在編寫所有代碼並且您現在處於防火練習階段並且有很多時間時並為您所做的選擇付出努力。

記錄您的選擇

無論您做什麼，您都必須在內部記錄和廣播您做出選擇的方法以及在做出該決定的過程中調查的替代方案。 假設有一個關於如何創建此新功能及其所有組件的總體架構藍圖，您確保創建一個專門用於支持此新功能的數據存儲區的部分，其中包含指向所有基準測試的鏈接，以達成團隊做出的決定.

這不僅是為了未來新員工的利益，也是為了您的團隊現在的利益。 人們可以異步閱讀和發表意見的文檔提供了一種保持決策過程透明的方法，在團隊成員中培養最佳意圖感，並可以從您未預見的角度提出批評。

外賣

這些步驟不僅會在增加業務產品時導致基於數據的決策，而且還會導致強大的基礎架構和更規範的方法，以便您在何時何地使用不斷增長的技術領域為您的支付提供價值顧客。