前言

在網際網路和大資料的背景下，越來越多的網站、應用系統需要支撐 海量資料儲存、高併發請求、高可用、高可擴充套件性 等特性要求。傳統的 關係型資料庫 已經難以應對類似的需求，各種各樣的 NoSQL（Not Only SQL）資料庫因此而產生。

本文將分析 傳統資料庫 的存在的問題，以及幾類 NoSQL 如何解決這些問題。在不同的 業務場景 下，作出正確的 資料儲存 技術選型。

正文

1. 傳統資料庫缺點

缺點	解釋說明
大資料場景下 I/O 較高	因為資料是按 行儲存，即使只針對其中 某一列 進行運算，關係型資料庫也會對 整行資料 進行掃描，從儲存裝置中 讀入記憶體，導致 I/O 較高
結構化儲存 不夠靈活	儲存的是 行記錄，無法儲存 靈活的資料結構
表結構 schema 擴充套件不方便	如要需要修改 表結構，需要執行執行 DDL（data definition language）語句修改，修改期間會導致 鎖表，部分服務不可用
全文搜尋 功能較弱	關係型資料庫只能夠進行 子字串 的 匹配查詢，當表的資料逐漸變大的時候，即使在有 索引 的情況下，like 掃表查詢的匹配會 非常慢
難以 儲存 和 處理 複雜 關係型資料	傳統的關聯式資料庫，並不擅長處理 資料點之間 的關係

2. NoSQL簡介

NoSQL，泛指 非關係型 的資料庫，可以理解為 關係型 資料庫的一個有力補充。

NoSQL 在許多方面效能大大優於 非關係型 資料庫的同時，往往也伴隨一些特性的缺失。比較常見的是 事務功能 的缺失。 資料庫事務正確執行的四個基本要素 ACID 如下：

	名稱	描述
A	Atomicity(原子性)	一個事務中的所有操作，要麼全部完成，要麼全部不完成，不會在中間某個環節結束。事務在執行過程中發生錯誤，會被回滾到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
C	Consistency一致性	在事務開始之前和事務結束以後，資料庫的完整性沒有被破壞。
I	Isolation隔離性	資料庫允許多個併發事務同時對資料進行讀寫和修改的能力。隔離性可以防止多個事務併發執行時由於交叉執行而導致資料的不一致。
D	Durability永續性	事務處理結束後，對資料的修改就是永久的，即便系統故障也不會丟失。

針對傳統 關係型資料庫 的不足，下面介紹常見的 5 大類 NoSQL 解決方案：

3. 列式資料庫

列式資料庫 是以 列相關儲存架構 進行資料儲存的資料庫，主要適合於 批量資料處理 和 即時查詢。相對應的是 行式資料庫，資料以 行相關的儲存架構 進行空間分配，主要適合於 小批量 的 資料處理，常用於 聯機事務型資料處理。

基於列式資料庫的 列儲存特性，可以解決某些特定場景下 關係型資料庫 高 I/O 的問題。

3.1. 基本原理

傳統關係型資料庫是 按照行 來儲存資料庫，稱為 行式資料庫，而 列式資料庫 是 按照列 來儲存資料。

將表放入儲存系統中有兩種方法，而我們絕大部分是採用 行儲存 的。行儲存法是將 各行 放入 連續的物理位置，這很像傳統的記錄和檔案系統。

列儲存法 是將資料 按照列 儲存到資料庫中，與 行儲存 類似，下圖是兩種儲存方法的圖形化解釋：

3.2. 常見列式資料庫

3.2.1. HBase

HBase 是一個開源的 非關係型分散式資料庫（NoSQL），它參考了 谷歌 的 BigTable 建模，實現的程式語言為 Java。它是 Apache 軟體基金會的 Hadoop 專案的一部分，執行於 HDFS 檔案系統之上，為 Hadoop 提供類似於 BigTable 規模的服務。因此，它可以 容錯地 儲存 海量稀疏 的資料。

3.2.2. BigTable

BigTable 是一種 壓縮的、高效能的、高可擴充套件性的，基於 Google 檔案系統（Google File System，GFS）的資料儲存系統，用於儲存 大規模結構化資料，適用於雲端計算。

3.3. 相關特性

3.3.1. 優點

• 高效的儲存空間利用率

列式資料庫 針對不同列的 資料特徵 而發明了 不同演算法，使其比 行式資料庫 高的多的 壓縮率。普通的 行式資料庫 一般壓縮率在 3：1 到 5：1 左右，而 列式資料庫 的壓縮率一般在 8：1 到 30：1 左右。

