數據庫亂象叢生，開發者該如何選擇？

【CSDN編者按】據不完全統計，目前已有340多個處於活躍且仍在更新的數據庫供開發者選擇。但事實上，這些方案的目的只有一個：解決存儲和讀取基於文本的資訊。本文試圖在亂象中指出一條路，帶你看盡2018年最受歡迎的數據庫推薦榜單。

以下為譯文：

有一天我在午飯時遇到個朋友，於是聊起了數據庫和數據存儲解決方案方面的亂象。所謂亂象是指，在我寫這篇文章時，《數據庫引擎排名》（https://db-engines.com/en/ranking）上已經列出了340多個處於活躍且仍在更新的數據庫供選擇，而每種方案其實都在用略微不同的方案試圖解決同一個問題：存儲和讀取基於文本的資訊。本文試圖在亂象中指出一條路，找出一種方案來幫你選擇最適合項目的數據庫。

當談論數據庫時，我們其實在談論什麽？

本文中所說的數據庫是指數據庫管理系統（Database Management Systems），其目的是在硬碟或SSD上存儲文本資訊，以提供立即訪問數據的能力（通常在幾秒內）。

也就是說，我們的談論並不包括：

純粹的記憶體緩存，如Memcached（https://memcached.org/）這種進程停止時會丟失全部數據的系統；

檔案存儲，或其他任何形式的存儲，如AWS S3（https://aws.amazon.com/s3/）或Azure Managed Disks（https://azure.microsoft.com/en-us/services/managed-disks/）；

長期的備份和數據倉庫解決方案，如AWS Glacier（https://aws.amazon.com/glacier/）。

那麽，怎樣才能為項目選擇合適的數據庫呢？

私有還是開源？

首先從一個無聊的商業問題說起：你想為數據庫花錢嗎？這裡不包括那些雲服務的账單（我們會在下一段討論），而是指自己搭建伺服器的情況下，數據庫所需的授權費用。

等等，不是有能免費使用的開源數據庫嗎？而且還很好用不是嗎？對，不過許多公司希望數據庫能提供99.999%的穩定性保證，以及能在清晨五點撥打的技術支持電話。實際上，前十大最流行的數據庫中的四個都有商業授權（Oracle（https://www.oracle.com/database/index.html），Microsoft SQL Server（https://www.microsoft.com/en-us/sql-server），IBM DB2（https://www.ibm.com/analytics/us/en/db2/）和Microsoft Access（https://products.office.com/en/access）），其中Oracle還是所有數據庫中的第一名。

雲服務還是自己搭建伺服器？

運行數據庫非常容易，只需要點擊一個可執行檔案，或者啟動服務，數據庫伺服器就能跑起來了。但在生產環境中真正地運營一個伺服器卻非常困難。分片（sharding）、創建讀寫副本（replica）、持續備份、熱更新……這也是數據庫管理員這個職位存在的原因。

如果你不想乾這些，那最好還是使用雲服務吧。這裡我們還需要區分兩大類數據庫——姑且稱之為“被管理的”數據庫和“無伺服器”數據庫。

被管理的數據庫雲服務能夠以完全受管理的服務的方式為你提供最流行的開源數據庫。例如AWS RDS（https://aws.amazon.com/rds/），它可以提供MySQL/MariaDB/Postgres等實例。這種數據庫的問題是，你還得自己決定一些問題，諸如“數據庫要多大”、“需要多少個實例”、“多長時間做一次備份，備份存放在哪裡”等問題。

如果連這些你也不想做，那可以使用現在越來越流行的“無伺服器”數據庫，或者叫做“數據庫即服務”。這些通常是雲服務供應商的私有數據庫，你只需要連接到某個API上存儲數據就行了。如AWS DynamoDB（https://aws.amazon.com/dynamodb/）、Azure CosmusDB（https://azure.microsoft.com/en-us/services/cosmos-db/）和Google Firebase（https://firebase.google.com/）等均屬此類。

數據模型

現在來討論下最重要的問題：哪種數據模型最適合你的數據結構？可選項有：

關係型 / 表

