隨著大數據時代的到來，越來越多的網站、應用系統需要支撐海量數據存儲，高并發、高可用、高可擴展性等特性要求。

傳統的關系型數據庫在應付這些已經顯得力不從心，并暴露了許多難以克服的問題。

由此，各種各樣的 NoSQL（Not Only SQL）數據庫作為傳統關系型數據的一個有力補充得到迅猛發展。

本文將分析傳統數據庫存在的一些問題，以及幾大類 NoSQL 如何解決這些問題，希望給大家提供一些在不同業務場景下存儲技術選型方面的參考。

?

傳統數據庫的缺點

---

傳統的數據庫有如下幾個缺點：

• 大數據場景下 I/O 較高，因為數據是按行存儲，即使只針對其中某一列進行運算，關系型數據庫也會將整行數據從存儲設備中讀入內存，導致 I/O 較高。

• 存儲的是行記錄，無法存儲數據結構。

• 表結構 Schema 擴展不方便，如要修改表結構，需要執行 DDL(data definition language)，語句修改，修改期間會導致鎖表，部分服務不可用。

• 全文搜索功能較弱，關系型數據庫下只能夠進行子字符串的匹配查詢，當表的數據逐漸變大的時候，like 查詢的匹配會非常慢，即使在有索引的情況下。況且關系型數據庫也不應該對文本字段進行索引。

• 存儲和處理復雜關系型數據功能較弱，許多應用程序需要了解和導航高度連接數據之間的關系，才能啟用社交應用程序、推薦引擎、欺詐檢測、知識圖譜、生命科學和 IT/網絡等用例。

  然而傳統的關系數據庫并不善于處理數據點之間的關系。它們的表格數據模型和嚴格的模式使它們很難添加新的或不同種類的關聯信息。

?

NoSQL 解決方案

---

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

在 NoSQL 許多方面性能大大優于非關系型數據庫的同時，往往也伴隨一些特性的缺失，比較常見的是事務庫事務功能的缺失。?

數據庫事務正確執行的四個基本要素?ACID 如下：

下面介紹 5 大類 NoSQL 數據針對傳統關系型數據庫的缺點和提供的解決方案：

?

列式數據庫

---

列式數據庫是以列相關存儲架構進行數據存儲的數據庫，主要適合于批量數據處理和即時查詢。

相對應的是行式數據庫，數據以行相關的存儲體系架構進行空間分配，主要適合于小批量的數據處理，常用于聯機事務型數據處理。

基于列式數據庫的列存儲特性，可以解決某些特定場景下關系型數據庫 I/O 較高的問題。

基本原理

傳統關系型數據庫是按照行來存儲數據庫，稱為“行式數據庫”，而列式數據庫是按照列來存儲數據。

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

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

常見列式數據庫

HBase：是一個開源的非關系型分布式數據庫（NoSQL），它參考了谷歌的 BigTable 建模，實現的編程語言為 Java。

它是 Apache 軟件基金會的 Hadoop 項目的一部分，運行于 HDFS 文件系統之上，為 Hadoop 提供類似于 BigTable 規模的服務。因此，它可以容錯地存儲海量稀疏的數據。

BigTable：是一種壓縮的、高性能的、高可擴展性的，基于 Google 文件系統（Google File System，GFS）的數據存儲系統，用于存儲大規模結構化數據，適用于云端計算。

相關特性

優點如下：

高效的儲存空間利用率：列式數據庫由于其針對不同列的數據特征而發明的不同算法使其往往有比行式數據庫高的多的壓縮率。

普通的行式數據庫一般壓縮率在 3：1 ?到 5：1 ?左右，而列式數據庫的壓縮率一般在 8：1 到 30：1 ?左右。

比較常見的，通過字典表壓縮數據： 下面中才是那張表本來的樣子。經過字典表進行數據壓縮后，表中的字符串才都變成數字了。

正因為每個字符串在字典表里只出現一次了，所以達到了壓縮的目的(有點像規范化和非規范化 Normalize 和 Denomalize)。

查詢效率高：讀取多條數據的同一列效率高，因為這些列都是存儲在一起的，一次磁盤操作可以把數據的指定列全部讀取到內存中。

下圖通過一條查詢的執行過程說明列式存儲(以及數據壓縮)的優點。

執行步驟如下：

• 去字典表里找到字符串對應數字(只進行一次字符串比較)。

• 用數字去列表里匹配，匹配上的位置設為 1。?

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

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

列式數據庫還適合做聚合操作，適合大量的數據而不是小數據。

缺點如下：

• 不適合掃描小量數據。

• 不適合隨機的更新。

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

• 單行的數據是 ACID 的，多行的事務時，不支持事務的正常回滾，支持 I(Isolation)隔離性(事務串行提交)，D(Durability)持久性，不能保證 A(Atomicity)原子性， C(Consistency)一致性。