比較常見的，通過 字典表 壓縮資料：

下面才是那張表本來的樣子。經過 字典表 進行 資料壓縮 後，表中的 字串 才都變成 數字。正因為每個字串在 字典表 裡只 出現了一次，所以達到了 壓縮 的目的。

• 查詢效率高

讀取多條資料的 同一列效率高，因為這些列都是 儲存在一起的，一次磁碟操作可以資料的 指定列 全部讀取到 記憶體 中。 下圖通過 一條查詢 的執行過程說明 列式儲存 （以及 資料壓縮）的優點。

執行步驟如下：

1. 去 字典表 裡找到 字串對應數字（只進行一次字串比較）。
2. 用 數字 去列表裡匹配，匹配上的位置設為 1。
3. 把 不同列 的 匹配結果 進行 位運算 得到符合所有條件的 記錄下標。
4. 使用這個 下標組裝 出最終的 結果集。

• 適合做聚合操作

• 適合大量的資料而不是小資料

3.3.2. 缺點

• 不適合掃描 小量資料

• 不適合 隨機的更新

• 不適合做含有刪除和更新的 實時操作

• 單行資料 支援 ACID 的 事務操作，多行資料 的 事務操作，不支援事務的 正常回滾，支援 （Isolation）隔離性、(Durability）永續性，不能保證 (Atomicity）原子性、（Consistency）一致性。

3.4. 應用場景

列資料庫的適用場景，以 HBase 為例說明：

• 適合 大資料量 (100TB 級資料），有 快速隨機訪問 的需求。

• 適合 寫密集型 應用，每天寫入量巨大，而 讀數量相對較小 的應用，比如 IM 的 歷史訊息，遊戲日誌 等等。

• 適合不需要 複雜查詢 條件來查詢資料的應用。HBase 只支援基於 rowkey 的查詢，對於 HBase 來說，單條記錄 或者 小範圍的查詢 是可以接受的。大範圍 的查詢由於 分散式 的原因，可能在 效能 上有點影響。HBase 不適用於有 join，多級索引，表關係複雜 的資料模型。

• 對 效能 和 可靠性 要求非常高的應用。

• 由於 HBase 本身沒有 單點故障，可用性 非常高。

• 適合 資料量較大，而且 增長量 無法預估的應用，需要進行優雅的資料擴充套件的應用。HBase 支援 線上擴充套件，即使在一段時間內，資料量呈 井噴式增長，也可以通過 HBase 橫向擴充套件 來滿足功能。

• 儲存 結構化 和 半結構化 的資料。

4. K-V資料庫

4.1. 基本概念

指的是使用 鍵值（key-value）儲存的資料庫，其資料按照 鍵值對 的形式進行 組織、索引 和 儲存。

KV 儲存非常適合不涉及過多 資料關係 業務的資料。它能夠有效減少 讀寫磁碟 的次數，比 SQL 資料庫儲存 擁有更好的 讀寫效能，能夠解決 關係型資料庫 無法儲存 資料結構 的問題。

4.2. 常見K-V資料庫

4.2.1. Redis

Redis 是一個使用 ANSI C 編寫的 開源、支援網路、基於記憶體、可選永續性 的 鍵值對儲存 資料庫。Redis 是目前最流行的 鍵值對儲存 資料庫之一。

4.2.2. Cassandra

Apache Cassandra（社群內一般簡稱為 C*）是一套 開源的分散式 NoSQL 資料庫系統。它最初由 Facebook 開發，用於儲存 收件箱 等簡單格式資料，集 Google BigTable 的 資料模型 與 Amazon Dynamo 的 完全分散式 架構於一身。Cassandra 是一種流行的 分散式結構化 資料儲存方案。

4.2.3. Memcached

Memcached 是一個 開放原始碼、高效能、分配的 記憶體物件快取系統。用於加速動態 web 應用程式，減輕關係型資料庫負載。它可以應對 任意多個連線，使用 非阻塞的網路 IO。由於它的工作機制是在記憶體中開闢一塊空間，然後建立一個 Hash 表，Memcached 自管理這些 Hash 表。

Memcached 簡單而強大。它簡單的設計促進 迅速部署，易於發現所面臨的問題，解決了很多 大型資料快取。

4.2.4. LevelDB

LevelDB 是一個由 Google 所研發的 鍵／值對（Key/Value Pair）嵌入式 資料庫管理系統 程式設計庫，以開源的 BSD 許可證釋出。

4.3. 相關特性

K-V 資料庫的相關特性，以 Redis 為例說明：

4.3.1. 優點

• 效能極高

Redis 單機最高能支援超過 10W 的 TPS。

• 豐富的資料型別

Redis 支援包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperloglog 等資料結構。

• 豐富的特性

Redis 還支援 publish/subscribe，通知，key 過期 等特性。

4.3.2. 缺點

• Redis 事務 不能支援 原子性 和 永續性（A 和 D），只支援 隔離性 和 一致性（I 和 C）。

這裡所說的 無法保證原子性，是針對 Redis 的 事務操作，因為事務是 不支援回滾（roll back），而因為 Redis 的 單執行緒模型，Redis 的普通操作是 原子性的。

4.4 應用場景

4.4.1. 適用場景

• 適合儲存 使用者資訊（比如 會話）、配置檔案、引數、購物車 等等。這些資訊一般都和 ID 掛鉤。

4.4.2. 不適用場景

• 不適合需要通過 值 來查詢，而不是 鍵 來查詢。Key-Value 資料庫中根本沒有通過 值查詢 的途徑。

• 不適合需要儲存 資料之間的關係。在 Key-Value 資料庫中不能通過 兩個或以上 的鍵來 關聯資料。

• 不適合需要支援 事務 的場景。在 Key-Value 資料庫中 故障產生 時不可以進行 回滾。

5. 文件型資料庫

5.1. 基本概念

文件資料庫 用於將 半結構化資料 儲存為 文件 的一種資料庫。文件資料庫通常以 JSON 或 XML 格式儲存資料。

• 由於文件資料庫的 no-schema 特性，可以 儲存 和 讀取 任意資料。

• 由於使用的 資料格式 是 JSON 或者 BSON，因為 JSON 資料是 自描述的，無需在使用前定義欄位，讀取一個 JSON 中 不存在的欄位 也不會導致 SQL 那樣的語法錯誤，可以解決關係型資料庫 表結構 schema 擴充套件不方便 的問題。

5.2. 常見文件資料庫

5.2.1. MongoDB

MongoDB 是一個基於 分散式檔案儲存 的資料庫。由 C++ 語言編寫。旨在為 WEB 應用提供可擴充套件的 高效能 資料儲存解決方案。

MongoDB 是一個介於 關聯式資料庫 和 非關聯式資料庫 之間的產品，是非關聯式資料庫當中功能 最豐富，最像關聯式資料庫的 NoSQL。

5.2.2. CouchDB

CouchDB 是用 Erlang 開發的 面向文件 的 分散式 資料庫，用於儲存 半結構化 的資料，比較類似 lucene 的 index 結構。

CouchDB 支援 RESTful API，它使用 JSON 作為 儲存格式，JavaScript 作為 查詢語言，MapReduce 和 HTTP 作為 API 的 NoSQL 資料庫。其中一個顯著的功能就是 多主複製 功能。除此之外，CouchDB 構建在強大的 B- 樹儲存引擎 之上。

5.3. 相關特性

文件型資料庫 的相關特性，以 MongoDB 為例進行說明：

5.3.1. 優點

• 新增欄位簡單不需要像關係型資料庫一樣，先執行 DDL 語句 修改表結構，程式程式碼 直接讀寫 即可。

• 容易相容 歷史資料。對於歷史資料，即使沒有新增的欄位，也不會導致錯誤，只會返回 空值，此時 程式碼相容處理 即可。

• 容易儲存複雜資料。JSON 是一種強大的 描述語言，能夠描述複雜的 資料結構。

5.3.2. 缺點

相比 傳統關係型資料庫，文件資料庫的缺點，主要是對 多條資料記錄 的 事務支援較弱，具體體現如下：

• Atomicity（原子性）：僅支援 單行/文件級原子性，不支援 多行、多文件、多語句原子性。

• Isolation（隔離性）：隔離級別僅支援 已提交讀（Read committed）級別，可能導致 不可重複讀，幻讀 的問題。

• 不支援 複雜查詢。例如 join 查詢，如果需要 join 查詢，需要 多次運算元據庫。

5.4. 應用場景

5.4.1. 適用場景

• 資料量 很大或者未來會變得很大。

• 表結構不明確，且 欄位 在 不斷增加，例如內容管理系統，資訊管理系統。

5.4.2. 不適用場景

• 在不同的文件上需要新增 事務。Document-Oriented 資料庫並不支援 文件間的事務。

• 多個文件之間需要 複雜的查詢，例如 join 操作。

6. 全文搜尋引擎

6.1. 基本概念

傳統關係型資料庫，主要通過 索引 來達到 快速查詢 的目的。在 全文搜尋 的業務下，索引 也無能為力，主要體現在以下幾方面：

• 全文搜尋的條件，可以隨意 排列組合，如果通過索引來滿足，則索引的 數量非常多。

• 全文搜尋的 模糊匹配方式，索引 無法滿足，只能用 like 進行查詢，而 like 查詢是 整表掃描，效率非常低。

全文搜尋引擎的出現，正是解決關係型資料庫 全文搜尋較弱 的問題。

6.2. 基本原理

全文搜尋引擎 的技術原理稱為 倒排索引（inverted index），是一種 索引方法，其基本原理是建立 單詞 到 文件 的索引。與之相對是，是 正排索引，其基本原理是建立 文件 到 單詞 的索引。

• 現在有如下文件集合：

• 正排索引 得到索引如下：

可見，正排索引 適用於根據 文件名稱 查詢 文件內容。

• 簡單的 倒排索引 如下：

• 帶有 單詞頻率 資訊的 倒排索引 如下：

可見，倒排索引 適用於根據 關鍵詞 來查詢 文件內容。

6.3. 常見全文搜尋引擎

6.3.1. ElasticSearch

ElasticSearch 是一個基於 Apache Lucene 的 搜尋引擎。它提供了一個 分散式，多租戶 對全文搜尋引擎。ElasticSearch 是用 Java 開發的，對外提供 RESTful Web 介面。根據 DB-Engines 排名，ElasticSearch 是最受歡迎的 企業搜尋引擎。

6.3.2. Solr

Solr 是 Apache Lucene 專案的 開源企業搜尋平臺。其主要功能包括 全文檢索、命中標示、分面搜尋、動態聚類、資料庫整合，以及 富文字（比如 Word、PDF）處理等等。Solr 是高度 可擴充套件 的，並提供了 分散式搜尋 和 索引複製。

6.4. 相關特性

全文搜尋引擎，以 ElasticSearch 為例說明：

6.4.1. 優點

• 查詢效率高，適用於對 海量資料 進行 近實時 的處理。

• 可擴充套件性

• 基於 叢集 環境可以方便 橫向擴充套件，可以承載 PB 級的資料。

• 支援 高可用，ElasticSearch 叢集彈性靈活，可以發現新的或失敗的節點，重組 和 重新平衡 資料，確保資料是 安全 和 可訪問的。

6.4.2. 缺點

• 事務的 ACID 支援不足，單一文件 的資料是支援 ACID 的。對於 多個文件 的 事務操作，不支援事務的 正常回滾。支援（Isolation）隔離性（基於 樂觀鎖機制）和（Durability）永續性，不支援（Atomicity）原子性，（Consistency）一致性。

• 對類似資料庫中，通過 外來鍵 進行 多表關聯的複雜操作支援較弱。

• 讀寫 有一定 延時，寫入的資料，最快 1s 中能被檢索到。

• 更新 效能較低，底層實現是 先刪資料，再 插入新資料。

• 記憶體佔用大，因為 Lucene 將 索引部分 載入到 記憶體 中。

6.5. 應用場景

6.5.1. 適用場景

• 分散式的 搜尋引擎 和 資料分析引擎。
• 全文檢索，結構化檢索 以及 資料分析。
• 對海量資料進行 近實時 的處理，可以將 海量資料 分散到 多臺伺服器 上去 儲存 和 檢索。

6.5.2. 不適用場景

• 資料需要 頻繁更新。

• 需要 複雜關聯查詢。

7. 圖形資料庫

7.1. 基本概念

圖形資料庫 應用 圖形理論 儲存 實體 之間的 關係資訊。最常見例子就是 社會網路中人與人之間的關係。關係型資料庫 用於儲存這種 關係型資料 的效果並不好，其查詢 複雜、緩慢、超出預期。

圖形資料庫 的獨特設計彌補了這個缺陷，解決 關係型 資料庫 儲存 和 處理複雜關係型資料 功能較弱的問題。

7.2. 常見圖形資料庫

7.2.1. Neo4j

Neo4j 是一個 高效能的，NOSQL 圖形資料庫，它將 結構化資料 儲存在 “圖形網路上” 而不是 “表中”。它是一個 嵌入式的、基於磁碟的、具備完全的 事務特性 的 Java 持久化引擎。

Neo4j 也可以被看作是一個 高效能的圖引擎。程式設計師工作在一個 物件導向的、靈活的網路結構 下而不是 嚴格、靜態 的 表中。

7.2.2. ArangoDB

ArangoDB 是一個 原生多模型 資料庫系統。資料庫系統支援 三個 重要的 資料模型（鍵/值，文件，圖形）。

ArangoDB 包含一個 資料庫核心 和 統一查詢語言 AQL（ArangoDB 查詢語言）。查詢語言是 宣告性的，允許在 單個查詢 中 組合 不同的 資料訪問模式。ArangoDB 是一個 NoSQL 資料庫系統，但 AQL 在很多方面與 SQL 都類似。

7.3. 基本原理

圖形資料庫，以 Neo4j 為例說明：

• Neo4j 使用 資料結構 中圖（graph）的概念來進行 建模。

• Neo4j 中兩個最基本的概念是 節點 和 邊。節點 表示 實體，邊 則表示 實體之間的關係。節點 和 邊 都可以有自己的 屬性。不同 實體 通過各種不同的 關係 關聯起來，形成複雜的 物件圖。

針對關係資料，兩種資料庫的 儲存結構 分別如下：

在 Neo4j 中，儲存節點 時使用了 index-free adjacency，即 每個節點 都有指向其 鄰居節點 的 指標。這樣就可以在 O(1) 的 複雜度 內找到 鄰居節點。另外，按照官方的說法，在 Neo4j 中 邊 s是最重要的，是 first-class entities，需要 單獨儲存。這有利於在 圖遍歷 的時候 提高速度，也可以很方便地以 任何方向 進行遍歷。

7.4. 相關特性

7.4.1. 優點

• 高效能表現

圖的遍歷 是 圖資料結構 所具有的獨特演算法，即從 一個節點 開始，根據其連線的 關係，可以快速和方便地找出它的 鄰近節點。這種查詢資料的方法不受 資料量大小 的影響，因為 鄰近查詢 始終查詢的是 有限的區域性資料，不會對 整個資料庫 進行搜尋。

• 設計的靈活性

資料結構 的自然伸展特性，以及其 非結構化 的 資料格式，讓圖資料庫設計可以具有很大的 伸縮性 和 靈活性。因為隨著需求的變化而增加的 節點、關係 及其 屬性，並不會影響到 原來資料 的正常使用。

• 開發的敏捷性

資料模型 直接明瞭，從需求的討論開始，到程式開發和實現，基本上不會有大的變化。

• 完全支援ACID

不像別的 NoSQL 資料庫，Neo4j 還完全具有 事務管理特性，完全支援 ACID 事務管理。

7.4.2. 缺點

• 節點，關係 和它們的 屬性 的數量被 限制。

• 不支援 拆分。

7.5. 應用場景

7.5.1. 適用場景

• 在一些 關係性強 的資料應用，例如 社交網路。

• 推薦引擎，將資料以 圖的形式 表現，非常有益於推薦的制定。

7.5.2. 不適用場景

• 記錄大量 基於事件 的資料，如日誌記錄、感測器資料。

• 對大規模 分散式資料 進行處理，類似於 Hadoop。

• 不適用於應該儲存在 關係型資料庫 中的 結構化資料。

• 二進位制資料儲存。

小結

關於 關係型資料庫 和 NoSQL 資料庫 的選型，往往需要考慮幾個指標：

• 資料量
• 併發量
• 實時性
• 一致性要求
• 讀寫分佈
• 資料型別
• 安全性
• 運維成本

常見的系統資料庫選型參考如下：

系統型別	資料庫選型
企業內部管理系統	例如運營系統，資料量少，併發量小，首選考慮 關係型資料庫
網際網路大流量系統	例如電商單品頁，後臺考慮選 關係型資料庫，前臺考慮選 記憶體型資料庫
日誌型系統	原始資料 考慮選 列式資料庫，日誌搜尋 考慮選 倒排索引
搜尋型系統	例如站內搜尋，非通用搜尋，商品搜尋，後臺考慮選 關係型資料庫，前臺考慮選 倒排索引
事務型系統	例如庫存管理，交易，記賬，考慮選 關係型資料庫 + 快取資料庫 + 一致性型協議
離線計算	例如大量資料分析，考慮選 列式資料庫 或者 關係型資料庫 都可以
實時計算	例如實時監控，可以考慮選 記憶體型資料庫 或者 列式資料庫

設計實踐中，要基於需求、業務驅動架構，無論選用 RDB/NoSQL/DRDB。一定是以需求為導向，最終資料儲存方案，必然是考慮各種 權衡 的綜合性設計。

---

歡迎關注技術公眾號： 零壹技術棧

本帳號將持續分享後端技術乾貨，包括虛擬機器基礎，多執行緒程式設計，高效能框架，非同步、快取和訊息中介軟體，分散式和微服務，架構學習和進階等學習資料和文章。

來源：https://juejin.im/post/5b85114be51d4559a81eda73#comment