NoSQL(NoSQL = Not Only SQL )，意即"不僅僅是SQL"。

現(xiàn)代計(jì)算系統(tǒng)每天在網(wǎng)絡(luò)上都會(huì)產(chǎn)生龐大的數(shù)據(jù)量。這些數(shù)據(jù)有很大一部分是由關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)（RDBMSs）來(lái)處理，其嚴(yán)謹(jǐn)成熟的數(shù)學(xué)理論基礎(chǔ)使得數(shù)據(jù)建模和應(yīng)用程序編程更加簡(jiǎn)單。

但隨著信息化的浪潮和互聯(lián)網(wǎng)的興起，傳統(tǒng)的RDBMS在一些業(yè)務(wù)上開(kāi)始出現(xiàn)問(wèn)題。首先，對(duì)數(shù)據(jù)庫(kù)存儲(chǔ)的容量要求越來(lái)越高，單機(jī)無(wú)法滿足需求，很多時(shí)候需要用集群來(lái)解決問(wèn)題，而RDBMS由于要支持join，union等操作，一般不支持分布式集群。其次，在大數(shù)據(jù)大行其道的今天，很多的數(shù)據(jù)都“頻繁讀和增加，不頻繁修改”，而RDBMS對(duì)所有操作一視同仁，這就帶來(lái)了優(yōu)化的空間。另外，互聯(lián)網(wǎng)時(shí)代業(yè)務(wù)的不確定性導(dǎo)致數(shù)據(jù)庫(kù)的存儲(chǔ)模式也需要頻繁變更，不自由的存儲(chǔ)模式增大了運(yùn)維的復(fù)雜性和擴(kuò)展的難度。

NoSQL 是一項(xiàng)全新的數(shù)據(jù)庫(kù)革命性運(yùn)動(dòng)，早期就有人提出，發(fā)展至2009年趨勢(shì)越發(fā)高漲。這類數(shù)據(jù)庫(kù)主要有這些特點(diǎn)：非關(guān)系型的、分布式的、開(kāi)源的、水平可擴(kuò)展的。最初的目的是為了大規(guī)模web 應(yīng)用。NoSQL 的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)據(jù)存儲(chǔ)，通常的應(yīng)用如下特點(diǎn)：模式自由、支持簡(jiǎn)易復(fù)制、簡(jiǎn)單的API、最終的一致性（非ACID）、大容量數(shù)據(jù)等。

筆者是MongoDB用戶，也使用過(guò)Redis。關(guān)系型數(shù)據(jù)庫(kù)使用過(guò)MySQL與Oracle，對(duì)兩者的區(qū)別有一定的體會(huì)。Mongo和Redis的操作都非常簡(jiǎn)單，速度很快，很多用SQL需要很多條語(yǔ)句的操作在NoSQL數(shù)據(jù)庫(kù)中都是2句以內(nèi)完成。另外NoSQL配置cluster也很容易，且可以隨時(shí)更改partition和replication的數(shù)量，Mongo的新版本還內(nèi)置了MapReduce操作，使其有了做大數(shù)據(jù)分析的能力。

NoSQL理論基礎(chǔ)

1.關(guān)系型數(shù)據(jù)庫(kù)理論 - ACID

ACID，是指數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）在寫(xiě)入或更新資料的過(guò)程中，為保證事務(wù)（transaction）是正確可靠的，所必須具備的四個(gè)特性：原子性（atomicity，或稱不可分割性）、一致性（consistency）、隔離性（isolation，又稱獨(dú)立性）、持久性（durability）。

• A – Atomicity – 原子性

一個(gè)事務(wù)（transaction）中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過(guò)程中發(fā)生錯(cuò)誤，會(huì)被回滾（Rollback）到事務(wù)開(kāi)始前的狀態(tài)，就像這個(gè)事務(wù)從來(lái)沒(méi)有被執(zhí)行過(guò)一樣。

• C – Consistency – 一致性

在事務(wù)開(kāi)始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫(kù)的完整性沒(méi)有被破壞。這表示寫(xiě)入的資料必須完全符合所有的預(yù)設(shè)規(guī)則，這包含資料的精確度、串聯(lián)性以及后續(xù)數(shù)據(jù)庫(kù)可以自發(fā)性地完成預(yù)定的工作。

• I – Isolation – 隔離性

數(shù)據(jù)庫(kù)允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)其數(shù)據(jù)進(jìn)行讀寫(xiě)和修改的能力，隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級(jí)別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復(fù)讀（repeatable read）和串行化（Serializable）。

• D – Durability – 持久性

事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。

