前言

在互聯網和大數據的背景下，越來越多的網站、應用系統需要支撐

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

正文

1. 傳統數據庫缺點

2. NoSQL簡介

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

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

針對傳統 關係型數據庫 的不足，下面介紹常見的 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

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）。

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 是一個介於 關係數據庫 和 非關係數據庫 之間的產品，是非關係數據庫當中功能

5.2.2. CouchDB

CouchDB 是用 Erlang 開發的 面向文檔 的 分佈式 數據庫，用於存儲 半結構化 的數據，比較類似 lucene 的 index 結構。

CouchDB 支持 RESTful API，它使用 JSON 作為 存儲格式

[圖片上傳失敗...(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)]

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

• 簡單的 倒排索引 如下：

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

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

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) 的 複雜度

7.4. 相關特性

7.4.1. 優點

• 高性能表現

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

• 設計的靈活性

數據結構

• 開發的敏捷性

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

• 完全支持ACID

不像別的 NoSQL 數據庫，Neo4j 還完全具有 事務管理特性

7.4.2. 缺點

• 節點，關係 和它們的 屬性 的數量被 限制。
• 不支持 拆分。

7.5. 應用場景

7.5.1. 適用場景

• 在一些 關係性強 的數據應用，例如 社交網絡。
• 推薦引擎，將數據以 圖的形式 表現，非常有益於推薦的制定。

7.5.2. 不適用場景

• 記錄大量 基於事件 的數據，如日誌記錄、傳感器數據。
• 對大規模 分佈式數據 進行處理，類似於 Hadoop。
• 不適用於應該保存在 關係型數據庫 中的 結構化數據。
• 二進制數據存儲。

小結

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

• 數據量
• 併發量
• 實時性
• 一致性要求
• 讀寫分佈
• 數據類型
• 安全性
• 運維成本

常見的系統數據庫選型參考如下：

系統類型 數據庫選型 企業內部管理系統 例如運營系統，數據量少，併發量小，首選考慮 關係型數據庫 互聯網大流量系統 例如電商單品頁，後臺考慮選 關係型數據庫，前臺考慮選 內存型數據庫 日誌型系統 原始數據 考慮選 列式數據庫，日誌搜索 考慮選 倒排索引 搜索型系統 例如站內搜索，非通用搜索，商品搜索，後臺考慮選 關係型數據庫，前臺考慮選 倒排索引 事務型系統 例如庫存管理，交易，記賬，考慮選 關係型數據庫 +

閱讀更多 程序猿的內心獨白 的文章

關鍵字: 淺談 可擴展性 Google文檔