NoSQL 還是 SQL ？這一篇講清楚

貝聊科技發表於2018-08-10

文章首發於51CTO技術棧公眾號
作者 陳彩華
文章轉載交流請聯絡 caison@aliyun.com
複製程式碼

隨著大資料時代的到來，越來越多的網站、應用系統需要支撐海量資料儲存，高併發請求、高可用、高可擴充套件性等特性要求，傳統的關係型資料庫在應付這些調整已經顯得力不從心，暴露了許多能以克服的問題。由此，各種各樣的NoSQL（Not Only SQL）資料庫作為傳統關係型資料的一個有力補充得到迅猛發展。

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

1 傳統資料庫缺點

大資料場景下I/O較高因為資料是按行儲存，即使只針對其中某一列進行運算，關係型資料庫也會將整行資料從儲存裝置中讀入記憶體，導致I/O較高
儲存的是行記錄，無法儲存資料結構
表結構schema擴充套件不方便如要需要修改表結構，需要執行執行DDL(data definition language)，語句修改，修改期間會導致鎖表，部分服務不可用
全文搜尋功能較弱關係型資料庫下只能夠進行子字串的匹配查詢，當表的資料逐漸變大的時候，like查詢的匹配會非常慢，即使在有索引的情況下。況且關係型資料庫也不應該對文字欄位進行索引
儲存和處理複雜關係型資料功能較弱許多應用程式需要了解和導航高度連線資料之間的關係，才能啟用社交應用程式、推薦引擎、欺詐檢測、知識圖譜、生命科學和 IT/網路等用例。然而傳統的關聯式資料庫並不善於處理資料點之間的關係。它們的表格資料模型和嚴格的模式使它們很難新增新的或不同種類的關聯資訊。

2 NoSQL解決方案

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

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

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

下面介紹5大類NoSQL資料針對傳統關係型資料庫的缺點提供的解決方案：

2.1 列式資料庫

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

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

2.1.1 基本原理

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

將表放入儲存系統中有兩種方法，而我們絕大部分是採用行儲存的。行儲存法是將各行放入連續的物理位置，這很像傳統的記錄和檔案系統。列儲存法是將資料按照列儲存到資料庫中，與行儲存類似，下圖是兩種儲存方法的圖形化解釋：

2.1.2 常見列式資料庫

HBase

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

BigTable

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

2.1.3 相關特性

優點如下：

高效的儲存空間利用率**

列式資料庫由於其針對不同列的資料特徵而發明的不同演算法使其往往有比行式資料庫高的多的壓縮率，普通的行式資料庫一般壓縮率在3：1 到5：1 左右，而列式資料庫的壓縮率一般在8：1到30：1 左右。比較常見的，通過字典表壓縮資料：下面中才是那張表本來的樣子。經過字典表進行資料壓縮後，表中的字串才都變成數字了。正因為每個字串在字典表裡只出現一次了，所以達到了壓縮的目的(有點像規範化和非規範化Normalize和Denomalize)

查詢效率高

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

執行步驟如下：
i. 去字典表裡找到字串對應數字(只進行一次字串比較)。
ii. 用數字去列表裡匹配，匹配上的位置設為1。
iii. 把不同列的匹配結果進行位運算得到符合所有條件的記錄下標。
iv. 使用這個下標組裝出最終的結果集。
複製程式碼

適合做聚合操作
適合大量的資料而不是小資料

缺點如下：

不適合掃描小量資料
不適合隨機的更新
不適合做含有刪除和更新的實時操作
單行的資料是ACID的，多行的事務時，不支援事務的正常回滾，支援 I(Isolation)隔離性(事務序列提交)，D(Durability)永續性，不能保證 A(Atomicity)原子性， C(Consistency)一致性

2.1.4 使用場景

以HBase為例說明：