使用場景

以 HBase 為例說明：

• 大數據量（100s TB級數據），且有快速隨機訪問的需求。

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

• 不需要復雜查詢條件來查詢數據的應用，HBase 只支持基于 rowkey 的查詢，對于 HBase 來說，單條記錄或者小范圍的查詢是可以接受的。

  大范圍的查詢由于分布式的原因，可能在性能上有點影響，HBase 不適用于有 join，多級索引，表關系復雜的數據模型。

• 對性能和可靠性要求非常高的應用，由于 HBase 本身沒有單點故障，可用性非常高。

• 數據量較大，而且增長量無法預估的應用，需要進行優雅的數據擴展的 HBase 支持在線擴展，即使在一段時間內數據量呈井噴式增長，也可以通過 HBase 橫向擴展來滿足功能。

• 存儲結構化和半結構化的數據。

?

K-V 數據庫

---

指的是使用鍵值(key-value)存儲的數據庫，其數據按照鍵值對的形式進行組織、索引和存儲。

K-V 存儲非常適合不涉及過多數據關系業務關系的數據，同時能有效減少讀寫磁盤的次數，比 SQL 數據庫存儲擁有更好的讀寫性能，能夠解決關系型數據庫無法存儲數據結構的問題。

常見 K-V 數據庫

Redis：是一個使用 ANSI C 編寫的開源、支持網絡、基于內存、可選持久性的鍵值對存儲數據庫。

從 2015 年 6 月開始，Redis 的開發由 Redis Labs 贊助，而 2013 年 5 月至 2015 年 6 月期間，其開發由 Pivotal 贊助。

在 2013 年 5 月之前，其開發由 VMware 贊助。根據月度排行網站 DB-Engines.com 的數據顯示，Redis 是最流行的鍵值對存儲數據庫。

Cassandra：Apache Cassandra（社區內一般簡稱為C*）是一套開源分布式 NoSQL 數據庫系統。

它最初由 Facebook 開發，用于儲存收件箱等簡單格式數據，集 Google BigTable 的數據模型與 Amazon Dynamo 的完全分布式架構于一身。

Facebook 于 2008 將 Cassandra 開源，此后，由于 Cassandra 良好的可擴展性和性能，它被 Apple，Comcas，Instagram，Spotify，eBay，Rackspace，Netflix 等知名網站所采用，成為了一種流行的分布式結構化數據存儲方案。

LevelDB：是一個由 Google 公司所研發的鍵／值對（Key/Value Pair）嵌入式數據庫管理系統編程庫， 以開源的 BSD 許可證發布。

相關特性

以 Redis 為例，K-V 數據庫優點如下：?

• 性能極高：Redis 能支持超過 10W 的 TPS。

• 豐富的數據類型：Redis 支持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperlog。

• 豐富的特性：Redis 還支持 publish/subscribe，通知，key 過期等等特性。

缺點如下：

• 針對 ACID，Redis 事務不能支持原子性和持久性(A 和 D)，只支持隔離性和一致性(I 和 C) 。

特別說明一下，這里所說的無法保證原子性，是針對 Redis 的事務操作，因為事務是不支持回滾（roll back），而因為 Redis 的單線程模型，Redis 的普通操作是原子性的。

大部分業務不需要嚴格遵循 ACID 原則，例如游戲實時排行榜，粉絲關注等場景，即使部分數據持久化失敗，其實業務影響也非常小。因此在設計方案時，需要根據業務特征和要求來做選擇。

使用場景

適用場景：

• 儲存用戶信息(比如會話)、配置文件、參數、購物車等等。這些信息一般都和 ID（鍵）掛鉤。

不適用場景：

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

• 需要儲存數據之間的關系。在 Key-Value 數據庫中不能通過兩個或以上的鍵來關聯數據。

• 需要事務的支持。在 Key-Value 數據庫中故障產生時不可以進行回滾。

?

文檔數據庫

---

文檔數據庫（也稱為文檔型數據庫）是旨在將半結構化數據存儲為文檔的一種數據庫。文檔數據庫通常以 JSON 或 XML 格式存儲數據。

由于文檔數據庫的 no-schema 特性，可以存儲和讀取任意數據。

由于使用的數據格式是 JSON 或者 BSON，因為 JSON 數據是自描述的，無需在使用前定義字段，讀取一個 JSON 中不存在的字段也不會導致 SQL 那樣的語法錯誤，可以解決關系型數據庫表結構 Schema 擴展不方便的問題。

常見文檔數據庫

MongoDB：是一種面向文檔的數據庫管理系統，由 C++ 撰寫而成，以此來解決應用程序開發社區中的大量現實問題。2007 年 10 月，MongoDB 由 10gen 團隊所發展。2009 年 2 月首度推出。

