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

• 日常開發(fā)中常用的存儲方案選型很多都是 “拿來主義” 的，憑借著經驗、習慣選用，但對它們的細節(jié)特性或約束少有研究。
• 除了手邊會用的存儲方案，也應該關注市面上更合適的存儲方案。
• 一定的技術預研和儲備能夠幫助未來更好的技術方案設計。

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

存儲選型的考慮要素

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

• 用戶量：用戶量預估多少？幾百幾萬還是幾億？
• 數據量：數據量預估多少？日均增量能有多少？
• 讀寫偏好：數據是讀多一些還是寫多一些？
• 數據場景：強事務型還是分析型需求？
• 運行性能要求：并發(fā)量是多少？高峰、平均、低谷分別預估是多少？

存儲引擎分類及特性

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

先拿我們最熟悉的關系數據庫來說，它的優(yōu)點非常多，我們選用關系數據庫的理由可簡單概括為以下幾點：

• 容易理解

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

• 事務特性

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

• 操作方便

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

• 數據穩(wěn)定

數據持久化到磁盤，沒有丟失數據風險。

• 服務穩(wěn)定

最常用的關系型數據庫產品 MySql、Oracle 服務器性能卓越，服務穩(wěn)定，通常很少出現宕機異常。

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

• 高并發(fā)下數據庫瓶頸明顯

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

• 為維護數據一致性付出的代價大

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

• 為維護索引付出的代價大

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

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

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

• 全文搜索功能弱

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

• 表結構擴展不方便

由于數據庫存儲的是結構化數據，因此表結構 schema 是固定的，擴展不方便，如果需要修改表結構，需要執(zhí)行 DDL（data definition language）語句修改，修改期間會導致鎖表，部分服務不可用。

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

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

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

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

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

• 數據基于內存，讀寫效率高。
• KV 型數據，時間復雜度為 O(1)，查詢速度快。

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

• 內存是有限的，無法支持海量數據存儲。
• 只能根據 K 查 V，無法根據 V 查 K。
• 查詢方式單一，只有 KV 的方式，不支持條件查詢，多條件查詢唯一的做法就是數據冗余，但這會浪費很多存儲空間。
• 由于 KV 型 NoSql 的存儲是基于內存的，會有丟失數據的風險（有持久化存儲方案）。

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

• 讀遠多于寫。
• 沒有持久化的需求，可以容忍數據丟失。

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

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

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

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

• "Tom is Tom"
• "Tom is my friend"
• "Thank you, Betty"
• "Tom is Betty's husband"

搜索引擎會根據一定的分詞規(guī)則將一句話切成多個關鍵字，并以關鍵字的維度維護關鍵字在每個文本中的出現次數。這樣下次搜索“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” 兩個單詞，根據開發(fā)者指定的滿足率，比如滿足率 = 50%，那么只要記錄中出現了兩個單詞之一的記錄都會被檢索出來，再按照匹配度進行展示。

搜索型 NoSql 以 ElasticSearch 為例，它的優(yōu)點為：

1）支持分詞場景、全文搜索，這是區(qū)別于關系型數據庫最大特點。

2）數據寫文件無丟失風險，在集群環(huán)境下可以方便橫向擴展，可承載 PB 級別的數據。

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

4）高可用，自動發(fā)現新的或者失敗的節(jié)點，重組和重新平衡數據，確保數據是安全和可訪問的。

同樣，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 這種數據結構的方式將所有關鍵字在啟動的時候全量加載到內存，加快查詢速度，官方建議至少留系統(tǒng)一半內存給 Lucene。
• Cluter State Buffer----ElasticSearch 被設計為每個 Node 都可以響應用戶請求，因此每個 Node 的內存中都包含有一份集群狀態(tài)的拷貝，一個規(guī)模很大的集群這個狀態(tài)信息可能會非常大。

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

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

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

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

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

列式 NoSql 和關系型數據庫一樣都有主鍵的概念，區(qū)別在于關系型數據庫是按照行組織的數據，數據字段即使沒有值同樣占空間，列式存儲完全是另一種方式，它是按列進行數據組織的，好處在于：

• 查詢時只有指定的列會被讀取，不會讀取所有列。
• 存儲上節(jié)約空間，空值不會被存儲，一列中有時候會有很多重復數據（尤其是枚舉數據，性別、狀態(tài)等字段），這類數據可壓縮。
• 列數據被組織到一起，一次磁盤 IO 可以將一列數據一次性讀取到內存中。

