當您為最新用例選擇數據庫時（或更換不滿足當前需求的數據庫），現在的好消息是您有很多選項可供選擇。當然，這也是壞消息。你有很多東西要整理。

有比以往更多的數據庫需要考慮和比較。2012 年 12 月，即 DB-Engines.com 首次開始對數據庫進行排名的第一年年底，他們列出了73個系統（比他們最初列出的18 個系統有了顯著增加）。截至 2022 年 12 月，他們只有不到 400 個系統。這代表了過去十年數據庫技術的寒武紀大爆發。有大量的選項可供導航：SQL、NoSQL 和“多模型”數據庫的混合，可以是 SQL 和 NoSQL 的混合，或者 NoSQL 的多個數據模型（結合兩個或更多選項：文檔，鍵值、寬列、圖表等）。

此外，用戶不應將完全流行與適用于他們的用例相混淆。雖然網絡效應肯定有優勢（“如果每個人都在使用 X，它就不會出錯”），但它也可能導致群體思維、扼殺創新和競爭。

我的同事 Arthur Pesa 和我最近討論了用戶在篩選和比較數據庫時需要首先考慮的五個因素。

五個因素

讓我們直接進入列表。

• 軟件架構——數據庫是否使用最高效的數據結構、靈活的數據模型和豐富的查詢語言來支持您的工作負載和查詢模式？
• 硬件利用——能否充分利用現代硬件平臺？或者您是否會留下大量未充分利用的 CPU 周期？
• 互操作性——集成到您的開發環境中有多容易？它是否支持您的編程語言、框架和項目？它是否旨在集成到您的微服務和事件流架構中？
• RASP——它是否具有可靠性、可用性、可擴展性、可維護性，當然還有性能的必要品質？
• 部署——這個數據庫是否只能在有限的環境中工作，比如只能在本地，或者只能在單個數據中心或單個云供應商中工作？或者它是否適合在全球范圍內以您想要的方式部署？

任何此類故障都是主觀的。您可能有自己的 4 個因素列表，或 12 個、20 個或 100 個標準。當然，軟件架構等這些因素中的每一個都分解為子類別，例如“存儲引擎”、“分布式處理架構”，甚至“查詢語言”。但這就是我將它們分為一般類別的方式。

軟件架構

這里的關鍵考慮因素是“數據庫是否使用最有效的數據結構、靈活的數據模型和豐富的查詢語言來支持您的特定工作負載和查詢模式？”

• 工作負載——您是否需要執行大量寫入或混合讀寫的事務性工作負載？或者你打算做一個大部分閱讀的分析工作量？您是否需要混合事務和分析的混合工作負載？該工作負載是實時的、批處理的還是混合的？是每秒穩定的事件流，還是平穩、規律的日內可預測漲跌？或者您是否需要計劃應對突發流量的隨機沖擊（例如，突發新聞或任何其他突然流行的記錄）？
• 數據模型——你在處理鍵值對嗎？寬列存儲（基于行的“鍵-鍵-值”數據）？列存儲（列數據）？文檔？圖形？RDBMS（帶有表和 JOIN）？或者完全是別的東西。您是否真的有時間并且需要對數據進行完全規范化，或者您是否會如此迅速地吸收如此多的非結構化數據以致于規范化是徒勞的，而您最好從非規范化數據模型開始？這里沒有單一的“正確”答案。“這取決于”應該作為你的口頭禪。
• 查詢語言——這里肯定有更多的偏見。因為雖然您的數據工程團隊可能能夠掩蓋或隱藏后端查詢模型，但您的許多用戶都有自己的偏見和偏好。這是 SQL 仍然如此鎖定的主要原因之一。同時，還有新的查詢語言可供使用。有些類似于 SQL，例如 Cassandra 和 ScyllaDB 使用的 Cassandra 查詢語言 (CQL)。SQL 用戶對它非常熟悉。但不要被愚弄——沒有表 JOIN！然后是一系列新派的查詢語言可能會用到，比如JSON。這就是 Amazon DynamoDB 查詢的工作方式。同樣，在這里，ScyllaDB 使用我們的 Alternator 接口支持這樣的 JSON 查詢模型，它與 DynamoDB 兼容。不管你往哪個方向傾斜，
• 交易/運營/ CAP——哪個對你更重要？完全一致的 ACID 事務？還是高性能、高可用的基本 CRUD 操作？CAP 定理說您可以擁有以下三個中的任意兩個：一致性、可用性或分區容錯性。考慮到分布式數據庫始終需要分區容忍，這讓您可以在所謂的“CP”模式一致性導向系統或“AP”模式可用性導向系統之間做出選擇。在這些模式中，需要考慮實施細節。例如，在分布式系統中實現強一致性的方式可能千差萬別。甚至考慮選擇各種共識算法來確保線性化，如 Paxos、Raft、Zookeeper (ZAB) 等。除了不同的算法之外，每個實現都可能與另一個有很大差異。
• 數據分布——當你說“分布式系統”時，你到底指的是什么？我們是在談論本地的單數據中心集群嗎？或者我們在談論多數據中心集群？跨集群更新是如何發生的？它是否被視為所有一個邏輯集群，還是需要集群間同步？它如何處理數據本地化，例如 GDPR 合規性？