CouchDB：Apache CouchDB 是一個開源數據庫，專注于易用性和成為"完全擁抱 Web 的數據庫"。

它是一個使用 JSON 作為存儲格式，JavaScript 作為查詢語言，MapReduce 和 HTTP 作為 API 的 NoSQL 數據庫。

其中一個顯著的功能就是多主復制。CouchDB 的第一個版本發布在 2005 年，在 2008 年成為了 Apache 的項目。

相關特性

以 MongoDB 為例進行說明，文檔數據庫優點如下：?

• 新增字段簡單，無需像關系型數據庫一樣先執行 DDL 語句修改表結構，程序代碼直接讀寫即可。

• 容易兼容歷史數據，對于歷史數據，即使沒有新增的字段，也不會導致錯誤，只會返回空值，此時代碼兼容處理即可。

• 容易存儲復雜數據，JSON 是一種強大的描述語言，能夠描述復雜的數據結構。

相比傳統關系型數據庫，文檔數據庫的缺點主要是對多條數據記錄的事務支持較弱，具體體現如下：

• Atomicity(原子性)，僅支持單行/文檔級原子性，不支持多行、多文檔、多語句原子性。

• Solation(隔離性)，隔離級別僅支持已提交讀（Read committed）級別，可能導致不可重復讀，幻讀的問題。

• 不支持復雜查詢，例如 join 查詢，如果需要 join 查詢，需要多次操作數據庫。

MongonDB 還支持多文檔事務的 Consistency(一致性)和 Durability(持久性)，雖然官方宣布 MongoDB 將在 4.0 版本中正式推出多文檔 ACID 事務支持，最后落地情況還有待見證。

使用場景

適用場景：?

• 數據量很大或者未來會變得很大。

• 表結構不明確，且字段在不斷增加，例如內容管理系統，信息管理系統。

不適用場景：

• 在不同的文檔上需要添加事務。Document-Oriented 數據庫并不支持文檔間的事務。

• 多個文檔之間需要復雜查詢，例如 join。

?

全文搜索引擎

---

傳統關系型數據庫主要通過索引來達到快速查詢的目的，在全文搜索的業務下，索引也無能為力，主要體現在：

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

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

而全文搜索引擎的出現，正是解決關系型數據庫全文搜索功能較弱的問題。

基本原理

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

現在有如下文檔集合：

正排索引得到索引如下：

由上可見，正排索引適用于根據文檔名稱查詢文檔內容。簡單的倒排索引如下：

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

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

常見全文搜索引擎

Elasticsearch：是一個基于 Lucene 的搜索引擎。它提供了一個分布式，多租戶，能夠全文搜索與生成 HTTP Web 界面和無架構 JSON 文件。

Elasticsearch 是用 Java 開發的，并根據 Apache License 的條款作為開源發布。

根據 DB-Engines 排名，Elasticsearch 是最受歡迎的企業搜索引擎，后面是基于 Lucene 的 Apache Solr。

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

相關特性

以 Elasticsearch 為例，全文搜索引擎優點如下：?

• 查詢效率高，對海量數據進行近實時的處理。

• 可擴展性，基于集群環境可以方便橫向擴展，可以承載 PB 級數據。

• 高可用，Elasticsearch 集群彈性，他們將發現新的或失敗的節點，重組和重新平衡數據，確保數據是安全的和可訪問的。

缺點如下：

• ACID 支持不足，單一文檔的數據是 ACID 的，包含多個文檔的事務時不支持事務的正常回滾，支持 I(Isolation)隔離性（基于樂觀鎖機制的），D(Durability)持久性，不支持 A(Atomicity)原子性，C(Consistency)一致性。

• 對類似數據庫中通過外鍵的復雜的多表關聯操作支持較弱。

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

• 更新性能較低，底層實現是先刪數據，再插入新數據。

• 內存占用大，因為 Lucene 將索引部分加載到內存中。

使用場景

適用場景如下：?

• 分布式的搜索引擎和數據分析引擎。

• 全文檢索，結構化檢索，數據分析。

• 對海量數據進行近實時的處理，可以將海量數據分散到多臺服務器上去存儲和檢索。

不適用場景如下：

• 數據需要頻繁更新。

• 需要復雜關聯查詢。

?

圖形數據庫

---

圖形數據庫應用圖形理論存儲實體之間的關系信息。最常見例子就是社會網絡中人與人之間的關系。

關系型數據庫用于存儲“關系型”數據的效果并不好，其查詢復雜、緩慢、超出預期。

而圖形數據庫的獨特設計恰恰彌補了這個缺陷，解決關系型數據庫存儲和處理復雜關系型數據功能較弱的問題。

