第七章-NoSQL数据库
第七章-NoSQL數據庫
文章目錄
- 第七章-NoSQL數據庫
- NoSQL簡介
- NoSQL VS. 關系數據庫
- NoSQL的四大類型
- 鍵值數據庫
- 列族數據庫
- 文檔數據庫
- 圖形數據庫
- 不同類型數據庫比較
- NoSQL的三大基石
- CAP
- BASE
- 最終一致性
- NewSQL數據庫
NoSQL簡介
傳統關系數據庫一度占據商業數據庫應用的主流位置
- 完備的關系理論基礎
- 事務管理機制的支持
- 高效的查詢優化機制
但是關系數據庫無法滿足 Web 2.0和大數據時代的需求
關系數據庫中的關鍵特性包括完善的事務機制和高效的查詢機制在Web 2.0時代沒有發揮
在這樣的新的應用背景下，關系數據庫實在難以滿足要求，于是 NoSQL 數據庫就應運而生了。
NoSQL（Not Only SQL）是對非關系型數據庫的統稱，采用的是類似鍵/值、列族、文檔等非關系模型。
NoSQL數據庫沒有固定的表結構，通常也不存在連接操作，也沒有嚴格遵守 ACID 約束。和關系型數據庫相比，NoSQL具有靈活的水平拓展性，可以支持海量數據的存儲。
NoSQL數據庫具有以下三個特點：
NoSQL VS. 關系數據庫
關系數據庫
- 優勢：以完善的關系代數理論作為基礎，有嚴格的標準，支持事務 ACID，借助索引機制可以實現高效的查詢，技術成熟，有專業公司的技術支持
- 劣勢：可擴展性較差，無法較好支持海量數據存儲，數據模型過于死板、無法較好支持Web2.0應用，事務機制影響了系統的整體性能等
NoSQL數據庫
- 優勢：可以支持超大規模數據存儲，靈活的數據模型可以很好地支持Web2.0應用，具有強大的橫向擴展能力等
- 劣勢：缺乏數學理論基礎，復雜查詢性能不高，大都不能實現事務強一致性，很難實現數據完整性，技術不夠成熟，缺乏專業團隊的 技術支持，維護較困難等
| 數據庫原理 | 完全支持 | 部分支持 | RDBMS有關系代數理論作為基礎 NoSQL沒有統一的理論基礎 |
| 數據規模 | 大 | 超大 | RDBMS很難實現橫向擴展，縱向擴展的空間也比較有限，性能會隨著數據規模的增大而降低 NoSQL可以很容易通過添加更多設備來支持更大規模的數據 |
| 數據庫模式 | 固定 | 靈活 | RDBMS需要定義數據庫模式，嚴格遵守數據定義和 相關約束條件 NoSQL不存在數據庫模式，可以自由靈活定義并存 儲各種不同類型的數據 |
| 查詢效率 | 快 | 可以實現高效的簡單查詢，但是不具備高度結構化查詢等特性，復雜查詢的性能不盡人意 | RDBMS借助于索引機制可以實現快速查詢（包括記 錄查詢和范圍查詢） 很多NoSQL數據庫沒有面向復雜查詢的索引 |
| 一致性 | 強一致性 | 弱一致性 | RDBMS嚴格遵守事務ACID模型，可以保證事務強一致性 很多NoSQL數據庫放松了對事務ACID四性的要求， 而是遵守BASE模型，只能保證最終一致性 |
| 數據完整性 | 容易實現 | 很難實現 | 任何一個RDBMS都可以很容易實現數據完整性，比如通過主鍵或者非空約束來實現實體完整性，通過主鍵、外鍵來實現參照完整性，通過約束或者觸發器來實現用戶自定義完整性 但是，在NoSQL數據庫卻無法實現 |
| 擴展性 | 一般 | 好 | RDBMS很難實現橫向擴展，縱向擴展的空間也比較有限 NoSQL在設計之初就充分考慮了橫向擴展的需求， 可以很容易通過添加廉價設備實現擴展 |
| 可用性 | 好 | 很好 | RDBMS在任何時候都以保證數據一致性為優先目標，其次才是優化系統性能，隨著數據規模的增大，RDBMS為了保證嚴格的一致性，只能提供相對較弱的可用性 大多數NoSQL都能提供較高的可用性 |
| 標準化 | 是 | 否 | RDBMS已經標準化（SQL） NoSQL還沒有行業標準，不同的NoSQL數據庫都有自己的查詢語言，很難規范應用程序接口 |
| 技術支持 | 高 | 低 | RDBMS經過幾十年的發展，已經非常成熟，Oracle 等大型廠商都可以提供很好的技術支持 NoSQL在技術支持方面還不成熟，缺乏有力的技術支持 |
| 可維護性 | 復雜 | 復雜 | RDBMS需要專門的數據庫管理員(DBA)維護 NoSQL數據庫雖然沒有DBMS復雜，也難以維護 |
關系數據庫和NoSQL數據庫各有優缺點，彼此無法取代
- 關系數據庫應用場景：電信、銀行等領域的關鍵業務系 統，需要保證強事務一致性
- NoSQL數據庫應用場景：互聯網企業、傳統企業的非關 鍵業務（比如數據分析）
有時候也會采用混合架構，比如使用不同類型的數據庫來支撐電子商務應用。
- 對于“購物車”這種臨時性數據，采用鍵值存儲會更加高效
- 當前的產品和訂單信息則適合存放在關系數據庫中
- 大量的歷史訂單信息則適合保存在類似 MongoDB 的文檔數據庫中
NoSQL的四大類型
典型的NoSQL數據庫通常包括：
- 鍵值數據庫
- 列族數據庫
- 文檔數據庫
- 圖形數據庫
鍵值數據庫
鍵值數據庫（Key-Value Database）會使用一個哈希表，這個表中有一個特定的 Key 和一個指針指向特定的 Value。Key可以用來定位 Value，即存儲和檢索具體的 Value。
Value可以用來存儲任意類型的數據，包括整形、字符型、數組、對象等。但是，Value 對數據庫而言是透明不可見的，不能對 Value 進行索引和存儲，只能通過 Key 進行查詢。
鍵值數據庫可以進一步劃分為內存鍵值數據庫和持久化鍵值數據庫。
- 內存鍵值數據庫把數據保存在內存，如 Memcached、Redis
- 持久化鍵值數據庫把數據保存在磁盤，如 BerkeleyDb、Riak
鍵值數據庫有自身的局限，條件查詢就是鍵值數據庫的弱項。因此，在使用鍵值數據庫時，應該盡量避免多表關聯查詢，可以采用雙向冗余存儲關系來替代表關聯，把操作分解為單表操作。
| 相關產品 | Redis、Riak、SimpleDB、Chordless、Memcached |
| 數據模型 | 鍵/值對 鍵是一個字符串對象 值可以是任意類型的數據，比如整型、字符型、數組、列表、集合等 |
| 典型應用 | 擁有簡單數據模型的應用，涉及頻繁讀寫 內容緩存，比如會話、配置文件、參數、購物車等 |
| 優點 | 擴展性好，靈活性好，大量寫操作時性能高 |
| 缺點 | 無法存儲結構化信息，條件查詢效率較低 |
| 不適用情景 | 不是通過鍵而是通過值來查：鍵值數據庫沒有通過值查詢的途徑 需要存儲數據之間的關系：在鍵值數據庫中，不能通過兩個或兩個以上的鍵來關聯數據 需要事務的支持：在一些鍵值數據庫中，產生故障時，不可以回滾 |
| 使用者 | 百度云數據庫（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Redis和 Memcached）、StackOverFlow（Redis）、Instagram （Redis）、Youtube （Memcached）、Wikipedia（Memcached） |
目前使用最多的是 Redis，被稱為“強化版的Memcached”，被廣泛應用在數據緩存方面
- 支持持久化
- 數據恢復
- 更多數據類型
列族數據庫
列族數據庫一般采用列族數據模型，數據庫由多個行組成，每行數據包含多個列族，不同的行可以具有不同數量的列族，屬于同一列族的數據會被存放在一起。
| 相關產品 | BigTable、HBase、Cassandra、Hypertable、GreenPlum等 |
| 數據模型 | 列族 |
| 典型應用 | 分布式數據存儲與管理 數據在地理上分布于多個數據中心的應用程序 可以容忍副本中存在短期不一致情況的應用程序 擁有動態字段的應用程序 擁有潛在大量數據的應用程序，大到幾百TB的數據 |
| 優點 | 查找速度快，可擴展性強，容易進行分布式擴展，復雜性低 |
| 缺點 | 功能較少，大都不支持強事務一致性 |
| 不適用情景 | 需要ACID事務支持的情形，Cassandra等產品就不適用 |
| 使用者 | Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、 Twitter（Cassandra and HBase）、Facebook（Cassandra）、Yahoo! （HBase） |
文檔數據庫
在文檔數據庫中，文檔是數據庫的最小單位。文檔是一個數據記錄，這個記錄能夠對包含的數據類型和內容進行“自我描述。文檔數據庫旨在將半結構化數據存儲為文檔，通常用XML、 JSON 等文檔格式來封裝和編碼數據。
一個文檔可以包含非常復雜的數據結構，如嵌套對象，且每個文檔可以有完全不同的數據結構，每一條記錄包含了所有的有關信息而沒有任何外部的引用，這條記錄就是“自包含”的，這使得記錄很容易完成數據遷移。
文檔數據庫既可以根據鍵（Key）來構建索引，也可以根據文檔內容構建索引。尤其是基于文檔內容的索引和查詢這種能力，是文檔數據庫不同于鍵值數據庫的地方。
| 相關產品 | MongoDB、CouchDB、Terrastore、MarkLogic、RavenDB |
| 數據模型 | 鍵/值 值（value）是版本化的文檔 |
| 典型應用 | 存儲、索引并管理面向文檔的數據或者類似的半結構化數據 比如，用于后臺具有大量讀寫操作的網站、使用JSON數據結構的應用、 使用嵌套結構等非規范化數據的應用程序 |
| 優點 | 性能好（高并發），復雜性低，數據結構靈活 提供嵌入式文檔功能，將經常查詢的數據存儲在同一個文檔中 既可以根據鍵來構建索引，也可以根據內容構建索引 |
| 缺點 | 缺乏統一的查詢語法 |
| 不適用情景 | 在不同的文檔上添加事務。文檔數據庫并不支持文檔間的事務，如果對 這方面有需求則不應該選用這個解決方案 |
| 使用者 | 百度云數據庫（MongoDB）、SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB） |
圖形數據庫
圖數據庫使用圖作為數據模型來存儲數據，完全不同于鍵值、文檔和列族數據模型，可以高效地存儲不同頂點之間的關系。圖數據庫專門用來處理具有高度相互關聯關系的數據，可以高效地處理實體之間的關系，比較適合于社交網絡、模式識別、依賴分析、推薦系統以及路徑尋找等問題。
但是，除了在處理圖和關系這些應用領域具有很好的性能之外，在別的領域，圖數據庫的性能不如其他 NoSQL 數據庫。
| 相關產品 | Neo4J、Infinite Graph、GraphDB |
| 數據模型 | 圖結構 |
| 典型應用 | 應用于大量復雜、互連接、低結構化的圖結構場合，如社交網絡、推薦系統等 |
| 優點 | 靈活性高，支持復雜的圖形算法，可用于構建復雜的關系圖譜 |
| 缺點 | 復雜性高，只能支持一定的數據規模 |
| 使用者 | Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J） |
不同類型數據庫比較
MySQL
- 功能較穩定強大，滿足多樣需求
MongoDB
- 數據模型較靈活，支持較多功能
HBase
- 具有很好的擴展性，依賴 Hadoop 生態環境
Redis
- 模型較為簡單，可提供隨機數據存儲，數據庫伸縮性較好
NoSQL的三大基石
NoSQL的三大基石包括 CAP、BASE 和最終一致性。
CAP
CAP理論指的是：
- C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，也就是在分布式環境中，多點的數據是一致的，或者說，所有節點在同一時間具有相同的數據
- A:（Availability）：可用性，是指快速獲取數據，可以在確定的時間內返回操作結果，保證每個請求不管成功或者失敗都有響應
- P（Tolerance of Network Partition）：分區容忍性，是指當出現網絡分區的情況時（即系統中的一部分節點無法和其他節點進行通信），分離的系統也能夠正常運行， 也就是說，系統中任意信息的丟失或失敗不會影響系統的繼續運作
CAP理論告訴我們，一個分布式系統不可能同時滿足一致性、可用性和分區容忍性這三個需求，最多只能同時滿足其中兩個。
處理CAP的問題時的選擇：
- CA：強調一致性（C）和可用性（A），放棄分區容忍性（P），最簡單的做法是把所有與事務相關的內容都放到同一臺機器上。很顯然，這種做法會嚴重影響系統的可擴展性
- CP：強調一致性（C）和分區容忍性（P），放棄可用性（A），當出現網絡分區的情況時，受影響的服務需要等待數據一致，因此在等待期間就無法對外提供服務
- AP：強調可用性（A）和分區容忍性（P），放棄一致性（C），允許系統返回不一致的數據
BASE
數據庫事務的 ACID 特性
- A（Atomicity）：原子性，是指事務必須是原子工作單元，對于其數據修改，要么全都執行，要么全都不執行
- C（Consistency）：一致性，是指事務在完成時，必須使所有的數據都保持一致狀態
- I（Isolation）：隔離性，是指由并發事務所做的修改必須與任何其它并發事務所做的修改隔離
- D（Durability）：持久性，是指事務完成之后，它對于系統的影響是永久性的，該修改即使出現致命的系統故 障也將一直保持
關系數據庫系統設計了復雜的事務管理機制來保證事務在執行過程中嚴格滿足 ACID 的要求，較好地滿足了銀行等領域對數據一致性的要求，因此得到了廣泛的商業應用。
但是，NoSQL 數據庫通常應用與 Web 2.0網站等應用場景中，對數據一致性要求并不是很高，而是強調系統的高可用性。因此為了獲得高可用性，可以考慮適當犧牲一致性或分區容忍性。BASE的基本思想就是在這個基礎上發展起來的，是完全不同于 ACID 模型的，BASE 犧牲了高一致性，從而獲得了可用性或可靠性。
BASE 的基本含義是 基本可用、軟狀態 和 最終一致性。
- 基本可用（Basically Available）：是指一個分布式系統的一部分發生問題變得不可用時，其他部分仍然可以正常使用，也就是允許分區失敗的情形出現
- 軟狀態（Soft-state）：是與“硬狀態（hardstate）”相對應的一種提法。數據庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。“軟狀態”是指狀態可以有一段時間不同步，具有一定的滯后性
- 最終一致性（Eventual consistency）：一致性的類型包括強一致性和弱一致性，二者的主要區別在于高并發的數據訪問操作下，后續操作是否能夠獲取最新的數據。
- 對于強一致性而言，當執行完一次更新操作后，后續的其他讀操作就可以保證讀到更新后的最新數據。關系數據庫通常實現強一致性
- 反之，如果不能保證后續訪問讀到的都是更新后的最新數據，那么就是弱一致性。而最終一致性只不過是弱一致性的一種特例，允許后續的訪問操作可以暫時讀不到更新后的數據，但是經過一段時間之后，必須最終讀到更新后的數據
最終一致性
最終一致性根據更新數據后各進程訪問到數據的時間和方式的不同，又可以區分為：
-
因果一致性 (Causal consistency）：如果進程A通知進 程B它已更新了一個數據項，那么進程B的后續訪問將獲 得A寫入的最新值。而與進程A無因果關系的進程C的訪 問，仍然遵守一般的最終一致性規則
-
“讀己之所寫”一致性 (Read your writes）：可以視為 因果一致性的一個特例。當進程A自己執行一個更新操 作之后，它自己總是可以訪問到更新過的值，絕不會看 到舊值
-
會話一致性 (Session consistency）：系統能保證在同 一個有效的會話中實現 “讀己之所寫” 的一致性，也 就是說，執行更新操作之后，客戶端能夠在同一個會話 中始終讀取到該數據項的最新值
-
單調讀一致性：如果進程已經看到過數據對象的某個值， 那么任何后續訪問都不會返回在那個值之前的值
-
單調寫一致性：系統保證來自同一個進程的寫操作順序 執行，對于多副本系統來說，保證寫順序的一致性（串 行化），是很重要的
在分布式數據系統中，將數據冗余的份數記為N，更新數據時需要保證寫完成的節點數記為W，讀取數據時需要讀取的節點數記為R。
- 如果W+R>N，寫的節點和讀的節點重疊，則是強一致性。例如對于典型的一主一備同步復制的關系型數據庫， N=2,W=2,R=1，則不管讀的是主庫還是備庫的數據，都 是一致的。一般設定是R＋W = N+1，這是保證強一致性的最小設定
- 如果W+R<=N，則是弱一致性。例如對于一主一備異步 復制的關系型數據庫，N=2,W=1,R=1，則如果讀的是備 庫，就可能無法讀取主庫已經更新過的數據，所以是弱一致性。
對于分布式系統，為了保證高可用性，一般設置N>=3。不同的N,W,R 組合，是在可用性和一致性之間取一個平衡，以適應不同的應用場景。
如果N=W,R=1，任何一個寫節點失效，都會導致寫失敗，因此可用性會降低，但是由于數據分布的N個節點是同步寫入的，因此可以保證強一致性
HBase是借助其底層的HDFS來實現其數據冗余備份的。HDFS采用的就是強一致性保證。在數據沒有完全同步到N個節點前，寫操作不會返 回成功。也就是說它的 W＝N，而讀操作只需要讀到一個值即可，也就是說它的 R＝1
而 Cassandra 等系統，通常都允許用戶按需要設置N，R，W三個值， 即可設置成W＋R<= N，也就是說允許用戶在強一致性和最終一致性之 間自由選擇。而在用戶選擇了最終一致性，或者是W<N的強一致性時，則總會出現一段“各個節點數據不同步導致系統處理不一致的時間”。為了提供最終一致性的支持，這些系統會提供一些工具來使數據更新被最終同步到所有相關節點
NewSQL數據庫
盡管 NoSQL 數據庫較好地滿足了 Web 2.0應用的需求，但是 NoSQL 不具備高度結構化查詢等特性，復雜查詢的效率不如關系數據庫，而且不支持事務ACID。
在這樣的背景下，NewSQL 數據庫開始升溫。NewSQL 是對各種新的可擴展/高性能數據庫的簡稱，這類數據庫不僅具有NoSQL對海量數據的存儲管理能力， 還保持了傳統數據庫支持ACID和SQL等特性。
在大數據時代，數據庫架構開始向著多元化方向發展，并形成了傳統關系數據庫（OldSQL）、NoSQL 和 NewSQL 數據庫三個陣營，三者各有自己的應用場景和發展空間。在未來的一段時間內，三個陣營共存共榮的局面還將持續。
總結
以上是生活随笔為你收集整理的第七章-NoSQL数据库的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 第六章-Hadoop优化与发展
- 下一篇： Redis的简单实践