硬件利用率

我們正處于底層硬件的持續革命之中，這場革命繼續推動軟件的發展。許多軟件應用程序，尤其是許多數據庫，仍然植根于幾十年前的起源、設計和假設。

• CPU 利用率/效率——如果 CPU 利用率超過 40% 或 50%，很多軟件就會運行不佳。這意味著您應該低效地運行該軟件，定期讓一半的機器未得到充分利用。實際上，您支付的基礎設施費用是您實際需要的兩倍（或更多）。因此，您有必要查看您的系統處理分布式處理的方式。
• RAM 利用率/效率——您的數據庫是否始終受內存限制？它的緩存是否過于激進或過于臃腫（例如具有多層緩存），將不需要的數據保留在內存中？它如何優化其讀寫路徑？
• 存儲利用率/效率——你的數據庫使用什么存儲格式？它是否具有可能需要重量級文件鎖定機制的緊湊型可變表？或者它是否使用可能產生快速寫入但以空間和讀取放大為代價的不可變表？它是否允許分層存儲？它如何處理并發？文件是按行存儲（適合事務用例）還是按列存儲（適合對高度重復的數據進行分析）？請注意，不只有一個“正確”答案。每個解決方案都針對不同的用例進行了優化。
• 網絡利用率/效率——在這里您應該同時考慮客戶端-服務器集群通信的效率，以及集群內通信的效率。通過并發、連接池等，可以使客戶端/服務器模型更加高效。集群內通信涵蓋典型的操作/交易聊天（在更新或寫入中復制數據），以及管理任務，例如在拓撲更改期間在節點之間流式傳輸和平衡數據。

互操作性

沒有數據庫是一座孤島。集成到您的開發環境中有多容易？它是否支持您的編程語言、框架和項目？它是否旨在集成到您的微服務和事件流架構中？

• 編程語言/框架——您一遍又一遍地聽到“我們是一家X商店”，其中X代表您首選的編程語言或框架。如果您的數據庫沒有必要的客戶端、SDK、庫、ORM 和/或其他包來將其集成到該語言中，那么它可能不存在。公平地說，數據庫的大規模爆炸與編程語言的大規模爆炸同時發生。然而，查看對客戶端的編程語言支持是值得的。請注意，這與數據庫本身可能編寫的語言不同（這可能會影響其軟件架構和效率）。這純粹是關于您可以使用哪些語言編寫應用程序來連接到該后端數據庫。
• 事件流/消息隊列——數據庫可能是單一的事實來源，但它們并不是您公司中運行的唯一系統。事實上，您可能擁有不同的數據庫，它們都在處理、分析和共享公司整體數據和信息空間的不同部分。事件流是現代企業避免數據孤島的越來越普遍的媒體，如今，您的數據庫只有與實時事件流和消息隊列技術集成才能發揮作用。您的數據庫能否同時充當數據接收器和數據源？它是否具有變更數據捕獲 (CDC)？它是否連接到您最喜歡的事件流和消息隊列技術，例如 Apache Kafka、Apache Pulsar 或 RabbitMQ？
• API——為了促進您的數據庫集成到您的應用程序和微服務架構中，您的數據庫是否支持一個或多個 API，例如 RESTful 接口或 GraphQL？它是否具有管理 API，以便您可以通過編程方式配置它而不是通過 GUI 界面執行所有操作？起初使用 GUI 似乎很方便，直到您必須管理和自動化您的部署系統。
• 其他集成——CI/CD 工具鏈呢？可觀察性平臺？如何將您的數據庫用作可插拔存儲引擎或更廣泛架構的底層元素？它作為基礎設施的作用如何，或者適合您已經使用的基礎設施？