常見圖形數據庫

Neo4j：是由 Neo4j，Inc. 開發的圖形數據庫管理系統。由其開發人員描述為具有原生圖存儲和處理的符合 ACID 的事務數據庫，根據 DB-Engines 排名，Neo4j 是最流行的圖形數據庫。

ArangoDB：是由 triAGENS GmbH 開發的原生多模型數據庫系統。數據庫系統支持三個重要的數據模型（鍵/值，文檔，圖形），其中包含一個數據庫核心和統一查詢語言 AQL（ArangoDB 查詢語言）。

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

Titan：是一個可擴展的圖形數據庫，針對存儲和查詢包含分布在多機群集中的數百億個頂點和邊緣的圖形進行了優化。

Titan 是一個事務性數據庫，可以支持數千個并發用戶實時執行復雜的圖形遍歷。

相關特性

以 Neo4j 為例，Neo4j 使用數據結構中圖（graph）的概念來進行建模。Neo4j 中兩個最基本的概念是節點和邊。

節點表示實體，邊則表示實體之間的關系。節點和邊都可以有自己的屬性。不同實體通過各種不同的關系關聯起來，形成復雜的對象圖。

針對關系數據，兩種數據庫的存儲結構不同：

Neo4j 中，存儲節點時使用了“index-free adjacency”，即每個節點都有指向其鄰居節點的指針，可以讓我們在 O(1) 的時間內找到鄰居節點。

另外，按照官方的說法，在 Neo4j 中邊是最重要的，即“first-class entities”，所以單獨存儲，這有利于在圖遍歷的時候提高速度，也可以很方便地以任何方向進行遍歷。

優點如下：

• 高性能表現，圖的遍歷是圖數據結構所具有的獨特算法，即從一個節點開始，根據其連接的關系，可以快速和方便地找出它的鄰近節點。

  這種查找數據的方法并不受數據量的大小所影響，因為鄰近查詢始終查找的是有限的局部數據，不會對整個數據庫進行搜索。

• 設計的靈活性，數據結構的自然伸展特性及其非結構化的數據格式，讓圖數據庫設計可以具有很大的伸縮性和靈活性。

  因為隨著需求的變化而增加的節點、關系及其屬性并不會影響到原來數據的正常使用。

• 開發的敏捷性，直觀明了的數據模型，從需求的討論開始，到程序開發和實現，以及最終保存在數據庫中的樣子，它的模樣似乎沒有什么變化，甚至可以說本來就是一模一樣的。

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

缺點如下：

• 具有支持節點，關系和屬性的數量的限制。

• 不支持拆分。

使用場景

適用場景如下：

• 在一些關系性強的數據中，例如社交網絡。

• 推薦引擎。如果我們將數據以圖的形式表現，那么將會非常有益于推薦的制定。

不適用場景如下：

• 記錄大量基于事件的數據（例如日志條目或傳感器數據）。

• 對大規模分布式數據進行處理，類似于 Hadoop。

• 適合于保存在關系型數據庫中的結構化數據。

• 二進制數據存儲。

?

總結

---

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

• 數據量

• 并發量

• 實時性

• 一致性要求

• 讀寫分布和類型

• 安全性

• 運維成本

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

• 內部使用的管理型系統，如運營系統，數據量少，并發量小，首選考慮關系型。

• 大流量系統，如電商單品頁，后臺考慮選關系型，前臺考慮選內存型。

• 日志型系統，原始數據考慮選列式，日志搜索考慮選倒排索引。

• 搜索型系統，例如站內搜索，非通用搜索，如商品搜索，后臺考慮選關系型，前臺考慮選倒排索引。

• 事務型系統，如庫存，交易，記賬，考慮選關系型+緩存+一致性型協議。

• 離線計算，如大量數據分析，考慮選列式或者關系型也可以。

• 實時計算，如實時監控，可以考慮選內存型或者列式數據庫。

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

?

參考資料：

• 從0開始學架構 —— Alibaba 李運華

• NoSQL漫談

• 圖形數據庫 Neo4j 開發實戰

• 大數據時代的 9 大Key-Value存儲數據庫

• 事務—— Redis官方文檔

• MongoDB是如何實現事務的ACID？

• MySQL臟讀、虛讀、幻讀

• 全面梳理關系型數據庫和 NoSQL 的使用情景

• 淺析列式數據庫的特點

• 一分鐘搞懂列式與行式數據庫

• HBase 基本概念

• NoSQL Databases, why we should use, and which one we should choose

• 傳統關系數據庫與分布式數據庫知識點

總結

以上是生活随笔為你收集整理的NoSQL还是SQL？这一篇讲清楚的全部內容，希望文章能夠幫你解決所遇到的問題。

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