1 理解ACID與BASE的區(qū)別（ACID是關(guān)系型數(shù)據(jù)庫強一致性的四個要求，而BASE是NoSQL數(shù)據(jù)庫通常對可用性及一致性的弱要求原則，它們的意思分別是，ACID：atomicity, consistency, isolation, durability;BASE：Basically Available, Soft-state, Eventually Consistent。同時有意思的是ACID在英語里意為酸，BASE意思為堿）
目前創(chuàng)新互聯(lián)建站已為近1000家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁空間、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計、甘泉網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
2 理解持久化與非持久化的區(qū)別。這么說是因為有的NoSQL系統(tǒng)是純內(nèi)存存儲的。
3 你必須意識到傳統(tǒng)有關(guān)系型數(shù)據(jù)庫與NoSQL系統(tǒng)在數(shù)據(jù)結(jié)構(gòu)上的本質(zhì)區(qū)別。傳統(tǒng)關(guān)系型數(shù)據(jù)庫通常是基于行的表格型存儲，而NoSQL系統(tǒng)包括了列式存儲（Cassandra）、key/value存儲（Memcached）、文檔型存儲（CouchDB）以及圖結(jié)構(gòu)存儲（Neo4j）
4與傳統(tǒng)關(guān)系數(shù)據(jù)庫有統(tǒng)一的SQL語言操作接口不同，NoSQL系統(tǒng)通常有自己特有的API接口。
5 在架構(gòu)上，你必須搞清楚，NoSQL系統(tǒng)是被設(shè)計用于成百上千臺機器的集群中的，而非共享型數(shù)據(jù)庫系統(tǒng)的架構(gòu)。
6在NoSQL系統(tǒng)中，可能你得習(xí)慣一下不知道你的數(shù)據(jù)具體存在何處的情況。
7 在NoSQL系統(tǒng)中，你最好習(xí)慣它的弱一致性?！眅ventually consistent”(最終一致性)正是BASE原則中的重要一項。比如在Twitter，你在Followers列表中經(jīng)常會感受到數(shù)據(jù)的延遲。
8 在NoSQL系統(tǒng)中，你要理解，很多時候數(shù)據(jù)并不總是可用的。
9 你得理解，有的方案是擁有分區(qū)容忍性的，有的方案不一定有。
NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題。
雖然NoSQL流行語火起來才短短一年的時間，但是不可否認，現(xiàn)在已經(jīng)開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗，然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個嚴酷的事實：技術(shù)越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲不得不進行重寫，也有少數(shù)人認為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數(shù)據(jù)建立快速、可擴展的存儲庫。
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關(guān)系型的數(shù)據(jù)存儲，相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運用，這一概念無疑是一種全新的思維的注入。
對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：
不需要預(yù)定義模式：不需要事先定義數(shù)據(jù)模式，預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當插入數(shù)據(jù)時，并不需要預(yù)先定義它們的模式。
無共享架構(gòu)：相對于將所有數(shù)據(jù)存儲的存儲區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)。NoSQL往往將數(shù)據(jù)劃分后存儲在各個本地服務(wù)器上。因為從本地磁盤讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能，從而提高了系統(tǒng)的性能。
彈性可擴展：可以在系統(tǒng)運行的時候，動態(tài)增加或者刪除結(jié)點。不需要停機維護，數(shù)據(jù)可以自動遷移。
分區(qū)：相對于將數(shù)據(jù)存放于同一個節(jié)點，NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進行分區(qū)，將記錄分散在多個節(jié)點上面。并且通常分區(qū)的同時還要做復(fù)制。這樣既提高了并行性能，又能保證沒有單點失效的問題。
異步復(fù)制：和RAID存儲系統(tǒng)不同的是，NoSQL中的復(fù)制，往往是基于日志的異步復(fù)制。這樣，數(shù)據(jù)就可以盡快地寫入一個節(jié)點，而不會被網(wǎng)絡(luò)傳輸引起遲延。缺點是并不總是能保證一致性，這樣的方式在出現(xiàn)故障的時候，可能會丟失少量的數(shù)據(jù)。
BASE：相對于事務(wù)嚴格的ACID特性，NoSQL數(shù)據(jù)庫保證的是BASE特性。BASE是最終一致性和軟事務(wù)。
NoSQL數(shù)據(jù)庫并沒有一個統(tǒng)一的架構(gòu)，兩種NoSQL數(shù)據(jù)庫之間的不同，甚至遠遠超過兩種關(guān)系型數(shù)據(jù)庫的不同。可以說，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應(yīng)用，在這些場合中會遠遠勝過關(guān)系型數(shù)據(jù)庫和其他的NoSQL。
NewSQL是對一類現(xiàn)代關(guān)系型數(shù)據(jù)庫的統(tǒng)稱，這類數(shù)據(jù)庫對于一般的OLTP讀寫請求提供可橫向擴展的性能，同時支持事務(wù)的ACID保證。這些系統(tǒng)既擁有NoSQL數(shù)據(jù)庫的擴展性，又保持傳統(tǒng)數(shù)據(jù)庫的事務(wù)特性。NewSQL重新將“應(yīng)用程序邏輯與數(shù)據(jù)操作邏輯應(yīng)該分離”的理念帶回到現(xiàn)代數(shù)據(jù)庫的世界，這也驗證了歷史的發(fā)展總是呈現(xiàn)出螺旋上升的形式。
在21世紀00年代中，出現(xiàn)了許多數(shù)據(jù)倉庫系統(tǒng) (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設(shè)計目標的系統(tǒng)并不在本文定義的NewSQL范圍內(nèi)。OLAP 數(shù)據(jù)庫更關(guān)注針對海量數(shù)據(jù)的大型、復(fù)雜、只讀的查詢，查詢時間可能持續(xù)秒級、分鐘級甚至更長。
NoSQL的擁躉普遍認為阻礙傳統(tǒng)數(shù)據(jù)庫橫向擴容、提高可用性的原因在于ACID保證和關(guān)系模型，因此NoSQL運動的核心就是放棄事務(wù)強一致性以及關(guān)系模型，擁抱最終一致性和其它數(shù)據(jù)模型?(如 key/value，graphs 和Documents)。
兩個最著名的NoSQL數(shù)據(jù)庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運動中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應(yīng)了NoSQL的哲學(xué)，其中最出名的就是MongoDB。
在21世紀00年代末，市面上已經(jīng)有許多供用戶選擇的分布式數(shù)據(jù)庫產(chǎn)品。使用NoSQL的優(yōu)勢在于應(yīng)用開發(fā)者可以更關(guān)注應(yīng)用邏輯本身，而非數(shù)據(jù)庫的擴展性問題；但與此同時許多應(yīng)用，如金融系統(tǒng)、訂單處理系統(tǒng)，由于無法放棄事務(wù)的一致性要求被拒之門外。
一些組織，如Google，已經(jīng)發(fā)現(xiàn)他們的許多工程師將過多的精力放在處理數(shù)據(jù)一致性上，這既暴露了數(shù)據(jù)庫的抽象、又提高了代碼的復(fù)雜度，這時候要么選擇回到傳統(tǒng)DBMS時代，用更高的機器配置縱向擴容，要么選擇回到中間件時代，開發(fā)支持分布式事務(wù)的中間件。這兩種方案成本都很高，于是NewSQL運動開始醞釀。
NewSQL數(shù)據(jù)庫設(shè)計針對的讀寫事務(wù)有以下特點：
1、耗時短。
2、使用索引查詢，涉及少量數(shù)據(jù)。
3、重復(fù)度高，通常使用相同的查詢語句和不同的查詢參考。
也有一些學(xué)者認為NewSQL系統(tǒng)是特指實現(xiàn)上使用Lock-free并發(fā)控制技術(shù)和share-nothing架構(gòu)的數(shù)據(jù)庫。所有我們認為是NewSQL的數(shù)據(jù)庫系統(tǒng)確實都有這樣的特點。
而傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對數(shù)據(jù)庫高并發(fā)讀寫的需求
web2.0網(wǎng)站要根據(jù)用戶個性化信息來實時生成動態(tài)頁面和提供動態(tài)信息，所以基本上無法使用動態(tài)頁面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫并發(fā)負載非常高，往往要達到每秒上萬次讀寫請求。關(guān)系數(shù)據(jù)庫應(yīng)付上萬次SQL查詢還勉強頂?shù)米?，但是?yīng)付上萬次SQL寫數(shù)據(jù)請求，硬盤IO就已經(jīng)無法承受了。其實對于普通的BBS網(wǎng)站，往往也存在對高并發(fā)寫請求的需求。
2、Huge Storage - 對海量數(shù)據(jù)的高效率存儲和訪問的需求
對于大型的SNS網(wǎng)站，每天用戶產(chǎn)生海量的用戶動態(tài)，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態(tài)，對于關(guān)系數(shù)據(jù)庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動輒數(shù)以億計的帳號，關(guān)系數(shù)據(jù)庫也很難應(yīng)付。
3、High Scalability High Availability- 對數(shù)據(jù)庫的高可擴展性和高可用性的需求
在基于web的架構(gòu)當中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應(yīng)用系統(tǒng)的用戶量和訪問量與日俱增的時候，你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務(wù)節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務(wù)的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫不能通過不斷的添加服務(wù)器節(jié)點來實現(xiàn)擴展呢？
在上面提到的“三高”需求面前，關(guān)系數(shù)據(jù)庫遇到了難以克服的障礙，而對于web2.0網(wǎng)站來說，關(guān)系數(shù)據(jù)庫的很多主要特性卻往往無用武之地，例如：
1、數(shù)據(jù)庫事務(wù)一致性需求
很多web實時系統(tǒng)并不要求嚴格的數(shù)據(jù)庫事務(wù)，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數(shù)據(jù)庫事務(wù)管理成了數(shù)據(jù)庫高負載下一個沉重的負擔。
2、數(shù)據(jù)庫的寫實時性和讀實時性需求
對關(guān)系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對于很多web應(yīng)用來說，并不要求這么高的實時性。
3、對復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢的需求
任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關(guān)聯(lián)查詢，以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設(shè)計角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關(guān)系數(shù)據(jù)庫在這些越來越多的應(yīng)用場景下顯得不那么合適了，為了解決這類問題的非關(guān)系數(shù)據(jù)庫應(yīng)運而生。
NoSQL 是非關(guān)系型數(shù)據(jù)存儲的廣義定義。它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲不需要固定的表結(jié)構(gòu)，通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢。該術(shù)語在 2009 年初得到了廣泛認同。
當今的應(yīng)用體系結(jié)構(gòu)需要數(shù)據(jù)存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現(xiàn)這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現(xiàn)。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。
下面是NoSQL Database的特性簡介：
數(shù)據(jù)模型簡單
●Key-Value式的存儲，其中key由一級主要key和二次次要key組成
●由Java寫成，支持基于Java API 的Put、Delete和GET操作
擴展性強
●支持自動地基于hash函數(shù)的數(shù)據(jù)分片策略
●提供基于數(shù)據(jù)節(jié)點拓撲結(jié)構(gòu)和訪問延遲的智能控制，以提供最佳的數(shù)據(jù)訪問性能
行為可預(yù)測性
●提供ACID 的事務(wù)性支持，并且支持基于全局和單個操作的事務(wù)級別設(shè)置
●通過B-tree 數(shù)據(jù)結(jié)構(gòu)構(gòu)成的Cache層和高效的查詢調(diào)度機制，提供可控的請求延時
高可用性
●沒有單點故障
●提供內(nèi)置且可配置的數(shù)據(jù)復(fù)制備份機制
●對單點或多點故障有很好的容錯性
●通過跨數(shù)據(jù)中心的數(shù)據(jù)備份，提供數(shù)據(jù)的災(zāi)難恢復(fù)
簡單的管理與維護
●除了命令行之外，還提供基于Web的界面管理工具
●提供對系統(tǒng)及數(shù)據(jù)節(jié)點的控制控制
●可以查看系統(tǒng)的拓撲結(jié)構(gòu)、系統(tǒng)狀態(tài)參數(shù)、當前負載情況、請求延遲記錄、內(nèi)部事件及通知等信息
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，
泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲不需要固定的模式，無需多余操作就可以橫向擴展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關(guān)系型數(shù)據(jù)庫與NoSQL的區(qū)別？
3.1 RDBMS
高度組織化結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化查詢語言（SQL）
數(shù)據(jù)和關(guān)系都存儲在單獨的表中。
數(shù)據(jù)操縱語言，數(shù)據(jù)定義語言
嚴格的一致性
基礎(chǔ)事務(wù)
ACID
關(guān)系型數(shù)據(jù)庫遵循ACID規(guī)則
事務(wù)在英文中是transaction，和現(xiàn)實世界中的交易很類似，它有如下四個特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說事務(wù)里的所有操作要么全部做完，要么都不做，事務(wù)成功的條件是事務(wù)里的所有操作都成功，只要有一個操作失敗，整個事務(wù)就失敗，需要回滾。比如銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài)，事務(wù)的運行不會改變數(shù)據(jù)庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指并發(fā)的事務(wù)之間不會互相影響，如果一個事務(wù)要訪問的數(shù)據(jù)正在被另外一個事務(wù)修改，只要另外一個事務(wù)未提交，它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務(wù)提交后，它所做的修改將會永久的保存在數(shù)據(jù)庫上，即使出現(xiàn)宕機也不會丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預(yù)定義的模式
鍵 - 值對存儲，列存儲，文檔存儲，圖形數(shù)據(jù)庫
最終一致性，而非ACID屬性
非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
CAP定理
高性能，高可用性和可伸縮性
分布式數(shù)據(jù)庫中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的
Availability(可用性), 好的響應(yīng)性能
Partition tolerance(分區(qū)容錯性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
定理：任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。
CAP理論的核心是：一個分布式系統(tǒng)不可能同時很好的滿足一致性，可用性和分區(qū)容錯性這三個需求，
因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點集群，滿足一致性，可用性的系統(tǒng)，通常在可擴展性上不太強大。
CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐σ恢滦砸蟮鸵恍?。
CAP理論就是說在分布式存儲系統(tǒng)中，最多只能實現(xiàn)上面的兩點。
而由于當前的網(wǎng)絡(luò)硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實現(xiàn)的。
所以我們只能在一致性和可用性之間進行權(quán)衡，沒有NoSQL系統(tǒng)能同時保證這三點。
說明：C：強一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統(tǒng)Oracle數(shù)據(jù)庫
AP：大多數(shù)網(wǎng)站架構(gòu)的選擇
CP：Redis、Mongodb
注意：分布式架構(gòu)的時候必須做出取舍。
一致性和可用性之間取一個平衡。多余大多數(shù)web應(yīng)用，其實并不需要強一致性。
因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。
4. 當下NoSQL的經(jīng)典應(yīng)用
當下的應(yīng)用是 SQL 與 NoSQL 一起使用的。
代表項目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機，很貴的，好像好幾萬一臺；O 是指 Oracle 數(shù)據(jù)庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設(shè)備，也很貴的。
難點：
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構(gòu)。
數(shù)據(jù)源改造而服務(wù)平臺不需要大面積重構(gòu)。
重慶分公司
重慶分公司