關(guān)系型數(shù)據(jù)庫(kù)嚴(yán)格遵循ACID理論。但當(dāng)數(shù)據(jù)庫(kù)要開(kāi)始滿足橫向擴(kuò)展、高可用、模式自由等需求時(shí)，需要對(duì)ACID理論進(jìn)行取舍，不能嚴(yán)格遵循ACID。以CAP理論和BASE理論為基礎(chǔ)的NoSQL數(shù)據(jù)庫(kù)開(kāi)始出現(xiàn)。

2.分布式系統(tǒng)理論

2.1 分布式系統(tǒng)介紹

分布式系統(tǒng)的核心理念是讓多臺(tái)服務(wù)器協(xié)同工作，完成單臺(tái)服務(wù)器無(wú)法處理的任務(wù)，尤其是高并發(fā)或者大數(shù)據(jù)量的任務(wù)。分布式是NoSQL數(shù)據(jù)庫(kù)的必要條件。

分布式系統(tǒng)由獨(dú)立的服務(wù)器通過(guò)網(wǎng)絡(luò)松散耦合組成的。每個(gè)服務(wù)器都是一臺(tái)獨(dú)立的PC機(jī)，服務(wù)器之間通過(guò)內(nèi)部網(wǎng)絡(luò)連接，內(nèi)部網(wǎng)絡(luò)速度一般比較快。因?yàn)?a href='/map/fenbushijiqun/' style='color:#000;font-size:inherit;'>分布式集群里的服務(wù)器是通過(guò)內(nèi)部網(wǎng)絡(luò)松散耦合，各節(jié)點(diǎn)之間的通訊有一定的網(wǎng)絡(luò)開(kāi)銷，因此分布式系統(tǒng)在設(shè)計(jì)上盡可能減少節(jié)點(diǎn)間通訊。此外，因?yàn)榫W(wǎng)絡(luò)傳輸瓶頸，單個(gè)節(jié)點(diǎn)的性能高低對(duì)分布式系統(tǒng)整體性能影響不大。比如，對(duì)分布式應(yīng)用來(lái)說(shuō)，采用不同編程語(yǔ)言開(kāi)發(fā)帶來(lái)的單個(gè)應(yīng)用服務(wù)的性能差異，跟網(wǎng)絡(luò)開(kāi)銷比起來(lái)都可以忽略不計(jì)。

因此，分布式系統(tǒng)每個(gè)節(jié)點(diǎn)一般不采用高性能的服務(wù)器，而是使用性能相對(duì)一般的普通PC服務(wù)器。提升分布式系統(tǒng)的整體性能是通過(guò)橫向擴(kuò)展（增加更多的服務(wù)器），而不是縱向擴(kuò)展（提升每個(gè)節(jié)點(diǎn)的服務(wù)器性能）實(shí)現(xiàn)。

分布式系統(tǒng)最大的特點(diǎn)是可擴(kuò)展性，它能夠適應(yīng)需求變化而擴(kuò)展。企業(yè)級(jí)應(yīng)用需求經(jīng)常隨時(shí)間而不斷變化，這也對(duì)企業(yè)級(jí)應(yīng)用平臺(tái)提出了很高的要求。企業(yè)級(jí)應(yīng)用平臺(tái)必須要能適應(yīng)需求的變化，即具有可擴(kuò)展性。比如移動(dòng)互聯(lián)網(wǎng)2C應(yīng)用，隨著互聯(lián)網(wǎng)企業(yè)的業(yè)務(wù)規(guī)模不斷增大，業(yè)務(wù)變得越來(lái)越復(fù)雜，并發(fā)用戶請(qǐng)求越來(lái)越多，要處理的數(shù)據(jù)也越來(lái)越多，這個(gè)時(shí)候企業(yè)級(jí)應(yīng)用平臺(tái)必須能夠適應(yīng)這些變化，支持高并發(fā)訪問(wèn)和海量數(shù)據(jù)處理。分布式系統(tǒng)有良好的可擴(kuò)展性，可以通過(guò)增加服務(wù)器數(shù)量來(lái)增強(qiáng)分布式系統(tǒng)整體的處理能力，以應(yīng)對(duì)企業(yè)的業(yè)務(wù)增長(zhǎng)帶來(lái)的計(jì)算需求增加。

2.2 分布式存儲(chǔ)的問(wèn)題 – CAP理論

如果我們期待實(shí)現(xiàn)一套嚴(yán)格滿足ACID的分布式事務(wù)，很可能出現(xiàn)的情況就是系統(tǒng)的可用性和嚴(yán)格一致性發(fā)生沖突。在可用性和一致性之間永遠(yuǎn)無(wú)法存在一個(gè)兩全其美的方案。由于NoSQL的基本需求就是支持分布式存儲(chǔ)，嚴(yán)格一致性與可用性需要互相取舍，由此延伸出了CAP理論來(lái)定義分布式存儲(chǔ)遇到的問(wèn)題。