大資料量（100s TB級資料）且有快速隨機訪問的需求
寫密集型應用，每天寫入量巨大，而相對讀數量較小的應用比如IM的歷史訊息，遊戲的日誌等等
不需要複雜查詢條件來查詢資料的應用 HBase只支援基於rowkey的查詢，對於HBase來說，單條記錄或者小範圍的查詢是可以接受的，大範圍的查詢由於分散式的原因，可能在效能上有點影響，HBase不適用與有join，多級索引，表關係複雜的資料模型
對效能和可靠性要求非常高的應用由於HBase本身沒有單點故障，可用性非常高。
資料量較大，而且增長量無法預估的應用，需要進行優雅的資料擴充套件的 HBase支援線上擴充套件，即使在一段時間內資料量呈井噴式增長，也可以通過HBase橫向擴充套件來滿足功能。
儲存結構化和半結構化的資料

2.2 K-V資料庫

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

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

2.2.1 常見 K-V資料庫

Redis

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, Comcast,Instagram, Spotify, eBay, Rackspace, Netflix等知名網站所採用，成為了一種流行的分散式結構化資料儲存方案。

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

2.2.2 相關特性

以Redis為例：優點如下：

效能極高：Redis能支援超過10W的TPS
豐富的資料型別： Redis支援包括String，Hash，List，Set，Sorted Set，Bitmap和hyperloglog
豐富的特性：Redis還支援 publish/subscribe, 通知, key 過期等等特性

缺點如下：針對ACID，Redis事務不能支援原子性和永續性(A和D)，只支援隔離性和一致性(I和C) 特別說明一下，這裡所說的無法保證原子性，是針對Redis的事務操作，因為事務是不支援回滾（roll back），而因為Redis的單執行緒模型，Redis的普通操作是原子性的

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

2.2.3 使用場景

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

不適用場景
- 需要通過值來查詢，而不是鍵來查詢。Key-Value資料庫中根本沒有通過值查詢的途徑。
- 需要儲存資料之間的關係。在Key-Value資料庫中不能通過兩個或以上的鍵來關聯資料
- 需要事務的支援。在Key-Value資料庫中故障產生時不可以進行回滾。

2.3 文件資料庫

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

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

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

2.3.1 常見文件資料庫

MongoDB

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

CouchDB

Apache CouchDB是一個開源資料庫，專注於易用性和成為"完全擁抱web的資料庫"。它是一個使用JSON作為儲存格式，JavaScript作為查詢語言，MapReduce和HTTP作為API的NoSQL資料庫。其中一個顯著的功能就是多主複製。CouchDB的第一個版本釋出在2005年，在2008年成為了Apache的專案。

2.3.2 相關特性

以MongoDB為例進行說明

優點如下：

新增欄位簡單無需像關係型資料庫一樣先執行DDL語句修改表結構，程式程式碼直接讀寫即可
容易相容歷史資料對於歷史資料，即使沒有新增的欄位，也不會導致錯誤，只會返回空值，此時程式碼相容處理即可
容易儲存複雜資料 JSON是一種強大的描述語言，能夠描述複雜的資料結構

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

Atomicity(原子性) 僅支援單行/文件級原子性，不支援多行、多文件、多語句原子性
Isolation(隔離性) 隔離級別僅支援已提交讀（Read committed）級別，可能導致不可重複讀，幻讀的問題
不支援複雜查詢例如join查詢，如果需要join查詢，需要多次運算元據庫

MongonDB還是支援多文件事務的Consistency(一致性)和Durability(永續性)

雖然官方宣佈MongoDB將在4.0版本中正式推出多文件ACID事務支援，最後落地情況還有待見證。

2.3.3 使用場景

適用場景：

資料量很大或者未來會變得很大
表結構不明確，且欄位在不斷增加，例如內容管理系統，資訊管理系統

不適用場景：

在不同的文件上需要新增事務。Document-Oriented資料庫並不支援文件間的事務
多個文件直接需要複雜查詢，例如join

2.4 全文搜尋引擎

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

全文搜尋的條件可以隨意排列組合，如果通過索引來滿足，則索引的數量非常多
全文搜尋的模糊匹配方式，索引無法滿足，只能用like查詢，而like查詢是整表掃描，效率非常低

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

2.4.1 基本原理

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

現在有如下文件集合：

正排索引得到索引如下：

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

簡單的倒排索引如下：

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

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

2.4.2 常見全文搜尋引擎

