https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653550127&idx=1&sn=93f79e007d757a2ba887e8dc9e6c47f6&chksm=813a67b7b64deea1093304b21065d76073f0eb6e4b2923181211d0cb4159e1dc8c3104f7436b&scene=0&key=f9325dcb38245ddc7742d7cded4d414f3281d7d65fa874e0f7fc88b5427449e479341ba5713746a72604354fc9dee61561ea327a1ef14a3e92076444b3223ba4f3c0af86cfdc217e49ff5008dfbb9cee&ascene=1&uin=MjgwMTEwNDQxNg%3D%3D&devicetype=Windows-QQBrowser&version=6103000b&lang=zh_CN&pass_ticket=DXC1954%2BK1SGTbNf0BfROhv9qHwlnnEPi%2BhWkN5VYUoPmHizjz4O33VIful%2FVDWv算法
傳統的關係型數據庫在應付這些已經顯得力不從心,並暴露了許多難以克服的問題。數據庫
由此,各類各樣的 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 數據庫存儲擁有更好的讀寫性能,可以解決關係型數據庫沒法存儲數據結構的問題。
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
傳統關係數據庫與分佈式數據庫知識點
做者:陳彩華
編輯:陶家龍、孫淑娟