關系型、非關系型資料庫存盤選型盤點大全-有解無憂

作業中總是遇到資料存盤相關的 Bug 工單，新需求開發設計中也多多少少會有資料模型設計和存盤相關的問題，經過幾次存盤方案設計選型和討論后發現需要有更全面的思考框架，

日常開發中常用的存盤方案選型很多都是 “拿來主義” 的，憑借著經驗、習慣選用，但對它們的細節特性或約束少有研究，

除了手邊會用的存盤方案，也應該關注市面上更合適的存盤方案，

一定的技術預研和儲備能夠幫助未來更好的技術方案設計，

故寫了這篇文章，拋出我的觀察和思考，希望日后可以將一些更先進 (合適) 的技術引入公司業務，助力業務發展，

存盤選型的考慮要素

存盤選型的目的還是為了我們的使用場景和用戶服務，因此在選型前需要回答一些業務指標 & 技術指標方面的問題，以便于我們清楚存盤選型的應用環境，

用戶量：用戶量預估多少？幾百幾萬還是幾億？

資料量：資料量預估多少？日均增量能有多少？

讀寫偏好：資料是讀多一些還是寫多一些？

資料場景：強事務型還是分析型需求？

運行性能要求：并發量是多少？高峰、平均、低谷分別預估是多少？

存盤引擎分類及特性

資料庫的分類方式非常多樣，因參考維度不同而存在較大差異，下面是常見的一些分類，

先拿我們最熟悉的關系資料庫來說，它的優點非常多，我們選用關系資料庫的理由可簡單概括為以下幾點：

容易理解

可由二維表結構來邏輯表達，相對網狀、層次等其他模型更加容易被理解，嚴格遵循資料格式與長度規范，資料以行為單位，一行資料表示一個物體資訊，每一行資料的屬性都是相同的，

事務特性

支持 ACID 特性，可以維護資料之間的一致性，這是使用關系資料庫非常重要的一個理由，

操作方便

通用的 SQL 語言使得操作關系型資料庫非常方便，支持 join 等復雜查詢，Sql + 二維關系是關系型資料庫最無可比擬的優點，這種易用性非常貼近開發者，

資料穩定

資料持久化到磁盤，沒有丟失資料風險，

服務穩定

最常用的關系型資料庫產品 MySql、Oracle 服務器性能卓越，服務穩定，通常很少出現宕機例外，

然而，在享受關系資料庫帶來的便利的同時，我們也不得不面臨很多麻煩的問題：

高并發下資料庫瓶頸明顯

資料按行存盤，即使只針對某一列進行運算，也會將整行資料從存盤設備中讀入記憶體，導致 IO 較高，寫入更新頻繁的情況下，資料庫往往會出現 CPU 飆高、Sql 執行慢、客戶端報資料庫連接池不夠等例外情況，且性能瓶頸通過加 CPU、換固態硬碟、繼續買服務器加資料庫做分庫等方式處理 ROI 不高，受限于其本身的特點，可能花了很多錢都未必能達到想要的效果，因此例如萬人秒殺這種場景，我們絕對不可能通過資料庫直接去扣減庫存，需要做好流量漏斗，

為維護資料一致性付出的代價大

資料一致性是關系型資料庫的核心，但是同樣為了維護資料一致性的代價也非常大，SQL 標準為事務定義了不同的隔離級別，從低到高依次是讀未提交、讀已提交、可重復度、串行化，事務隔離級別越低，可能導致的并發例外越多，但是能提供的并發能力越強，那么為了保證事務一致性，資料庫就需要提供并發控制與故障恢復兩種技術，前者用于減少并發例外，后者可以在系統例外的時候保證事務與資料庫狀態不會被破壞，對于并發控制，其核心思想就是加鎖，無論是樂觀鎖還是悲觀鎖，只要提供的隔離級別越高，那么讀寫性能必然會受影響，

為維護索引付出的代價大

為了提供豐富的查詢能力，通常熱點表都會有多個二級索引，一旦有了二級索引，資料的新增必然伴隨著所有二級索引的新增，資料的更新也必然伴隨著所有二級索引的更新，這不可避免地降低了關系型資料庫的讀寫能力，且索引越多讀寫能力越差，除了資料檔案不可避免地占空間外，索引占的空間其實也并不少，

水平擴展后帶來的種種問題難處理

隨著業務規模擴大，一種方式是對資料庫做分庫，做了分庫之后，資料遷移（1 個庫的資料按照一定規則打到 2 個庫中）、跨庫 join、分布式事務處理都是需要考慮的問題，尤其是分布式事務處理，業界當前都沒有特別好的解決方案，

全文搜索功能弱

例如 like “% 新年快樂 %”，只能搜索到 “新年快樂，愛大家”，無法搜索到 “新年真是太快樂了，愛大家” 這樣的文本，即不具備分詞能力，且 like 查詢在 “% 新年快樂” 這樣的搜索條件下，無法命中索引，將會導致查詢效率大大降低，

表結構擴展不方便