CAP理論告訴我們：一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性(C:Consistency)、可用性(A:Availability)、分區(qū)容錯(cuò)性(P:Partitiontolerance)這三個(gè)基本需求，并且最多只能滿足其中的兩項(xiàng)。

對(duì)于一個(gè)分布式系統(tǒng)來(lái)說(shuō)，分區(qū)容錯(cuò)是基本需求，否則不能稱之為分布式系統(tǒng)。因此架構(gòu)師需要在C和A之間尋求平衡。

• C – Consistency – 一致性（與ACID的C完全不同）

一致性是指“all nodes see the same data at the same time”，即更新操作成功并返回客戶端完成后，所有節(jié)點(diǎn)在同一時(shí)間的數(shù)據(jù)完全一致。

對(duì)于一致性，可以分為從客戶端和服務(wù)端兩個(gè)不同的視角。

從客戶端來(lái)看，一致性主要指的是多并發(fā)訪問(wèn)時(shí)更新過(guò)的數(shù)據(jù)如何獲取的問(wèn)題。

從服務(wù)端來(lái)看，則是更新如何復(fù)制分布到整個(gè)系統(tǒng)，以保證數(shù)據(jù)最終一致。一致性是因?yàn)橛胁l(fā)讀寫(xiě)才有的問(wèn)題，因此在理解一致性的問(wèn)題時(shí)，一定要注意結(jié)合考慮并發(fā)讀寫(xiě)的場(chǎng)景。

從客戶端角度，多進(jìn)程并發(fā)訪問(wèn)時(shí)，更新過(guò)的數(shù)據(jù)在不同進(jìn)程如何獲取的不同策略，決定了不同的一致性。對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，要求更新過(guò)的數(shù)據(jù)能被后續(xù)的訪問(wèn)都能看到，這是強(qiáng)一致性。如果能容忍后續(xù)的部分或者全部訪問(wèn)不到，則是弱一致性。如果經(jīng)過(guò)一段時(shí)間后要求能訪問(wèn)到更新后的數(shù)據(jù)，則是最終一致性。

• A – Availability – 可用性

可用性是指“Reads and writes always succeed”，即服務(wù)一直可用，而且是正常響應(yīng)時(shí)間。

對(duì)于一個(gè)可用性的分布式系統(tǒng)，每一個(gè)非故障的節(jié)點(diǎn)必須對(duì)每一個(gè)請(qǐng)求作出響應(yīng)。也就是說(shuō)，該系統(tǒng)使用的任何算法必須最終終止。當(dāng)同時(shí)要求分區(qū)容忍性時(shí)，這是一個(gè)很強(qiáng)的定義：即使是嚴(yán)重的網(wǎng)絡(luò)錯(cuò)誤，每個(gè)請(qǐng)求必須完成。

好的可用性主要是指系統(tǒng)能夠很好的為用戶服務(wù)，不出現(xiàn)用戶操作失敗或者訪問(wèn)超時(shí)等用戶體驗(yàn)不好的情況。在通常情況下，可用性與分布式數(shù)據(jù)冗余、負(fù)載均衡等有著很大的關(guān)聯(lián)。

• P – Partition tolerance – 分區(qū)容錯(cuò)性

分區(qū)容錯(cuò)性是指“the system continues to operate despite arbitrary message loss or failureof part of the system”，即分布式系統(tǒng)在遇到某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)。

分區(qū)容錯(cuò)性和擴(kuò)展性緊密相關(guān)。在分布式應(yīng)用中，可能因?yàn)橐恍┓植际降脑驅(qū)е孪到y(tǒng)無(wú)法正常運(yùn)轉(zhuǎn)。好的分區(qū)容錯(cuò)性要求能夠使應(yīng)用雖然是一個(gè)分布式系統(tǒng)，但看上去卻好像是一個(gè)可以運(yùn)轉(zhuǎn)正常的整體。比如現(xiàn)在的分布式系統(tǒng)中有某一個(gè)或者幾個(gè)機(jī)器宕掉了，其它剩下的機(jī)器還能夠正常運(yùn)轉(zhuǎn)滿足系統(tǒng)需求，或者是機(jī)器之間有網(wǎng)絡(luò)異常，將分布式系統(tǒng)分隔成未獨(dú)立的幾個(gè)部分，各個(gè)部分還能維持分布式系統(tǒng)的運(yùn)作，這樣就具有好的分區(qū)容錯(cuò)性。

• CA without P

如果不要求P（不允許分區(qū)），則C（強(qiáng)一致性）和A（可用性）是可以保證的。但其實(shí)分區(qū)不是你想不想的問(wèn)題，而是始終會(huì)存在，因此CA的系統(tǒng)更多的是允許分區(qū)后各子系統(tǒng)依然保持CA。

• CP without A