RASP

這個首字母縮略詞可以追溯到幾十年前，通常用于硬件上下文中。它代表可靠性、可用性、可維護性（或可擴展性）和性能。基本上，這些“-ilities”是“facilities”——讓你的系統運行起來更容易的東西。在數據庫中，考慮您可能需要執行多少手動干預和“轉盤”以保持系統正常運行和穩定是至關重要的。它們表示數據庫在一般操作條件下可以在多大程度上照顧好自己，甚至盡可能地減輕故障狀態。

典型的平臺工程師啟動了一堆新節點。

• 可靠性——為了防止這個東西崩潰或數據消失，你需要進行多少修補？你的數據庫是否具備良好的持久化能力？它的生存能力如何？它包括什么反熵機制來讓集群恢復同步？您的備份系統有多好？更重要的是，您的還原系統有多好？是否有操作護欄來防止個人用一個“哎呀！”把事情搞砸了？
• 可用性——當您遇到短期網絡分區和臨時節點不可用時，您的數據庫會做什么？當一個節點完全失敗時會發生什么？如果網絡故障持續超過幾個小時怎么辦？
• 可服務性——如今流行的流行語是“可觀察性”，它通常包含日志記錄、跟蹤和指標這三大支柱。當然，您的數據庫需要內置可觀察性。然而，可維護性遠不止于此。在不停機的情況下執行升級有多容易？維護操作有多輕松？
• 可擴展性——一些數據庫非常適合入門。然后……你撞墻了。難的。可擴展性意味著您不必擔心在管理的總數據量、每秒總操作數或地理限制方面達到極限——例如超越單個數據中心以實現真正的全球部署。此外，還有水平可擴展性——向集群添加更多節點的橫向擴展——以及垂直可擴展性——將您的數據庫放在具有不斷增加的 CPU 數量、更多 RAM 和更多存儲的服務器上（參見硬件部分）多于）。
• 性能——底線：如果數據庫不能滿足您的延遲或吞吐量 SLA，它就不會在生產中運行。此外，與可擴展性相關，許多數據庫似乎可以在小規模下或基于使用測試數據的靜態基準滿足您的性能要求，但當遇到實際生產工作負載時，就無法跟上不斷增加的頻率、可變性和查詢的復雜性。因此性能需要與線性比例有很強的相關性。

部署

然后，以上所有內容都需要在您需要的地方運行。這個數據庫是否只能在有限的環境中工作，比如只能在本地，或者只能在單個數據中心或單個云供應商中工作？或者它是否適合在全球范圍內以您想要的方式部署？問自己這些問題：

• 鎖定——這可以在本地運行嗎？或者，相反，它是否僅限于本地部署？它僅限于某個公共云供應商，還是可以在您選擇的云供應商中運行？您的混合云或多云部署選項是什么？
• 管理/控制——同樣，這是否只能作為自我管理的數據庫使用，還是可以作為完全托管的數據庫即服務 (DBaas) 使用？前者允許團隊完全控制系統，后者減輕團隊的管理負擔。兩者都有其權衡。只能選擇一個，還是數據庫允許用戶在這兩種商業模式之間切換？
• 自動化和編排——是否有 Kubernetes Operator 在生產中支持它？Terraform 和 Ansible 腳本？雖然這是列表中的最后一項，但請放心，在任何生產考慮中都不應事后考慮。