關係型數據庫在表中存儲數據，表有多個列，每列都有自己的數據結構（文本、數字、日期等）。每行都由唯一的ID確定，稱為“主鍵”。數據之間的關係通過引用其他行的主鍵來實現。

數據通常由“結構化查詢語言”（即SQL）負責創建和讀取，這種語言有豐富的功能。

選擇關係型數據庫的理由

關係型數據庫是最常見也是應用最廣泛的數據庫，這是有原因的。這種模型儘管不靈活，但很穩定，能避免數據重複，還可以給開發者提供可預測的結果。此外，這個分類下有大量非常成熟的數據庫系統，如PostgreSQL（https://www.postgresql.org/）和MySQL（https://www.mysql.com/），而成熟、穩定的結果和安全可能是選擇數據庫時需要考慮的最重要的因素。

不選擇關係型數據庫的理由

關係型數據庫需要預先定義表結構，這種表結構通常是靜態的。儘管可以修改已有表的列定義，但通常需要額外的開銷。而且，每個列只能保存一種數據類型。這種方式可以讓數據庫管理系統減少存儲太空並避免數據重複，但NoSQL的提議（見下一段）認為，存儲太空已經十分廉價，犧牲靈活性換取存儲太空已經沒有必要。

對象 / 文檔 / NoSQL數據庫

除了一些例外情況，這類數據庫會將所有相關資訊保存在對象中（比如應用程式的用戶，或者唱片目錄中的一張專輯），使用一個結構松散的JSON數據塊保存，這個數據塊被稱為“對象”或“文檔”。同類型的多個文檔以“列表”或“集合”的方式組織。對象數據庫的數據建立、讀取和搜索方式多種多樣，有的提供RESTful API（如CouchDB（http://couchdb.apache.org/）），有的以Map-Reduce等函數式編程概念提供（MongoDB（https://www.mongodb.com/））。

選擇對象數據庫的理由

倒退幾年，NoSQL的熱潮像暴風雨一樣席卷了整個數據庫世界。NoSQL不是一個概念，而是一次運動，口號就是“打倒關係型數據庫”。今天，在經歷了無數的運維危機和莽撞的系統轉換之後，NoSQL在大量存儲解決方案中間找到了應屬於它的位置。NoSQL是個偉大的工具，而不是根治一切的靈丹妙藥。它的靈活性給開發者帶來了極大方便，如在同一個集合記憶體儲不同結構的文檔，無需擔心數據類型和數據的強關聯並由DBMS搞定一切等。

不選擇對象數據庫的理由

有一點混亂是好事兒，但對象數據庫在原則上的缺失使得它在大公司裡並不受歡迎。而且，高度關係型的數據依然更適合保存在關係型數據庫或者圖數據庫中，只有一小部分數據被孤立的情況下才能很好地應用文檔數據庫。

圖數據庫

圖數據庫提供了另一種對數據間關係進行抽象的方式，在嚴格的表和松散的文檔之間找到了很好的平衡。在圖數據庫中，每個實體（節點）是個獨立的文檔，其中包含一系列可以嵌套的屬性。這些節點由“邊”連接起來，這些邊構成了節點之間的關係。邊可以擁有自己的屬性。聽上去似乎很複雜，但可以這樣考慮：“John有四個紅蘋果”這個事實可以分解為：John（節點A）有（邊）四個（邊屬性）紅（節點B的屬性）蘋果（節點B）。

大多數圖數據庫都提供了豐富的工具用於對複雜網絡的節點進行查詢、遍歷和求值，如找出所有連接的節點、找出連接最多的節點、找出最近的鄰居等。

選擇圖數據庫的理由

圖數據庫是組織高度互聯的數據的絕佳方法。比如要構建一個支付系統，在每筆交易中錢可以在多個账戶之間轉手，那麽圖數據庫可以顯著降低複雜度，如在多個交易步驟中跟蹤每筆支付等。

不選擇圖數據庫的理由

圖數據庫在相對簡單的情況下會有很大的額外開銷。特別是線性數據系列（如會話日誌）非常不適合圖模型。而且圖模型的最大難點就是它需要對數據模型進行深度思考，通常這會給開發人員帶來相當大的壓力。

鍵值數據庫