由于資料庫存盤的是結構化資料，因此表結構 schema 是固定的，擴展不方便，如果需要修改表結構，需要執行 DDL（data definition language）陳述句修改，修改期間會導致鎖表，部分服務不可用，

如上文所分析的，關系型資料庫優點明顯，缺點同樣不能忽視，因此通常在企業規模不斷擴大的情況下，不會一味指望通過增強資料庫的能力來解決資料存盤問題，而是會引入其他存盤，也就是我們說的 NoSql，

NoSql 的全稱為 Not Only SQL，泛指非關系型資料庫，是對關系型資料庫的一種補充，特別注意補充這兩個字，這意味著 NoSql 與關系型資料庫并不是對立關系，二者各有優劣，取長補短，在合適的場景下選擇合適的存盤引擎才是正確的做法，

下面看一下常用的 NoSql 及他們的代表產品，并對每種 NoSql 的優缺點和適用場景做一下分析，便于熟悉每種 NoSql 的特點，方便技術選型，

1、KV 型 NoSql（代表——Redis）

KV 型 NoSql 顧名思義就是以鍵值對形式存盤的非關系型資料庫，是最常見的一種 NoSql，Redis、MemCache 是其中的代表，Redis 又是 KV 型 NoSql 中應用最廣泛的 NoSql，KV 型資料庫以 Redis 為例，最大的優點總結下來主要有兩點：

資料基于記憶體，讀寫效率高，

KV 型資料，時間復雜度為 O(1)，查詢速度快，

所以說，KV 型 NoSql 最大的優點就是高性能，利用 Redis 自帶的 BenchMark 做基準測驗，TPS 可達到 10 萬的級別，性能非常強勁，同樣的 Redis 也有所有 KV 型 NoSql 都有的比較明顯的缺點：

記憶體是有限的，無法支持海量資料存盤，

只能根據 K 查 V，無法根據 V 查 K，

查詢方式單一，只有 KV 的方式，不支持條件查詢，多條件查詢唯一的做法就是資料冗余，但這會浪費很多存盤空間，

由于 KV 型 NoSql 的存盤是基于記憶體的，會有丟失資料的風險（有持久化存盤方案），

綜上所述，KV 型 NoSql 最合適的場景就是快取的場景：

讀遠多于寫，

沒有持久化的需求，可以容忍資料丟失，

針對那些讀遠多于寫的資料，引入一層快取，每次讀從快取中讀取，快取中讀取不到，再去資料庫中取，取完之后再寫入到快取，對資料做好失效機制通常就沒有大問題了，通常來說，快取是性能優化的第一選擇也是見效最明顯的方案，

2、搜索型 NoSql（代表——ElasticSearch）

傳統關系型資料庫主要通過索引來達到快速查詢的目的，但是在全文搜索的場景下，索引是無能為力的，like 查詢無法滿足所有模糊匹配需求，使用限制太大且使用不當容易引起慢查詢問題，搜索型 NoSql 的誕生正是為了解決關系型資料庫全文搜索能力較弱的問題，ElasticSearch 是搜索型 NoSql 的代表產品，

全文搜索的原理是倒排索引，我們看一下什么是倒排索引，它是關鍵字 –> 檔案的映射，舉例來說，現在這里有四個短句：

"Tom is Tom"

"Tom is my friend"

"Thank you, Betty"

"Tom is Betty's husband"

搜索引擎會根據一定的分詞規則將一句話切成多個關鍵字，并以關鍵字的維度維護關鍵字在每個文本中的出現次數，這樣下次搜索“Tom”關鍵字的時候，由于 Tom 這個詞語在“Tom is Tom”、“Tom is my friend”、“Tom is Betty’s husband” 三句話中都出現過，因此這三條記錄都會被檢索出來，而且由于”Tom is Tom” 這句話中”Tom” 出現了 2 次，因此這條記錄對”Tom” 這個單詞的匹配度最高，最先展示，這就是搜索引擎倒排索引的基本原理，假設某個關鍵字在某個檔案中出現，那么倒排索引中有兩部分內容：

檔案 ID

該關鍵字在該檔案中出現的位置情況

相對應的，我們搜索”Betty Tom” 這兩個詞語也是一樣，搜索引擎將”Betty Tom” 切分為”Tom”、”Betty” 兩個單詞，根據開發者指定的滿足率，比如滿足率 = 50%，那么只要記錄中出現了兩個單詞之一的記錄都會被檢索出來，再按照匹配度進行展示，

搜索型 NoSql 以 ElasticSearch 為例，它的優點為：

1）支持分詞場景、全文搜索，這是區別于關系型資料庫最大特點，

2）資料寫檔案無丟失風險，在集群環境下可以方便橫向擴展，可承載 PB 級別的資料，

3）支持條件查詢，支持聚合操作，類似關系型資料庫的 Group By，但是功能更加強大，適合做資料分析，

4）高可用，自動發現新的或者失敗的節點，重組和重新平衡資料，確保資料是安全和可訪問的，

同樣，ElasticSearch 也有比較明顯的缺點：

