前言

在互聯網和大數據的背景下，越來越多的網站、應用系統需要支撐 海量數據存儲、高并發請求、高可用、高可擴展性 等特性要求。傳統的 關系型數據庫 已經難以應對類似的需求，各種各樣的 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。

把 不同列 的 匹配結果 進行 位運算 得到符合所有條件的 記錄下標。

使用這個 下標組裝 出最終的 結果集。

• 適合做聚合操作

• 適合大量的數據而不是小數據

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?[k?'s?ndr?]?

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

?

4.2.3. Memcached

Memcached 是一個 開放源代碼、高性能、分配的 內存對象緩存系統。用于加速動態 web 應用程序，減輕關系型數據庫負載。它可以應對 任意多個連接，使用 非阻塞的網絡 IO。由于它的工作機制是在內存中開辟一塊空間，然后建立一個 Hash 表，Memcached 自管理這些 Hash 表。

Memcached 簡單而強大。它簡單的設計促進 迅速部署，易于發現所面臨的問題，解決了很多 大型數據緩存。

image

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- 樹儲存引擎 之上。

[圖片上傳失敗...(image-fe7dcf-1536933787428)]

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），是一種 索引方法，其基本原理是建立 單詞 到 文檔 的索引。與之相對是，是 正排索引，其基本原理是建立 文檔 到 單詞 的索引。

• 現在有如下文檔集合：

[圖片上傳失敗...(image-695617-1536933787428)]

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

[圖片上傳失敗...(image-35c3a2-1536933787428)]

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

• 簡單的 倒排索引 如下：

image

• 帶有 單詞頻率 信息的 倒排索引 如下：

image

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

6.3. 常見全文搜索引擎

6.3.1. ElasticSearch

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

image

6.3.2. Solr

Solr 是 Apache Lucene 項目的 開源企業搜索平臺。其主要功能包括 全文檢索、命中標示、分面搜索、動態聚類、數據庫集成，以及 富文本（比如 Word、PDF）處理等等。Solr 是高度 可擴展 的，并提供了 分布式搜索 和 索引復制。

image

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 也可以被看作是一個 高性能的圖引擎。程序員工作在一個 面向對象的、靈活的網絡結構 下而不是 嚴格、靜態 的 表中。

image

7.2.2. ArangoDB

ArangoDB 是一個 原生多模型 數據庫系統。數據庫系統支持 三個 重要的 數據模型（鍵/值，文檔，圖形）。

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

image

7.3. 基本原理

圖形數據庫，以 Neo4j 為例說明：

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

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

針對關系數據，兩種數據庫的 存儲結構 分別如下：

image

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

image

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://www.jianshu.com/p/a586a8bf13f7
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的浅谈常见的NoSQL技术方案和选型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。