如果不要求A（可用），相當(dāng)于每個(gè)請(qǐng)求都需要在Server之間強(qiáng)一致，而P（分區(qū)）會(huì)導(dǎo)致同步時(shí)間無(wú)限延長(zhǎng)，如此CP也是可以保證的。很多傳統(tǒng)的數(shù)據(jù)庫(kù)分布式事務(wù)都屬于這種模式。

• AP without C

要高可用并允許分區(qū)，則需放棄一致性。一旦分區(qū)發(fā)生，節(jié)點(diǎn)之間可能會(huì)失去聯(lián)系，為了高可用，每個(gè)節(jié)點(diǎn)只能用本地?cái)?shù)據(jù)提供服務(wù)，而這樣會(huì)導(dǎo)致全局?jǐn)?shù)據(jù)的不一致性。現(xiàn)在眾多的NoSQL都屬于此類。

CAP理論定義了分布式存儲(chǔ)的根本問(wèn)題，但并沒(méi)有指出一致性和可用性之間到底應(yīng)該如何權(quán)衡。于是出現(xiàn)了BASE理論，給出了權(quán)衡A與C的一種可行方案。

2.3 權(quán)衡一致性與可用性 - BASE理論

Base = Basically Available + Soft state + Eventuallyconsistent 基本可用性+軟狀態(tài)+最終一致性，由eBay架構(gòu)師DanPritchett提出。Base是對(duì)CAP中一致性A和可用性C權(quán)衡的結(jié)果，源于提出者自己在大規(guī)模分布式系統(tǒng)上實(shí)踐的總結(jié)。核心思想是無(wú)法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身的特點(diǎn)，采用適當(dāng)方式達(dá)到最終一致性。

• BA - Basically Available - 基本可用

基本可用。這里是指分布式系統(tǒng)在出現(xiàn)故障的時(shí)候，允許損失部分可用性，即保證核心功能或者當(dāng)前最重要功能可用。對(duì)于用戶來(lái)說(shuō)，他們當(dāng)前最關(guān)注的功能或者最常用的功能的可用性將會(huì)獲得保證，但是其他功能會(huì)被削弱。

• S – Soft State - 軟狀態(tài)

允許系統(tǒng)數(shù)據(jù)存在中間狀態(tài)，但不會(huì)影響到系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步時(shí)存在延時(shí)。

• E - Eventually Consistent - 最終一致性

要求系統(tǒng)數(shù)據(jù)副本最終能夠一致，而不需要實(shí)時(shí)保證數(shù)據(jù)副本一致。最終一致性是弱一致性的一種特殊情況。最終一致性有5個(gè)變種：

• 因果一致性
• 讀己之所寫(xiě)(因果一致性特例)
• 會(huì)話一致性
• 單調(diào)讀一致性
• 單調(diào)寫(xiě)一致性

3.分布式存儲(chǔ)算法

3.1一致性算法 – Paxos

Paxos 算法解決的問(wèn)題是一個(gè)分布式系統(tǒng)如何就某個(gè)值（決議）達(dá)成一致。一個(gè)典型的場(chǎng)景是，在一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)中，如果各節(jié)點(diǎn)的初始狀態(tài)一致，每個(gè)節(jié)點(diǎn)執(zhí)行相同的操作序列，那么他們最后能得到一個(gè)一致的狀態(tài)。為保證每個(gè)節(jié)點(diǎn)執(zhí)行相同的命令序列，需要在每一條指令上執(zhí)行一個(gè)“一致性算法”以保證每個(gè)節(jié)點(diǎn)看到的指令一致。一個(gè)通用的一致性算法可以應(yīng)用在許多場(chǎng)景中，是分布式計(jì)算中的重要問(wèn)題。因此從20世紀(jì)80年代起對(duì)于一致性算法的研究就沒(méi)有停止過(guò)。節(jié)點(diǎn)通信存在兩種模型：共享內(nèi)存（Shared memory）和消息傳遞（Messages passing）。Paxos 算法就是一種基于消息傳遞模型的一致性算法。

不僅僅是在分布式系統(tǒng)中，凡是多個(gè)過(guò)程需要達(dá)成某種一致的場(chǎng)合都可以使用Paxos 算法。一致性算法可以通過(guò)共享內(nèi)存（需要鎖）或者消息傳遞實(shí)現(xiàn)，Paxos 算法采用的是后者。Paxos 算法適用的幾種情況：一臺(tái)機(jī)器中多個(gè)進(jìn)程/線程達(dá)成數(shù)據(jù)一致；分布式文件系統(tǒng)或者分布式數(shù)據(jù)庫(kù)中多客戶端并發(fā)讀寫(xiě)數(shù)據(jù)；分布式存儲(chǔ)中多個(gè)副本響應(yīng)讀寫(xiě)請(qǐng)求的一致性。

3.2分區(qū)（Partitioning）