有些情況下，你只需要簡單地保存些數據，這些數據可以用鍵來標識。這種情況下應該使用鍵值數據庫。鍵值數據庫非常簡單，因此訪問非常快，特別適合非關係型數據。比如像bit.ly這種短地址生成器，它只需要使用一個代碼查找原始地址，而不需要任何複雜的查詢。

使用鍵值數據庫的理由

如果數據很簡單，那麽使用鍵值數據庫可以很方便擴容。

不使用鍵值數據庫的理由

關係型數據、擁有複雜結構的數據，或者需要查詢或搜索的情況。

寬列數據庫

寬列數據庫就像是有第二個維度的鍵值數據庫，或者更恰當的比喻就是擁有無限的動態行和列的Excel數據表。寬列數據庫可以快速查找行、列或行列交點，並可以快速讀寫大量數據。

使用寬列數據庫的理由

如果數據可以放到一個巨大的Excel表中，那麽寬列數據庫簡單的數據模型可以實現方便的擴展，並且很容易進行複製（replication）和分片（sharding）。

不使用寬列數據庫的理由

時間序列數據庫

時間序列數據庫隻做一件事，而且做得很好。這種數據庫以二維形式存儲線性數據序列，兩個維度之一通常為時間，另一個維度是一個或多個值。時間序列通常用於伺服器監視或財務記錄，但並不是通用的解決方案。

使用時間序列數據庫的理由

如果需要有效地存儲並查詢時間序列數據，就可以使用時間序列數據庫。如果應用中的數據只有少量時間序列，那麽關係型數據庫一般夠用。多數情況下，時間序列數據庫能提供更高層次的功能，如當特定的值被破壞時發出警告等。

不使用時間序列數據庫的理由

如果數據不是時間序列，或在一個大型應用中只需要存儲少量時間序列數據，那就不要使用時間序列數據庫。

還有什麽？

這些基本上覆蓋了主要的數據庫類型。但還有相當數量的特殊類型數據庫，如Elasticsearch（https://www.elastic.co/）等代表底層數據數據的搜索引擎，或用於XML、YAML等特殊格式的數據庫。除此之外，還有一些多概念的數據庫，比如結合關係型和圖數據的數據庫，或允許動態表結構，從而可以支持像對象一樣的靈活性的數據庫等。有些情況下，這些數據庫也許更合適。

在商用方案與開源方案、雲服務於自行架設伺服器方面做出決定，並確定了數據模型之後，還有一些因素需要考慮：

可擴展性和一致性

許多數據庫提供“強”一致性，即在數據讀取時，即使數據庫集群中的部分節點失效，或發生任何災難性的事件，也能保證所有的寫操作都已完成，所有數據都是最新的。這種一致性會對性能造成可觀的影響，但對於多數應用來說，這是絕對必要的。要想知道某個數據庫是否滿足一致性需求，可以看看“ACID依從性”（即原子性、一致性、隔離性、持久性）。關於更深入的測試以及理解失敗情況下的數據庫行為，可以看看與此相關的Jepsen報告（https://jepsen.io/analyses）。

實時查詢，報警，觸發器和其他特性

許多數據庫在純粹的存儲和數據獲取之外還提供其他特性。例如RethinkDB（https://www.rethinkdb.com/）提供的實時查詢（在底層數據發生改變時自動更新結果的查詢）功能，還有Elasticsearch（https://www.elastic.co/）、Algolia（https://www.algolia.com/）提供的支持詞乾提取和同義詞等複雜全文搜索功能，甚至連PostgreSQL（https://www.postgresql.org/）這樣的數據庫（作者最喜愛的數據庫）都提供了完整的可編程數據環境、完整的觸發器功能和發布者/訂閱者方式的消息功能。

接下來幹什麽？

有了上面這些知識，你可以去看看DB Engines Ranking（https://db-engines.com/en/ranking）網站，上面列出了你能想到的所有數據庫，並根據流行度進行評分。可以從這個網站上根據你的條件選一兩個流行的數據庫，來幫助你的項目獲得成功吧。

原文：https://arcentry.com/blog/choosing-a-database-in-2018/

作者：Wolfram Hempel，Arcentry的創始人，DeepstreamIO的聯合創始人。

譯者：彎月，責編：郭芮