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

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

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

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

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

NoSQL理論基礎(chǔ)

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

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

• A – Atomicity – 原子性

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

• C – Consistency – 一致性

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

• I – Isolation – 隔離性

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

• D – Durability – 持久性

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

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

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

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

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

分布式系統(tǒng)由獨立的服務(wù)器通過網(wǎng)絡(luò)松散耦合組成的。每個服務(wù)器都是一臺獨立的PC機，服務(wù)器之間通過內(nèi)部網(wǎng)絡(luò)連接，內(nèi)部網(wǎng)絡(luò)速度一般比較快。因為分布式集群里的服務(wù)器是通過內(nèi)部網(wǎng)絡(luò)松散耦合，各節(jié)點之間的通訊有一定的網(wǎng)絡(luò)開銷，因此分布式系統(tǒng)在設(shè)計上盡可能減少節(jié)點間通訊。此外，因為網(wǎng)絡(luò)傳輸瓶頸，單個節(jié)點的性能高低對分布式系統(tǒng)整體性能影響不大。比如，對分布式應(yīng)用來說，采用不同編程語言開發(fā)帶來的單個應(yīng)用服務(wù)的性能差異，跟網(wǎng)絡(luò)開銷比起來都可以忽略不計。

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

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

2.2 分布式存儲的問題 – CAP理論

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

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

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

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

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

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

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

從服務(wù)端來看，則是更新如何復(fù)制分布到整個系統(tǒng)，以保證數(shù)據(jù)最終一致。一致性是因為有并發(fā)讀寫才有的問題，因此在理解一致性的問題時，一定要注意結(jié)合考慮并發(fā)讀寫的場景。

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

• A – Availability – 可用性

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

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

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

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

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

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

• CA without P

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

• CP without A

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

• AP without C

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

CAP理論定義了分布式存儲的根本問題，但并沒有指出一致性和可用性之間到底應(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是對CAP中一致性A和可用性C權(quán)衡的結(jié)果，源于提出者自己在大規(guī)模分布式系統(tǒng)上實踐的總結(jié)。核心思想是無法做到強一致性，但每個應(yīng)用都可以根據(jù)自身的特點，采用適當方式達到最終一致性。

• BA - Basically Available - 基本可用

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

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

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

• E - Eventually Consistent - 最終一致性

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

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

3.分布式存儲算法

3.1一致性算法 – Paxos

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

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

3.2分區(qū)（Partitioning）

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

3.3分片（Replication）

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

3.4一致性哈希（Consistent Hashing）

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

一致性哈?；窘鉀Q了在P2P環(huán)境中最為關(guān)鍵的問題——如何在動態(tài)的網(wǎng)絡(luò)拓撲中分布存儲和路由。每個節(jié)點僅需維護少量相鄰節(jié)點的信息，并且在節(jié)點加入/退出系統(tǒng)時，僅有相關(guān)的少量節(jié)點參與到拓撲的維護中。所有這一切使得一致性哈希成為第一個實用的DHT算法。

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

優(yōu)點

缺點

1.易擴展

2.高性能

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

4.高可用

1.沒有標準

2.沒有存儲過程

3.不支持sql

4.功能不夠完善

4.1優(yōu)點

• 易擴展

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

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

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

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

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

• 高可用

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

4.1缺點

• 沒有標準

沒有對NoSQL數(shù)據(jù)庫定義的標準，所以沒有兩個NoSQL數(shù)據(jù)庫是平等的。

• 沒有存儲過程

NoSQL數(shù)據(jù)庫中大多沒有存儲過程。

• 不支持SQL

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

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

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

NoSQL與SQL的對比

RDBMS

NoSQL

模式

預(yù)定義的模式

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

查詢語言

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

沒有聲明性查詢語言

一致性

嚴格的一致性

最終一致性

事務(wù)

支持

不支持

理論基礎(chǔ)

ACID

CAP, BASE

擴展

縱向擴展

橫向擴展(分布式)

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

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

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

E. g:

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

這部分數(shù)據(jù)庫通常是用來應(yīng)對分布式存儲的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。

E. g:

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

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

E. g:

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

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

E. g:

• Neo4J
• InfoGrid
• InfiniteGraph

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

1. Redis

1.1 介紹

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

1.2 適用場景

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

2. MongoDB

2.1 介紹

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

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

2.2 適用場景

• 需要動態(tài)查詢支持
• 需要使用索引而不是 map/reduce功能
• 需要對大數(shù)據(jù)庫有性能要求
• 需要使用 CouchDB但因為數(shù)據(jù)改變太頻繁而占滿內(nèi)存

3.Neo4j

3.1 介紹

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

3.2 適用場景

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

4.Cassandra

4.1 介紹

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

4.2適用場景

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

5. HBase

5.1 介紹

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

5.2適用場景

• 對大數(shù)據(jù)進行隨機、實時訪問的場合
• 例如： Facebook消息數(shù)據(jù)庫

6.CouchDB

6.1 介紹

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

6.2適用場景

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

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

1. 新浪微博 - Redis

新浪微博從技術(shù)上來說，每天用戶發(fā)表微博特別容易，這造成每天新增的數(shù)據(jù)量都是百萬級、上千萬級的這樣一個量。你經(jīng)常要面對的一個問題就是增加服務(wù)器，因為一般一臺MySQL服務(wù)器，它可能支撐的規(guī)模也就是幾千萬，或者說復(fù)雜一點只有幾百萬，這樣，可能每天都要增加服務(wù)器，從而解決所你面對的這些問題。

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

新浪微博面臨的問題如下：

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

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

• 解決寫的問題：

水平拆分，對表的拆分，將有的用戶放在這個表，有的用戶放在另外一個表。

• 可靠性需求

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

• 開發(fā)成本需求

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

• 維護性復(fù)雜

一致性維護成本越來越高

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

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

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

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

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

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

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