原來(lái)所有的數(shù)據(jù)都是在一個(gè)數(shù)據(jù)庫(kù)上的，網(wǎng)絡(luò)IO及文件IO都集中在一個(gè)數(shù)據(jù)庫(kù)上的，因此CPU、內(nèi)存、文件IO、網(wǎng)絡(luò)IO都可能會(huì)成為系統(tǒng)瓶頸。而分區(qū)的方案就是把某一個(gè)表或某幾個(gè)相關(guān)的表的數(shù)據(jù)放在一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)上，這樣就可以把CPU、內(nèi)存、文件IO、網(wǎng)絡(luò)IO分解到多個(gè)機(jī)器中，從而提升系統(tǒng)處理能力。

3.3分片（Replication）

分區(qū)有兩種模式，一種是主從模式，用于做讀寫(xiě)分離；另外一種模式是分片模式，也就是說(shuō)把一個(gè)表中的數(shù)據(jù)分解到多個(gè)表中。一個(gè)分區(qū)只能是其中的一種模式。

3.4一致性哈希（Consistent Hashing）

一致性哈希算法是分布式系統(tǒng)中常用的算法。比如，一個(gè)分布式的存儲(chǔ)系統(tǒng)，要將數(shù)據(jù)存儲(chǔ)到具體的節(jié)點(diǎn)上，如果采用普通的hash方法，將數(shù)據(jù)映射到具體的節(jié)點(diǎn)上，如key%N，key是數(shù)據(jù)的key，N是機(jī)器節(jié)點(diǎn)數(shù)，如果有一個(gè)機(jī)器加入或退出這個(gè)集群，則所有的數(shù)據(jù)映射都無(wú)效了，如果是持久化存儲(chǔ)則要做數(shù)據(jù)遷移，如果是分布式緩存，則其他緩存就失效了。

一致性哈?；窘鉀Q了在P2P環(huán)境中最為關(guān)鍵的問(wèn)題——如何在動(dòng)態(tài)的網(wǎng)絡(luò)拓?fù)渲蟹植即鎯?chǔ)和路由。每個(gè)節(jié)點(diǎn)僅需維護(hù)少量相鄰節(jié)點(diǎn)的信息，并且在節(jié)點(diǎn)加入/退出系統(tǒng)時(shí)，僅有相關(guān)的少量節(jié)點(diǎn)參與到拓?fù)涞木S護(hù)中。所有這一切使得一致性哈希成為第一個(gè)實(shí)用的DHT算法。

4.NoSQL的優(yōu)點(diǎn)/缺點(diǎn)

優(yōu)點(diǎn)

缺點(diǎn)

1.易擴(kuò)展

2.高性能

3.數(shù)據(jù)類型靈活

4.高可用

1.沒(méi)有標(biāo)準(zhǔn)

2.沒(méi)有存儲(chǔ)過(guò)程

3.不支持sql

4.功能不夠完善

4.1優(yōu)點(diǎn)

• 易擴(kuò)展

NoSQL數(shù)據(jù)庫(kù)種類繁多，但是有一個(gè)共同的特點(diǎn)，都是去掉了關(guān)系型數(shù)據(jù)庫(kù)的關(guān)系型特性。數(shù)據(jù)之間無(wú)關(guān)系，這樣就非常容易擴(kuò)展。也無(wú)形之間，在架構(gòu)的層面上帶來(lái)了可擴(kuò)展的能力。

• 大數(shù)據(jù)量，高性能

NoSQL數(shù)據(jù)庫(kù)都具有非常高的讀寫(xiě)性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無(wú)關(guān)系性，數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單。一般MySQL使用Query Cache，每次表更新Cache就失效，是一種大粒度的Cache，針對(duì)web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的Cache是記錄級(jí)的，是一種細(xì)粒度的Cache，所以NoSQL在這個(gè)層面上來(lái)說(shuō)性能就要高很多了。

• 靈活的數(shù)據(jù)模型

NoSQL無(wú)需事先為要存儲(chǔ)的數(shù)據(jù)建立字段，隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式。而在關(guān)系型數(shù)據(jù)庫(kù)里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡(jiǎn)直就是一個(gè)噩夢(mèng)。這點(diǎn)在大數(shù)據(jù)量的web2.0時(shí)代尤其明顯。

• 高可用

NoSQL在不太影響性能的情況下，就可以方便地實(shí)現(xiàn)高可用的架構(gòu)。比如Cassandra、HBase模型，通過(guò)復(fù)制模型也能實(shí)現(xiàn)高可用。

4.1缺點(diǎn)

• 沒(méi)有標(biāo)準(zhǔn)

沒(méi)有對(duì)NoSQL數(shù)據(jù)庫(kù)定義的標(biāo)準(zhǔn)，所以沒(méi)有兩個(gè)NoSQL數(shù)據(jù)庫(kù)是平等的。