Elasticsearch
Elasticsearch是一個基於Lucene的搜尋引擎。它提供了一個分散式，多租戶 -能夠全文搜尋與發動機HTTP Web介面和無架構JSON檔案。Elasticsearch是用Java開發的，並根據Apache License的條款作為開源釋出。根據DB-Engines排名，Elasticsearch是最受歡迎的企業搜尋引擎，後面是基於Lucene的Apache Solr。
Solr
Solr是Apache Lucene專案的開源企業搜尋平臺。其主要功能包括全文檢索、命中標示、分面搜尋、動態聚類、資料庫整合，以及富文字（如Word、PDF）的處理。Solr是高度可擴充套件的，並提供了分散式搜尋和索引複製

2.4.3 相關特性

以Elasticsearch為例：優點如下：

查詢效率高對海量資料進行近實時的處理
可擴充套件性基於叢集環境可以方便橫向擴充套件，可以承載PB級資料
高可用 Elasticsearch叢集彈性-他們將發現新的或失敗的節點，重組和重新平衡資料，確保資料是安全的和可訪問的

缺點如下：

ACID支援不足單一文件的資料是ACID的，包含多個文件的事務時不支援事務的正常回滾，支援 I(Isolation)隔離性（基於樂觀鎖機制的），D(Durability)永續性，不支援 A(Atomicity)原子性，C(Consistency)一致性
對類似資料庫中通過外來鍵的複雜的多表關聯操作支援較弱
讀寫有一定延時，寫入的資料，最快1s中能被檢索到
更新效能較低，底層實現是先刪資料，再插入新資料
記憶體佔用大，因為Lucene 將索引部分載入到記憶體中

2.4.4 使用場景

適用場景如下：

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

不適用場景如下：

資料需要頻繁更新
需要複雜關聯查詢

2.5 圖形資料庫

圖形資料庫應用圖形理論儲存實體之間的關係資訊。最常見例子就是社會網路中人與人之間的關係。關係型資料庫用於儲存“關係型”資料的效果並不好，其查詢複雜、緩慢、超出預期，而圖形資料庫的獨特設計恰恰彌補了這個缺陷，解決關係型資料庫儲存和處理複雜關係型資料功能較弱的問題。

2.5.1 常見圖形資料庫

Neo4j

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

ArangoDB

ArangoDB是由triAGENS GmbH開發的原生多模型資料庫系統。資料庫系統支援三個重要的資料模型（鍵/值，文件，圖形），其中包含一個資料庫核心和統一查詢語言AQL（ArangoDB查詢語言）。查詢語言是宣告性的，允許在單個查詢中組合不同的資料訪問模式。ArangoDB是一個NoSQL資料庫系統，但AQL在很多方面與SQL類似。

Titan

Titan是一個可擴充套件的圖形資料庫，針對儲存和查詢包含分佈在多機群集中的數百億個頂點和邊緣的圖形進行了優化。Titan是一個事務性資料庫，可以支援數千個併發使用者實時執行復雜的圖形遍歷。

2.5.2 相關特性

以Neo4j為例：

Neo4j 使用資料結構中圖（graph）的概念來進行建模。 Neo4j 中兩個最基本的概念是節點和邊。節點表示實體，邊則表示實體之間的關係。節點和邊都可以有自己的屬性。不同實體通過各種不同的關係關聯起來，形成複雜的物件圖。

針對關係資料，2種2資料庫的儲存結構不同：

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

如下優點：

高效能表現圖的遍歷是圖資料結構所具有的獨特演算法，即從一個節點開始，根據其連線的關係，可以快速和方便地找出它的鄰近節點。這種查詢資料的方法並不受資料量的大小所影響，因為鄰近查詢始終查詢的是有限的區域性資料，不會對整個資料庫進行搜尋
設計的靈活性資料結構的自然伸展特性及其非結構化的資料格式，讓圖資料庫設計可以具有很大的伸縮性和靈活性。因為隨著需求的變化而增加的節點、關係及其屬性並不會影響到原來資料的正常使用
開發的敏捷性直觀明瞭的資料模型，從需求的討論開始，到程式開發和實現，以及最終儲存在資料庫中的樣子，它的模樣似乎沒有什麼變化，甚至可以說本來就是一模一樣的
完全支援ACID 不像別的NoSQL資料庫Neo4j還具有完全事務管理特性，完全支援ACID事務管理

缺點如下：