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

現代計算系統每天在網絡上都會產生龐大的數據量。這些數據有很大一部分是由關系型數據庫管理系統（RDBMSs）來處理，其嚴謹成熟的數學理論基礎使得數據建模和應用程序編程更加簡單。

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

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

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

NoSQL理論基礎

1.關系型數據庫理論 - ACID

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

• A – Atomicity – 原子性

一個事務（transaction）中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有被執行過一樣。

• C – Consistency – 一致性

在事務開始之前和事務結束以后，數據庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設規則，這包含資料的精確度、串聯性以及后續數據庫可以自發性地完成預定的工作。

• I – Isolation – 隔離性

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

• D – Durability – 持久性

事務處理結束后，對數據的修改就是永久的，即便系統故障也不會丟失。

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

2.分布式系統理論

2.1 分布式系統介紹

分布式系統的核心理念是讓多臺服務器協同工作，完成單臺服務器無法處理的任務，尤其是高并發或者大數據量的任務。分布式是NoSQL數據庫的必要條件。

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

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

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

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

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

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

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

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

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

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

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

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

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

• A – Availability – 可用性

可用性是指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。

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

好的可用性主要是指系統能夠很好的為用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。在通常情況下，可用性與分布式數據冗余、負載均衡等有著很大的關聯。

• P – Partition tolerance – 分區容錯性

分區容錯性是指“the system continues to operate despite arbitrary message loss or failureof part of the system”，即分布式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

分區容錯性和擴展性緊密相關。在分布式應用中，可能因為一些分布式的原因導致系統無法正常運轉。好的分區容錯性要求能夠使應用雖然是一個分布式系統，但看上去卻好像是一個可以運轉正常的整體。比如現在的分布式系統中有某一個或者幾個機器宕掉了，其它剩下的機器還能夠正常運轉滿足系統需求，或者是機器之間有網絡異常，將分布式系統分隔成未獨立的幾個部分，各個部分還能維持分布式系統的運作，這樣就具有好的分區容錯性。

• CA without P

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

• CP without A

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

• AP without C

要高可用并允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性?，F在眾多的NoSQL都屬于此類。

CAP理論定義了分布式存儲的根本問題，但并沒有指出一致性和可用性之間到底應該如何權衡。于是出現了BASE理論，給出了權衡A與C的一種可行方案。

2.3 權衡一致性與可用性 - BASE理論

Base = Basically Available + Soft state + Eventuallyconsistent 基本可用性+軟狀態+最終一致性，由eBay架構師DanPritchett提出。Base是對CAP中一致性A和可用性C權衡的結果，源于提出者自己在大規模分布式系統上實踐的總結。核心思想是無法做到強一致性，但每個應用都可以根據自身的特點，采用適當方式達到最終一致性。

• BA - Basically Available - 基本可用

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

• S – Soft State - 軟狀態

允許系統數據存在中間狀態，但不會影響到系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步時存在延時。

• E - Eventually Consistent - 最終一致性

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

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

3.分布式存儲算法

3.1一致性算法 – Paxos

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

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

3.2分區（Partitioning）

原來所有的數據都是在一個數據庫上的，網絡IO及文件IO都集中在一個數據庫上的，因此CPU、內存、文件IO、網絡IO都可能會成為系統瓶頸。而分區的方案就是把某一個表或某幾個相關的表的數據放在一個獨立的數據庫上，這樣就可以把CPU、內存、文件IO、網絡IO分解到多個機器中，從而提升系統處理能力。

3.3分片（Replication）

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

3.4一致性哈希（Consistent Hashing）

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

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

4.NoSQL的優點/缺點

優點

缺點

1.易擴展

2.高性能

3.數據類型靈活

4.高可用

1.沒有標準

2.沒有存儲過程

3.不支持sql

4.功能不夠完善

4.1優點

• 易擴展

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

• 大數據量，高性能

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

• 靈活的數據模型

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

• 高可用

NoSQL在不太影響性能的情況下，就可以方便地實現高可用的架構。比如Cassandra、HBase模型，通過復制模型也能實現高可用。

4.1缺點

• 沒有標準

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

• 沒有存儲過程

NoSQL數據庫中大多沒有存儲過程。

• 不支持SQL

NoSQL大多不提供對SQL的支持：如果不支持SQL這樣的工業標準，將會對用戶產生一定的學習和應用遷移上的成本。

• 支持的特性不夠豐富，產品不夠成熟

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

NoSQL與SQL的對比

RDBMS

NoSQL

模式

預定義的模式

沒有預定義的模式

查詢語言

結構化查詢語言（SQL）

沒有聲明性查詢語言

一致性

嚴格的一致性

最終一致性

事務

支持

不支持

理論基礎

ACID

CAP, BASE

擴展

縱向擴展

橫向擴展(分布式)

NoSQL數據庫的分類

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

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

E. g:

• TokyoCabinet/Tyrant
• Redis
• Voldemort
• OracleBDB
• 列存儲數據庫

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

E. g:

• Cassandra
• HBase
• Riak
• 文檔型數據庫

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

E. g:

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

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

E. g:

• Neo4J
• InfoGrid
• InfiniteGraph

主流NoSQL數據庫介紹及其適用場景

1. Redis

1.1 介紹

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

1.2 適用場景

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

2. MongoDB

2.1 介紹

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

MongoDB 是一個介于關系型數據庫和非關系型數據庫之間的產品，是非關系型數據庫當中功能最豐富，最像關系型數據庫的非關系型數據庫。

2.2 適用場景

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

3.Neo4j

3.1 介紹

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

3.2 適用場景

• 適用于圖形一類數據
• 這是 Neo4j與其他NoSQL數據庫的最顯著區別
• 例如：社會關系，公共交通網絡，地圖及網絡拓譜

4.Cassandra

4.1 介紹

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

4.2適用場景

• 銀行業，金融業
• 寫比讀更快

5. HBase

5.1 介紹

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

5.2適用場景

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

6.CouchDB

6.1 介紹

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

6.2適用場景

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

NoSQL優秀應用實例

1. 新浪微博 - Redis

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

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

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

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

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

• 解決寫的問題：

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

• 可靠性需求

Cache的"雪崩"問題難以解決，面臨著快速恢復的挑戰。

• 開發成本需求

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

• 維護性復雜

一致性維護成本越來越高

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

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

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

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

業務場景如下：

1. 業務使用方式：

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