資料庫亂象叢生，開發者該如何選擇？

【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的聯合創始人。

譯者：彎月，責編：郭芮

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！