歡迎光臨
每天分享高質量文章

NoSQL還是SQL?這一篇講清楚

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


傳統的關係型資料庫在應付這些已經顯得力不從心,並暴露了許多難以剋服的問題。


由此,各種各樣的 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 和 Hyperloglog。

  • 豐富的特性: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

  • 傳統關係資料庫與分佈式資料庫知識點


作者:陳彩華

編輯:陶家龍、孫淑娟


陳彩華(caison),主要從事服務端開發、需求分析、系統設計、優化重構工作,主要開發語言是 Java,現任廣州貝聊服務端研發工程師。微信號:hua1881375。


更多近期精華文章:



本文由 51CTO技術棧 授權轉載,歡迎投稿,詳情請戳公眾號選單「聯繫我們」。

高可用架構

改變互聯網的構建方式

長按二維碼 關註「高可用架構」公眾號

赞(0)

分享創造快樂