Java開發大型互聯網NoSQL數據庫-數據模型之CAP原理淺析

引言

NoSQL，泛指非關係型的數據庫。隨著互聯網web2.0網站的興起，傳統的關係數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的數據庫則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題。

雖然NoSQL的流行與火起來才短短一年的時間，但是不可否認，現在已經開始了第二代運動。儘管早期的堆棧代碼只能算是一種實驗，然而現在的系統已經更加的成熟、穩定。不過現在也面臨著一個嚴酷的事實：技術越來越成熟——以至於原來很好的NoSQL數據存儲不得不進行重寫，也有少數人認為這就是所謂的2.0版本。該工具可以為大數據建立快速、可擴展的存儲庫。

NoSQL簡介

NOSQL歷史

NoSQL一詞最早出現於1998年，是Carlo Strozzi開發的一個輕量、開源、不提供SQL功能的關係數據庫。

2009年，Last.fm的Johan Oskarsson發起了一次關於分佈式開源數據庫的討論，來自Rackspace的Eric Evans再次提出了NoSQL的概念，這時的NoSQL主要指非關係型、分佈式、不提供ACID的數據庫設計模式。

2009年在亞特蘭大舉行的"no:sql(east)"討論會是一個里程碑，其口號是"select fun, profit from real_world where relational=false;"。因此，對NoSQL最普遍的解釋是"非關聯型的"，強調Key-Value Stores和文檔數據庫的優點，而不是單純的反對RDBMS。

NoSQL 泛指非關係型數據庫，NoSQL數據庫的四大分類：

鍵值存儲數據庫

這一類數據庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。如Redis，Voldmort，Oracle BDB

列存儲數據庫

這部分數據庫通常是用來應對分佈式存儲的海量數據。鍵仍然存在，但是它們的特定是指向了多個列。如HBase，Riak

文檔型數據庫

該類型的數據模型是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型數據庫可以看作是鍵值數據庫的升級版，允許之間嵌套鍵值。而且文檔型數據庫比鍵值數據庫的查詢效率更高。如： CouchDB、MongoDB

圖形〔Graph〕 數據庫

圖形結構的數據庫同其他行列以及剛性結構的SQL數據庫不同，它是使用靈活的圖形模型，並且能夠擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言[SQL]，因此進行數據庫查詢需要制定數據模型。許多NoSQL數據庫都有REST式的數據藉口或者查詢API，如Neo4J、InfoGrid、Infinite Graph

NOSQL概念

剛剛出現NOSQL這個概念的時候，很多人都是似而非的字面理解成"不是SQL"， 與傳統的關係型數據庫是兩個完全獨立的陣營，實際上完全不是這麼回事。個人更傾向於理解NOSQL的誕生更多的是為了補充關係型數據庫的短板，滿足現下互聯網海量數據、高併發、低延遲和非結構化數據易擴展等需求。

NoSQL = Not Only SQL，意即“不僅僅是SQL”，是對不同於傳統的關係型數據庫的數據庫管理系統的統稱。與關係型數據庫相比，它們在架構和數據模型方面做了“減法”，而在擴展和併發等方面做了“加法”。

為何要使用NoSQL

NoSQL具有靈活的數據模型，可以處理非結構化/半結構化的大數據

NoSQL很容易實現可伸縮性（向上擴展與水平擴展）

NoSQL在不太影響性能的情況，就可以方便的實現高可用的架構

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。

數據模型

傳統的數據庫在數據模型方面，主要是關係型，它的特色是對Join類操作和ACID事務的支持。在NoSQL領域，主要有三種主流的數據模型：

Column-oriented(列式)

列式也主要使用Table這樣的模型，但是它並不支持類似Join這樣多表的操作，它的主要特點是在存儲數據時，主要圍繞著“列(Column)”，而不是像傳統的關係型數據庫那樣根據“行(Row)”進行存儲，也就是說，屬於同一列的數據會盡可能地存儲在硬盤同一個頁(Page)中，而不是將屬於同一個行的數據存放在一起，這樣做的好處是，對於很多類似數據倉庫(Data Warehouse)的應用，雖然每次查詢都會處理很多數據，但是每次所涉及的列並沒有很多，這樣如果使用列式數據庫的話，將會節省大量I/O，並且大多數列式數據庫都支持Column Family這個特性，通過這個特性能將多個Column併為一個小組，這樣做好處是能將相似Column放在一起存儲，這樣能提高這些Column的存儲和查詢效率。總體而言，這種數據模型的優點是比較適合彙總(Aggregation)和數據倉庫這類應用。.

Key-value

雖然Key-value這種模型和傳統的關係型相比較簡單，有點類似常見的HashTable，一個Key對應一個Value，但是其能提供非常快的查詢速度、大的數據存放量和高併發操作，並非常適合通過主鍵對數據進行查詢和修改等操作，雖然不支持複雜的操作，但是可以通過上層的開發來彌補這個缺陷。

Document(文檔)

在結構上，Document和Key-value是非常相似的，也是一個Key對應一個Value，但是這個Value主要以JSON或者XML等格式的文檔來進行存儲，是有語義的，並且Document DB一般可以對Value來創建Secondary Index來方便上層的應用，而這點是普通Key-Value DB所無法支持的。

CAP理論

這個理論是由美國著名科學家，同時也是著名互聯網企業Inktomi的創始人Eric Brewer在2000年PODC(Symposium on Principles of Distributed Computing)大會上提出的，後來Seth Gilbert 和 Nancy lynch兩人也證明了CAP理論的正確性，雖然在後來近十年的時間很多人對CAP理論提出了很多異議，但是在NoSQL的世界中，它還是非常有參考價值的。它的意思是，一個分佈式系統不能同時滿足一致性，可用性和分區容錯性這三個需求，最多隻能同時滿足兩個。

1. 一致性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結果，也就是在分佈式環境中，多點的數據是一致的;

2. 可用性(Availability)：每一個操作總是能夠在確定的時間內返回，也就是系統隨時都是可用的。

3. 分區容忍性(Partition Tolerance)： 在出現網絡分區(比如斷網)的情況下，分離的系統也能正常運行。

由於一致性、可用性和分區容忍性這三方面只能選擇兩個，所以大多數NoSQL系統都會根據自己的設計理念來進行相應的選擇，但由於許多NoSQL數據庫都以水平擴展著稱，所以在CAP的選擇上面，都傾向於堅持分區容忍性，而放棄一致性或者可用性，它們的做法主要是通過消減關係型和事務相關的功能。

總結

以 上就是我對Java開發大型互聯網NoSQL數據庫-數據模型之CAP原理淺析問題及其優化總結，分享給大家，希望大家知道什麼是Java開發大型互聯網NoSQL數據庫-數據模型之CAP原理淺析問題及其優化。覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持！

• 1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的

• 2、可以去百度搜索騰訊課堂圖靈學院的視頻來學習一下java架構實戰案例，還挺不錯的。

• 最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步！都能贏取白富美，走向架構師的人生巔峰!

• 3丶想了解學習以上課程內容可加群：469717771 驗證碼頭條（06 必過）歡迎大家的加入喲！