• 沒(méi)有存儲(chǔ)過(guò)程

NoSQL數(shù)據(jù)庫(kù)中大多沒(méi)有存儲(chǔ)過(guò)程。

• 不支持SQL

NoSQL大多不提供對(duì)SQL的支持：如果不支持SQL這樣的工業(yè)標(biāo)準(zhǔn)，將會(huì)對(duì)用戶產(chǎn)生一定的學(xué)習(xí)和應(yīng)用遷移上的成本。

• 支持的特性不夠豐富，產(chǎn)品不夠成熟

現(xiàn)有產(chǎn)品所提供的功能都比較有限，不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報(bào)表等。大多數(shù)產(chǎn)品都還處于初創(chuàng)期，和關(guān)系型數(shù)據(jù)庫(kù)幾十年的完善不可同日而語(yǔ)。

NoSQL與SQL的對(duì)比

RDBMS

NoSQL

模式

預(yù)定義的模式

沒(méi)有預(yù)定義的模式

查詢語(yǔ)言

結(jié)構(gòu)化查詢語(yǔ)言（SQL）

沒(méi)有聲明性查詢語(yǔ)言

一致性

嚴(yán)格的一致性

最終一致性

事務(wù)

支持

不支持

理論基礎(chǔ)

ACID

CAP, BASE

擴(kuò)展

縱向擴(kuò)展

橫向擴(kuò)展(分布式)

NoSQL數(shù)據(jù)庫(kù)的分類

1.鍵值(Key-Value)存儲(chǔ)數(shù)據(jù)庫(kù)

這一類數(shù)據(jù)庫(kù)主要會(huì)使用到哈希表，在這個(gè)表中有一個(gè)特定的鍵和一個(gè)指針指向特定的數(shù)據(jù)。Key/value模型對(duì)于IT系統(tǒng)來(lái)說(shuō)優(yōu)勢(shì)在于簡(jiǎn)單、易部署。但是如果DBA只對(duì)部分值進(jìn)行查詢或更新的時(shí)候，Key/value就顯得效率低下了。

E. g:

• TokyoCabinet/Tyrant
• Redis
• Voldemort
• OracleBDB
• 列存儲(chǔ)數(shù)據(jù)庫(kù)

這部分?jǐn)?shù)據(jù)庫(kù)通常是用來(lái)應(yīng)對(duì)分布式存儲(chǔ)的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點(diǎn)是指向了多個(gè)列。這些列是由列家族來(lái)安排的。

E. g:

• Cassandra
• HBase
• Riak
• 文檔型數(shù)據(jù)庫(kù)

文檔型數(shù)據(jù)庫(kù)的靈感來(lái)自于Lotus Notes辦公軟件，它同第一種鍵值存儲(chǔ)相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結(jié)構(gòu)化的文檔以特定的格式存儲(chǔ)，比如JSON。文檔型數(shù)據(jù)庫(kù)可以看作是鍵值數(shù)據(jù)庫(kù)的升級(jí)版，允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫(kù)比鍵值數(shù)據(jù)庫(kù)的查詢效率更高。

E. g:

• CouchDB
• MongoDB
• SequoiaDB
• 圖形(Graph)數(shù)據(jù)庫(kù)

圖形結(jié)構(gòu)的數(shù)據(jù)庫(kù)同其它行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫(kù)不同，它是使用靈活的圖形模型，并且能夠擴(kuò)展到多個(gè)服務(wù)器上。NoSQL數(shù)據(jù)庫(kù)沒(méi)有標(biāo)準(zhǔn)的查詢語(yǔ)言(SQL)，因此進(jìn)行數(shù)據(jù)庫(kù)查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫(kù)都有REST式的數(shù)據(jù)接口或者查詢API。

E. g:

• Neo4J
• InfoGrid
• InfiniteGraph

主流NoSQL數(shù)據(jù)庫(kù)介紹及其適用場(chǎng)景

1. Redis

1.1 介紹

Redis是一個(gè)開(kāi)源的使用ANSI C語(yǔ)言編寫(xiě)、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫(kù)，并提供多種語(yǔ)言的API。從2010年3月15日起，Redis的開(kāi)發(fā)工作由VMware主持。從2013年5月開(kāi)始，Redis的開(kāi)發(fā)由Pivotal贊助。

1.2 適用場(chǎng)景

• 數(shù)據(jù)變化較少，執(zhí)行預(yù)定義查詢，進(jìn)行數(shù)據(jù)統(tǒng)計(jì)的應(yīng)用程序
• 需要提供數(shù)據(jù)版本支持的應(yīng)用程序
• 例如：股票價(jià)格、數(shù)據(jù)分析、實(shí)時(shí)數(shù)據(jù)搜集、實(shí)時(shí)通訊、分布式緩存

