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

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

此外，用戶不應(yīng)將完全流行與適用于他們的用例相混淆。雖然網(wǎng)絡(luò)效應(yīng)肯定有優(yōu)勢（“如果每個(gè)人都在使用 X，它就不會(huì)出錯(cuò)”），但它也可能導(dǎo)致群體思維、扼殺創(chuàng)新和競爭。

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

五個(gè)因素

讓我們直接進(jìn)入列表。

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

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

軟件架構(gòu)

這里的關(guān)鍵考慮因素是“數(shù)據(jù)庫是否使用最有效的數(shù)據(jù)結(jié)構(gòu)、靈活的數(shù)據(jù)模型和豐富的查詢語言來支持您的特定工作負(fù)載和查詢模式？”

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

硬件利用率

我們正處于底層硬件的持續(xù)革命之中，這場革命繼續(xù)推動(dòng)軟件的發(fā)展。許多軟件應(yīng)用程序，尤其是許多數(shù)據(jù)庫，仍然植根于幾十年前的起源、設(shè)計(jì)和假設(shè)。

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

互操作性

沒有數(shù)據(jù)庫是一座孤島。集成到您的開發(fā)環(huán)境中有多容易？它是否支持您的編程語言、框架和項(xiàng)目？它是否旨在集成到您的微服務(wù)和事件流架構(gòu)中？

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

RASP

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

典型的平臺(tái)工程師啟動(dòng)了一堆新節(jié)點(diǎn)。

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

部署

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

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