大數據時代最具代表性的技術之一 HBase 就是列式 NoSQL 的產品實現，其優(yōu)點主要是：

• 海量數據存儲，PB 級別數據隨便存，底層基于 HDFS（Hadoop 文件系統(tǒng)），數據持久化。
• 讀寫性能好，只要沒有濫用造成數據熱點，讀寫基本沒任何問題。
• 橫向擴展在關系型數據庫及非關系型數據庫中都是最方便的之一，只需要添加新機器就可以實現數據容量的線性增長，且可用在廉價服務器上，節(jié)省成本。
• 可存儲結構化或者半結構化的數據。
• 本身沒有單點故障，可用性高。
• 列數理論上無限制，HBase 本身只對列族數量有要求，建議 1~3 個。

缺點主要表現在：

• HBase 是 Hadoop 生態(tài)的一部分，因此它本身是一款比較重的產品，依賴很多 Hadoop 組件，數據規(guī)模不大沒必要用，運維還是有點復雜的。
• 不支持分頁查詢，因為統(tǒng)計不了數據總數。
• 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 的關系型數據庫就好了，其優(yōu)點主要是：

• 沒有預定義的字段，擴展字段容易。
• 相較于關系型數據庫，讀寫性能優(yōu)越，命中二級索引的查詢不會比關系型數據庫慢，對于非索引字段的查詢則是全面勝出。

缺點在于：

• 不支持事務操作，雖然 Mongodb4.0 之后宣稱支持事務，但是效果待觀測。
• 多表之間的關聯(lián)查詢不支持（雖然有嵌入文檔的方式），join 查詢還是需要多次操作。
• 空間占用較大，這個是 MongDB 的設計問題，空間預分配機制 + 刪除數據后空間不釋放，只有用 db.repairDatabase () 去修復才能釋放。
• 目前沒發(fā)現 MongoDB 有關系型數據庫例如 MySql 的 Navicat 這種成熟的運維工具。

總而言之，MongDB 的使用場景很大程度上可以對標關系型數據庫，但是比較適合處理那些沒有 join、沒有強一致性要求且表 Schema 會常變化的數據。

通過以上討論分析我們心中已經有了一個基本的選型框架指導，實際上在數據庫選型時回答自己兩個核心問題就好了：

• 什么時候選用關系型數據庫，什么時候選用非關系型數據庫。
• 選用非關系型數據庫的話，使用哪種非關系型數據庫。

NoSQL 數據庫都是通過犧牲了 ACID 特性來獲取更高性能的，假設表數據有很強的事務特性需求，那么這類數據是不適合放在非關系型數據庫。此外，選用 NoSQL 數據庫時也要根據公司技術棧框架、業(yè)務特性、運維成本等多方面考慮是否采納。

總結

關系型數據庫和 NoSQL 數據庫的選型，往往需要考慮幾個指標：

• 數據量
• 并發(fā)量
• 實時性
• 一致性要求
• 讀寫分布和類型
• 安全性
• 運維成本

常見軟件系統(tǒng)數據庫選型參考如下：

• 中后臺管理型系統(tǒng)  - 如運營系統(tǒng)，數據量少，并發(fā)量小，首選關系型數據庫。
• 大流量系統(tǒng)  - 如電商單品頁，后臺考慮選關系型數據庫，前臺考慮選內存型數據庫。
• 日志型系統(tǒng)  - 原始數據考慮選列式數據庫，日志搜索考慮選搜索引擎。
• 搜索型系統(tǒng)  - 例如站內搜索，非通用搜索，如商品搜索，后臺考慮選關系型數據庫，前臺考慮選搜索引擎。
• 事務型系統(tǒng)  - 如庫存，交易，記賬，考慮選關系型數據庫 + K-V 數據庫（作為緩存）+ 分布式事務。
• 離線計算 - 如大量數據分析，考慮選列式數據庫或關系型數據庫。
• 實時計算  - 如實時監(jiān)控，可以考慮選內存型數據庫或者列式數據庫。

設計實踐中，要基于需求、業(yè)務驅動架構，無論選用 RDB/NoSQL, 一定是以需求為導向，最終數據存儲方案必然是各種權衡的綜合性設計。