2. MongoDB

2.1 介紹

MongoDB 是一個(gè)基于分布式文件存儲(chǔ)的數(shù)據(jù)庫(kù)。由 C++ 語(yǔ)言編寫(xiě)。旨在為 WEB 應(yīng)用提供可擴(kuò)展的高性能數(shù)據(jù)存儲(chǔ)解決方案。

MongoDB 是一個(gè)介于關(guān)系型數(shù)據(jù)庫(kù)和非關(guān)系型數(shù)據(jù)庫(kù)之間的產(chǎn)品，是非關(guān)系型數(shù)據(jù)庫(kù)當(dāng)中功能最豐富，最像關(guān)系型數(shù)據(jù)庫(kù)的非關(guān)系型數(shù)據(jù)庫(kù)。

2.2 適用場(chǎng)景

• 需要?jiǎng)討B(tài)查詢支持
• 需要使用索引而不是 map/reduce功能
• 需要對(duì)大數(shù)據(jù)庫(kù)有性能要求
• 需要使用 CouchDB但因?yàn)閿?shù)據(jù)改變太頻繁而占滿內(nèi)存

3.Neo4j

3.1 介紹

Neo4j是一個(gè)高性能的NoSQL圖形數(shù)據(jù)庫(kù)，它將結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)在網(wǎng)絡(luò)上而不是表中。它是一個(gè)嵌入式的、基于磁盤(pán)的、具備完全的事務(wù)特性的Java持久化引擎，但是它將結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)在網(wǎng)絡(luò)(從數(shù)學(xué)角度叫做圖)上而不是表中。Neo4j也可以被看作是一個(gè)高性能的圖引擎，該引擎具有成熟數(shù)據(jù)庫(kù)的所有特性。

3.2 適用場(chǎng)景

• 適用于圖形一類數(shù)據(jù)
• 這是 Neo4j與其他NoSQL數(shù)據(jù)庫(kù)的最顯著區(qū)別
• 例如：社會(huì)關(guān)系，公共交通網(wǎng)絡(luò)，地圖及網(wǎng)絡(luò)拓譜

4.Cassandra

4.1 介紹

Apache Cassandra 是一套開(kāi)源分布式 Key-Value 存儲(chǔ)系統(tǒng)。它最初由 Facebook 開(kāi)發(fā)，用于儲(chǔ)存特別大的數(shù)據(jù)。 Cassandra 不是一個(gè)數(shù)據(jù)庫(kù)，它是一個(gè)混合型的非關(guān)系的數(shù)據(jù)庫(kù)，類似于Google 的 BigTable。Cassandra 的數(shù)據(jù)模型是基于列族（Column Family）的四維或五維模型。

4.2適用場(chǎng)景

• 銀行業(yè)，金融業(yè)
• 寫(xiě)比讀更快

5. HBase

5.1 介紹

HBase是一個(gè)分布式的、面向列的開(kāi)源數(shù)據(jù)庫(kù)，該技術(shù)來(lái)源于Google論文“Bigtable：一個(gè)結(jié)構(gòu)化數(shù)據(jù)的分布式存儲(chǔ)系統(tǒng)”。就像Bigtable利用了Google文件系統(tǒng)（File System）所提供的分布式數(shù)據(jù)存儲(chǔ)一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。它是一個(gè)適合于非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫(kù)。另一個(gè)不同的是HBase基于列的而不是基于行的模式。

5.2適用場(chǎng)景

• 對(duì)大數(shù)據(jù)進(jìn)行隨機(jī)、實(shí)時(shí)訪問(wèn)的場(chǎng)合
• 例如： Facebook消息數(shù)據(jù)庫(kù)

6.CouchDB

6.1 介紹

CouchDB 是一個(gè)開(kāi)源的面向文檔的數(shù)據(jù)庫(kù)管理系統(tǒng)，可以通過(guò) RESTful JavaScript Object Notation (JSON) API 訪問(wèn)。術(shù)語(yǔ) “Couch” 是 “Cluster Of Unreliable CommodityHardware” 的首字母縮寫(xiě)，它反映了 CouchDB 的目標(biāo)具有高度可伸縮性，提供了高可用性和高可靠性，即使運(yùn)行在容易出現(xiàn)故障的硬件上也是如此。

6.2適用場(chǎng)景

• 數(shù)據(jù)變化較少，執(zhí)行預(yù)定義查詢，進(jìn)行數(shù)據(jù)統(tǒng)計(jì)的應(yīng)用程序
• 需要提供數(shù)據(jù)版本支持的應(yīng)用程序。
• 例如： CRM、CMS系統(tǒng)。 master-master復(fù)制對(duì)于多站點(diǎn)部署是非常有用的。

NoSQL優(yōu)秀應(yīng)用實(shí)例

1. 新浪微博 - Redis

