NoSql的三大基石：CAP理論&BASE&最終一致性

時間 2019-11-29

標籤 nosql 三大基石 cap 理論 base 最終一致性欄目 NoSQL 简体版

原文原文鏈接

關係型數據庫的侷限
html

NoSql出如今關係型數據庫以後，主要是爲了解決關係型數據庫的短板，咱們先來看看隨着軟件行業的發展，關係型數據庫面臨了哪些挑戰：數據庫

一、高併發json

一個最典型的就是電商網站，例如雙11，幾億大軍的點擊形成在某一時刻的併發量是很高的，傳統的關係型數據庫確定已是不堪重負了，如Oracle的Session數量推薦的才只有500。網絡

二、高效率存儲海量數據併發

大數據時代，數據量已經不是用GB、TB來衡量了，而是EB、ZB了，面對這海量的數據，如何高效率的存儲這些數據，關係型數據庫沒法解決這個問題，以Oracle爲例，單機的物理擴展不只成本高，並且難度也加大了。分佈式

三、高可用&高擴展高併發

Oracle即便RAC能擴展數臺機器，但數量也是有限。性能

NoSql的出現便是爲了解決這些問題了，可是NoSql並非用來替代關係型數據庫的，由於它自己也有着不可克服的缺陷，俗話說，好處不可能都讓你佔了。大數據

關係型數據庫與NoSql一致性的比較
網站

通常來講,構建NoSql，爲了高可用和海量數據存儲，咱們會選擇犧牲一致性，但這並不意味着咱們不要一致性，而是咱們能夠選擇不實現強一致性，而實現弱一致性或者最終一致性。不管是在關係型數據庫或者NoSql中，咱們都是經過事務來實現一致性，下面咱們來討論二者在一致性方面的差別：

關係型數據庫事務的4個基本特性ACID，即原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。

而對於分佈式事務的特性BASE，則是反這個標準的，即基本可用（Basically Availble）、軟狀態/柔性事務（Soft-state）、最終一致性（Eventual Consistency）。下面是Brewer教授在PODC大會展現的ACID vs BASE：

前面咱們說過，NoSql的出現是爲了解決高併發、海量數據、高可用等問題的，於是通常分佈式是最優選項，咱們先來講一下分佈式系統的特性：CAP理論，固然，這也是NoSql的特性：

CAP理論

CAP理論是Brewer教授提出的：一個分佈式系統不能同時知足一致性（Consistency）、可用性（Availability）和分區容錯性（Tolerance of network Partition）。魚和熊掌不可兼得。

一致性：任何一個讀操做老是能讀取到以前完成的寫操做結果，也就是在分佈式環境中，多點的數據是一致的。

可用性：每個操做老是能在肯定的時間內返回，也不是系統隨時都是可用的。

分區容錯性：在出現網絡分區（如斷網）的狀況下，分離的系統也能正常運行。

PS：這裏有人可能會問，可用性與分區容錯性是否是一個意思（既然分區均可以容錯了，不就是可用麼），我的理解這裏可用性說的是調用不會被阻塞。

而市場上的NoSql則以CAP理論爲指導，大多選擇實現了CAP理論的兩點（如CA、CP、AP），未實現的即其缺陷部分。下面則是常見NoSql系統的特性：

常見NoSql的分類

類型	部分表明	特色
列存儲	Hbase Cassandra Hypertable	顧名思義，是按列存儲數據的。最大的特色是方便存儲結構化和半結構化數據，方便作數據壓縮，對針對某一列或者某幾列的查詢有很是大的IO優點。
文檔存儲	MongoDB CouchDB	文檔存儲通常用相似json的格式存儲，存儲的內容是文檔型的。這樣也就有有機會對某些字段創建索引，實現關係數據庫的某些功能。
kv存儲	Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis	能夠經過key快速查詢到其value。通常來講，存儲無論value的格式，照單全收。（Redis包含了其餘功能）
圖存儲	Neo4J FlockDB	圖形關係的最佳存儲。使用傳統關係數據庫來解決的話性能低下，並且設計使用不方便。
對象存儲	db4o Versant	經過相似面嚮對象語言的語法操做數據庫，經過對象的方式存取數據。
xml數據庫	Berkeley DB XML	高效的存儲XML數據，並支持XML的內部查詢語法，好比XQuery,Xpath。