1）性能全靠記憶體來頂，也是使用的時候最需要注意的點，非常吃記憶體，大資料量下 64G + SSD 基本就是標配，相同的配置多一倍記憶體，一個月差不多就要多花好多錢，至于 ElasticSearch 記憶體主要用在以下幾個地方：

Indexing Buffer----ElasticSearch 基于 Luence，Lucene 的倒排索引是先在記憶體里生成，然后定期以 Segment File 的方式刷磁盤的，每個 Segment File 實際就是一個完整的倒排索引，

各類快取 ----Filter Cache、Field Cache、Indexing Cache 等，用于提升查詢分析性能，例如 Filter Cache 用于快取使用過的 Filter 的結果集，

Segment Memory---- 倒排索引前面說過是基于關鍵字的，Lucene 在 4.0 后會將所有關鍵字以 FST 這種資料結構的方式將所有關鍵字在啟動的時候全量加載到記憶體，加快查詢速度，官方建議至少留系統一半記憶體給 Lucene，

Cluter State Buffer----ElasticSearch 被設計為每個 Node 都可以回應用戶請求，因此每個 Node 的記憶體中都包含有一份集群狀態的拷貝，一個規模很大的集群這個狀態資訊可能會非常大，

2）資料結構靈活性不高，欄位一旦建立就沒法修改型別了，假如建立的資料表某個欄位沒有加全文索引，想加上，那么只能把整個表刪了再重建，

3）讀寫之間有延遲，寫入的資料差不多 1s 樣子會被讀取到（資料寫入時需要維護很多索引），

因此，搜索型 NoSql 最適用的場景就是有條件搜索尤其是全文搜索的場景，作為關系型資料庫的一種替代方案，通常搜索型 NoSql 也會作為一層前置快取，來對關系型資料庫進行保護，

此外，搜索型資料庫還有一種非常重要的應用場景，我們可以想，一旦對資料庫做了分庫分表后，原來可以在單表中做的聚合操作、統計操作是否統統失效？例如我把訂單表分 16 個庫，1024 張表，那么訂單資料就散落在 1024 張表中，我想要統計昨天浙江省單筆成交金額最高的訂單是哪筆如何做？這就是搜索型 NoSql 的另一大作用了，我們可以把分表之后的資料統一打在搜索型 NoSql 中，利用搜索型 NoSql 的搜索與聚合能力完成對全量資料的查詢，

3、列式 NoSql（代表——HBase）

列式 NoSql 和關系型資料庫一樣都有主鍵的概念，區別在于關系型資料庫是按照行組織的資料，資料欄位即使沒有值同樣占空間，列式存盤完全是另一種方式，它是按列進行資料組織的，好處在于：

查詢時只有指定的列會被讀取，不會讀取所有列，

存盤上節約空間，空值不會被存盤，一列中有時候會有很多重復資料（尤其是列舉資料，性別、狀態等欄位），這類資料可壓縮，

列資料被組織到一起，一次磁盤 IO 可以將一列資料一次性讀取到記憶體中，

大資料時代最具代表性的技術之一 HBase 就是列式 NoSQL 的產品實作，其優點主要是：

海量資料存盤，PB 級別資料隨便存，底層基于 HDFS（Hadoop 檔案系統），資料持久化，

讀寫性能好，只要沒有濫用造成資料熱點，讀寫基本沒任何問題，

橫向擴展在關系型資料庫及非關系型資料庫中都是最方便的之一，只需要添加新機器就可以實作資料容量的線性增長，且可用在廉價服務器上，節省成本，

可存盤結構化或者半結構化的資料，

本身沒有單點故障，可用性高，

列數理論上無限制，HBase 本身只對列族數量有要求，建議 1~3 個，

缺點主要表現在：

HBase 是 Hadoop 生態的一部分，因此它本身是一款比較重的產品，依賴很多 Hadoop 組件，資料規模不大沒必要用，運維還是有點復雜的，

不支持分頁查詢，因為統計不了資料總數，

KV 式存盤，條件查詢很弱，HBase 在 Scan 掃描一批資料的情況下還是提供了前綴匹配這種 API 的，條件查詢除非定義多個 RowKey 做資料冗余，

因此 HBase 比較適用于 KV 型存盤且未來無法預估資料增長量的場景，另外 HBase 使用還是需要一定的經驗，主要體現在 RowKey 的設計上，

4、檔案型 NoSql（代表——MongoDB）

檔案型 NoSql 指的是將半結構化資料存盤為檔案的一種 NoSql，檔案型 NoSql 通常以 JSON 或者 XML 格式存盤資料，因此檔案型 NoSql 是沒有 Schema 的，由于沒有 Schema 的特性，我們可以隨意地存盤與讀取資料，因此檔案型 NoSql 的出現是解決關系型資料庫表結構擴展不方便的問題的，

MongoDB 是檔案型 NoSql 的代表產品，同時也是所有 NoSql 產品中的明星產品之一，它的很多概念與關系資料庫類似，因此，對于 MongDB，我們只需要理解成一個 Free-Schema 的關系型資料庫就好了，其優點主要是：