新浪微博從技術(shù)上來(lái)說(shuō)，每天用戶發(fā)表微博特別容易，這造成每天新增的數(shù)據(jù)量都是百萬(wàn)級(jí)、上千萬(wàn)級(jí)的這樣一個(gè)量。你經(jīng)常要面對(duì)的一個(gè)問(wèn)題就是增加服務(wù)器，因?yàn)橐话阋慌_(tái)MySQL服務(wù)器，它可能支撐的規(guī)模也就是幾千萬(wàn)，或者說(shuō)復(fù)雜一點(diǎn)只有幾百萬(wàn)，這樣，可能每天都要增加服務(wù)器，從而解決所你面對(duì)的這些問(wèn)題。

目前新浪微博是Redis全球最大的用戶，在新浪有200多臺(tái)物理機(jī)，400多個(gè)端口正在運(yùn)行著Redis, 有4G的數(shù)據(jù)跑在Redis上來(lái)為微博用戶提供服務(wù)。

新浪微博面臨的問(wèn)題如下：

• 數(shù)據(jù)結(jié)構(gòu)(Data Structure)需求越來(lái)越多, 但memcache中沒(méi)有, 影響開(kāi)發(fā)效率
• 隨著讀操作的量的上升，性能問(wèn)題需要解決，經(jīng)歷的過(guò)程有:

數(shù)據(jù)庫(kù)讀寫(xiě)分離(M/S)-->數(shù)據(jù)庫(kù)使用多個(gè)Slave-->增加Cache (memcache)-->轉(zhuǎn)到Redis

• 解決寫(xiě)的問(wèn)題：

水平拆分，對(duì)表的拆分，將有的用戶放在這個(gè)表，有的用戶放在另外一個(gè)表。

• 可靠性需求

Cache的"雪崩"問(wèn)題難以解決，面臨著快速恢復(fù)的挑戰(zhàn)。

• 開(kāi)發(fā)成本需求

Cache和DB的一致性維護(hù)成本越來(lái)越高，但開(kāi)發(fā)需要跟上不斷涌入的產(chǎn)品需求。且硬件成本最貴的就是數(shù)據(jù)庫(kù)層面的機(jī)器，基本上比前端的機(jī)器要貴幾倍，主要是IO密集型，很耗硬件。

• 維護(hù)性復(fù)雜

一致性維護(hù)成本越來(lái)越高

BerkeleyDB使用B樹(shù)，會(huì)一直寫(xiě)新的，內(nèi)部不會(huì)有文件重新組織；這樣會(huì)導(dǎo)致文件越來(lái)越大；大的時(shí)候需要進(jìn)行文件歸檔，歸檔的操作要定期做，這樣，就需要有一定的down time。

基于以上考慮，新浪微博選擇了Redis。

在新浪NoSQL和MySQL在大多數(shù)情況下是結(jié)合使用的，根據(jù)應(yīng)用的特點(diǎn)選擇合適的存儲(chǔ)方式。譬如：關(guān)系型數(shù)據(jù)，例如：索引使用MySQL存儲(chǔ)；非關(guān)系型數(shù)據(jù)，例如：一些K/V需求的，對(duì)并發(fā)要求比較高的放入Redis存儲(chǔ)。

新浪微博團(tuán)隊(duì)通過(guò)修改Redis源碼滿足自己的業(yè)務(wù)需求：完善它的replication機(jī)制，加入position的概念，讓維護(hù)更容易，同時(shí)failover能力也大大增強(qiáng)。改善Hashset在RDB里面的存儲(chǔ)方式，提升復(fù)雜數(shù)據(jù)類型的加載速度。

業(yè)務(wù)場(chǎng)景如下：

1. 業(yè)務(wù)使用方式：

• hash sets: 關(guān)注列表, 粉絲列表, 雙向關(guān)注列表(key-value(field), 排序)
• string(counter): 微博數(shù), 粉絲數(shù), ...(避免了select count(*) from ...)
• sort sets(自動(dòng)排序): TopN, 熱門(mén)微博等, 自動(dòng)排序
• lists(queue): push/sub提醒,...
• 上述四種, 從精細(xì)化控制方面，hash sets和string(counter)推薦使用, sort sets和lists(queue)不推薦使用
• 還可通過(guò)二次開(kāi)發(fā)，進(jìn)行精簡(jiǎn)。比如: 存儲(chǔ)字符改為存儲(chǔ)整形, 16億數(shù)據(jù),只需要16G內(nèi)存
• 存儲(chǔ)類型保存在3種以內(nèi)，建議不要超過(guò)3種；
• 將memcache +mysql 替換為Redis：
• Redis作為存儲(chǔ)并提供查詢，后臺(tái)不再使用mysql，解決數(shù)據(jù)多份之間的一致性問(wèn)題；