NoSql 簡述

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

NoSQL，泛指非關系型的資料庫。随着網際網路web2.0網站的興起，傳統的關系資料庫在應付web2.0網站，特别是超大規模和高并發的SNS類型的web2.0純動态網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的資料庫則由于其本身的特點得到了非常迅速的發展。NoSQL資料庫的産生就是為了解決大規模資料集合多重資料種類帶來的挑戰，尤其是大資料應用難題。

傳統關系資料庫的瓶頸

傳統的關系資料庫具有不錯的性能，高穩定型，久經曆史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在網際網路領域，MySQL成為了絕對靠前的王者，毫不誇張的說，MySQL為網際網路的發展做出了卓越的貢獻。

在 網際網路，大部分的MySQL都應該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那麼很可能你的MySQL設計得有性能問題，需要優 化了。大資料量高并發環境下的MySQL應用開發越來越複雜，也越來越具有技術挑戰性。分表分庫的規則把握都是需要經驗的。雖然有像淘寶這樣技術實力強大 的公司開發了透明的中間件層來屏蔽開發者的複雜性，但是避免不了整個架構的複雜性。分庫分表的子庫到一定階段又面臨擴充問題。還有就是需求的變更，可能又 需要一種新的分庫方式。

MySQL資料庫也經常存儲一些大文本字段，導緻資料庫表非常的大，在做資料庫恢複的時候就導緻非常的慢，不容易快速恢複資料庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些資料從MySQL省去，MySQL将變得非常的小。

随着網際網路的不斷發展，各種類型的應用層出不窮，是以導緻在這個雲計算的時代，對技術提出了更多的需求，主要展現在下面這四個方面：

• 低延遲的讀寫速度：應用快速地反應能極大地提升使用者的滿意度;
• 支撐海量的資料和流量：對于搜尋這樣大型應用而言，需要利用PB級别的資料和能應對百萬級的流量;
• 大規模叢集的管理：系統管理者希望分布式應用能更簡單的部署和管理;
• 龐大營運成本的考量：IT經理們希望在硬體成本、軟體成本和人力成本能夠有大幅度地降低;

SQL 與 NOSQL 的優缺點

SQL優點

• 事務處理—保持資料的一緻性；
• 由于以标準化為前提，資料更新的開銷很小（相同的字段基本上隻有一處）；
• 可以進行Join等複雜查詢。

SQL缺點

• 擴充困難：由于存在類似Join這樣多表查詢機制，使得資料庫在擴充方面很艱難;
• 讀寫慢：這種情況主要發生在資料量達到一定規模時由于關系型資料庫的系統邏輯非常複雜，使得其非常容易發生死鎖等的并發問題，是以導緻其讀寫速度下滑非常嚴重;
• 成本高：企業級資料庫的License價格很驚人，并且随着系統的規模，而不斷上升;
• 有限的支撐容量：現有關系型解決方案還無法支撐Google這樣海量的資料存儲;

NoSql優點

• 易擴充 : NoSQL資料庫種類繁多，但是一個共同的特點都是去掉關系資料庫的關系型特性。資料之間無關系，這樣就非常容易擴充。也無形之間，在架構的層面上帶來了可擴充的能力。
• 大資料量，高性能 : NoSQL 資料庫都具有非常高的讀寫性能，尤其在大資料量下，同樣表現優秀。這得益于它的無關系性，資料庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的互動頻繁的應用，Cache性能不高。而NoSQL的 Cache是記錄級的，是一種細粒度的Cache，是以NoSQL在這個層面上來說就要性能高很多了。
• 靈活的資料模型 : NoSQL無需事先為要存儲的資料建立字段，随時可以存儲自定義的資料格式。而在關系資料庫裡，增删字段是一件非常麻煩的事情。如果是非常大資料量的表，增加字段簡直就是一個噩夢。這點在大資料量的web2.0時代尤其明顯。
• 高可用 : NoSQL在不太影響性能的情況，就可以友善的實作高可用的架構。比如Cassandra，HBase模型，通過複制模型也能實作高可用。

NoSql缺點

• 不提供對SQL的支援：如果不支援SQL這樣的工業标準，将會對使用者産生一定的學習和應用遷移成本;
• 支援的特性不夠豐富：現有産品所提供的功能都比較有限，大多數NoSQL資料庫都不支援事務，也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等;
• 現有産品的不夠成熟：大多數産品都還處于初創期，和關系型資料庫幾十年的完善不可同日而語;

Nosql的應用場景

NoSQL作為鏡像

這種架構在原有基于MySQL資料庫的架構上增加了一層輔助的NoSQL存儲，代碼量不大，技術難度小，卻在可擴充性和性能上起到了非常大的作用。隻需要程式在寫入MySQL資料庫後，同時寫入到NoSQL資料庫，讓MySQL和NoSQL擁有相同的鏡像資料，在某些可以根據主鍵查詢的地方，使用高效的NoSQL資料庫查詢，這樣就節省了MySQL的查詢，用NoSQL的高性能來抵擋這些查詢。

NoSQL為鏡像（同步模式）

這種不通過程式代碼，而是通過MySQL把資料同步到NoSQL中，這種模式是上面一種的變體，是一種對寫入透明但是具有更高技術難度一種模式。這種模式适用于現有的比較複雜的老系統，通過修改代碼不易實作，可能引起新的問題。同時也适用于需要把資料同步到多種類型的存儲中。

MySQL和NoSQL組合

MySQL中隻存儲需要查詢的小字段，NoSQL存儲所有資料。這種架構模式把MySQL和NoSQL的作用進行了融合，各司其職，讓MySQL專門負責處理擅長的關系存儲，NoSQL作為資料的存儲。簡單的說，就是在mysql中存儲1對多/多對多的映射關系，然後根據關系查詢出主鍵，再查nosql。或者在nosql直接維護映射關系，實作範圍查詢。它有以下優點：

• 節省MySQL的IO開銷。由于MySQL隻存儲需要查詢的小字段，不再負責存儲大文本字段，這樣就可以節省MySQL存儲的空間開銷，進而節省MySQL的磁盤IO。我們曾經通過這種優化，把MySQL一個40G的表縮減到幾百M。
• 提高MySQl Query Cache緩存命中率。我們知道query cache緩存失效是表級的，在MySQL表一旦被更新就會失效，經過這種字段的分離，更新的字段如果不是存儲在MySQL中，那麼對query cache就沒有任何影響。而NoSQL的Cache往往都是行級别的，隻對更新的記錄的緩存失效。
• 提升MySQL主從同步效率。由于MySQL存儲空間的減小，同步的資料記錄也減小了，而部分資料的更新落在NoSQL而不是MySQL，這樣也減少了MySQL資料需要同步的次數。
• 提高MySQL資料備份和恢複的速度。由于MySQL資料庫存儲的資料的減小，很容易看到資料備份和恢複的速度也将極大的提高。

純NoSQL架構

在一些資料庫結構經常變化，資料結構不定的系統中，就非常适合使用NoSQL來存儲。比如監控系統中的監控資訊的存儲，可能每種類型的監控資訊都不太一樣。這樣可以避免經常對MySQL進行表結構調整，增加字段帶來的性能問題。

這種架構的缺點就是資料直接存儲在NoSQL中，不能做關系資料庫的複雜查詢，如果由于需求變更，需要進行某些查詢，可能無法滿足，是以采用這種架構的時候需要确認未來是否會進行複雜關系查詢以及如何應對。

以NoSQL為資料源的架構

純NoSQL的架構雖然結構簡單，易于開發，但是在應付需求的變更、穩定性和可靠性上，總是給開發人員一種風險難于控制的感覺。為了降低風險，系統的功能不局限在NoSQL的簡單功能上，我們可以使用以NoSQL為資料源的架構。

在這種架構中，應用程式隻負責把資料直接寫入到NoSQL資料庫就OK，然後通過NoSQL的複制協定，把NoSQL資料的每次寫入，更新，删除操作都複制到MySQL資料庫中。同 時，也可以通過複制協定把資料同步複制到全文檢索實作強大的檢索功能。在海量資料下面，我們也可以根據不同的規則，把資料同步複制到設計好的分表分庫的 MySQL中。這種架構：

• 非常靈活。可以非常友善的線上上系統運作過程中進行資料的調整，比如調整分庫分表的規則、要添加一種新的存儲類型等等。
• 操作簡單。隻需要寫入NoSQL資料庫源，應用程式就不用管了。需要增加存儲類型或者調整存儲規則的時候，隻需要增加同步的資料存儲，調整同步規則即可，無需更改應用程式的代碼。
• 性能高。資料的寫入和更新直接操作NoSQL，實作了寫的高性能。而通過同步協定，把資料複制到各種适合查詢類型的存儲中（按照業務邏輯區分不同的存儲），能實作查詢的高性能，不像以前MySQL一種資料庫就全包了。或者就一個表負責跟這個表相關的所有的查詢，現在可以把一個表的資料複制到各種存儲，讓各種存儲用自己的長處來對外服務。
• 易擴充。開發人員隻需要關心寫入NoSQL資料庫。資料的擴充可以友善的在後端由複制協定根據規則來完成。

NoSQL 資料庫分類

類型	部分代表	特點
列存儲	Hbase Cassandra Hypertable	顧名思義，是按列存儲資料的。最大的特點是友善存儲結構化和半結構化資料，友善做資料壓縮，對針對某一列或者某幾列的查詢有非常大的IO優勢。
文檔存儲	MongoDB CouchDB	文檔存儲一般用類似json的格式存儲，存儲的内容是文檔型的。這樣也就有有機會對某些字段建立索引，實作關系資料庫的某些功能。
key-value存儲	Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis	可以通過key快速查詢到其value。一般來說，存儲不管value的格式，照單全收。（Redis包含了其他功能）
圖存儲	Neo4J FlockDB	圖形關系的最佳存儲。使用傳統關系資料庫來解決的話性能低下，而且設計使用不友善。
對象存儲	db4o Versant	通過類似面向對象語言的文法操作資料庫，通過對象的方式存取資料。

鍵值(Key-Value)存儲資料庫

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

列存儲資料庫

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

文檔型資料庫

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

圖形(Graph)資料庫

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

8 種 NoSQL 資料庫系統對比

名稱	特性	場景	例如
CouchDB	-所用語言： Erlang -特點：DB一緻性，易于使用 -使用許可： Apache -協定：HTTP/REST - 雙向資料複制 - 持續進行或臨時處理 -處理時帶沖突檢查是以，采用的是master-master複制 -MVCC – 寫操作不阻塞讀操作 -可儲存檔案之前的版本 -Crash-only（可靠的）設計 -需要不時地進行資料壓縮 -視圖：嵌入式 映射/減少 -格式化視圖：清單顯示 -支援進行伺服器端文檔驗證 -支援認證 -根據變化實時更新 -支援附件處理是以， CouchApps（獨立的 js應用程式） -需要 jQuery程式庫	适用于資料變化較少， 執行預定義查詢，進 行資料統計的應用程式。 适用于需要提供資料版本 支援的應用程式。	CRM、CMS系統。 master-master複制 對于多站點部署是 非常有用的。
Redis	-所用語言：C/C++ -特點：運作異常快 -使用許可： BSD -協定：類 Telnet -有硬碟存儲支援的記憶體資料庫,但自2.0版本以後可以将資料交換到硬碟（注意， 2.4以後版本不支援該特性！） -Master-slave複制 -雖然采用簡單資料或以鍵值索引的哈希表，但也支援複雜操作，例如 ZREVRANGEBYSCORE。 -INCR & co （适合計算極限值或統計資料） -支援 sets（同時也支援 union/diff/inter） -支援清單（同時也支援隊列；阻塞式 pop操作） -支援哈希表（帶有多個域的對象） -支援排序 sets（高得分表，适用于範圍查詢） -Redis支援事務 -支援将資料設定成過期資料（類似快速緩沖區設計） -Pub/Sub允許使用者實作消息機制	适用于資料變化快且 資料庫大小可遇見 （适合記憶體容量） 的應用程式。	股票價格、 資料分析、 實時資料搜集、 實時通訊。
MongoDB	-所用語言：C++ -特點：保留了SQL一些友好的特性（查詢，索引）。 -使用許可： AGPL（發起者： Apache）協定： Custom, binary（ BSON） -Master/slave複制（支援自動錯誤恢複，使用 sets 複制） -内建分片機制 -支援 javascript表達式查詢 -可在伺服器端執行任意的 javascript函數 -update-in-place支援比CouchDB更好 -在資料存儲時采用記憶體到檔案映射 -對性能的關注超過對功能的要求 -建議最好打開日志功能（參數 –journal） -在32位作業系統上，資料庫大小限制在約2.5Gb -空資料庫大約占 192Mb -采用 GridFS存儲大資料或中繼資料（不是真正的檔案系統）	适用于需要動态查詢支援； 需要使用索引而不是 map/reduce功能； 需要對大資料庫有性能要求； 需要使用 CouchDB, 但因為資料改變太頻繁而占滿記憶體的應用程式。	你本打算采用 MySQL或 PostgreSQL， 但因為它們本身 自帶的預定義欄 讓你望而卻步。
Riak	-所用語言：Erlang和C，以及一些Javascript -特點：具備容錯能力 -使用許可： Apache協定： HTTP/REST或者 custom binary -可調節的分發及複制(N, R, W) -用 JavaScript or Erlang在操作前或操作後進行驗證和安全支援。 -使用JavaScript或Erlang進行 Map/reduce -連接配接及連接配接周遊：可作為圖形資料庫使用 -索引：輸入中繼資料進行搜尋（1.0版本即将支援） -大資料對象支援（ Luwak） -提供“開源”和“企業”兩個版本 -全文本搜尋，索引，通過 Riak搜尋伺服器查詢（ beta版） -支援Masterless多站點複制及商業許可的 SNMP監控	适用于想使用類似 Cassandra（類似 Dynamo）資料庫 但無法處理 bloat 及複雜性的情況。 适用于你打算做多 站點複制，但又需 要對單個站點的 擴充性，可用性 及出錯處理有要求的情況。	銷售資料搜集， 工廠控制系統； 對當機時間有嚴格要求； 可以作為易于更新 的 web伺服器使用。
Membase	-所用語言： Erlang和C -特點：相容 Memcache，但同時兼具持久化和支援叢集 -使用許可： Apache 2.0 -協定：分布式緩存及擴充 -非常快速（200k+/秒），通過鍵值索引資料 -可持久化存儲到硬碟 -所有節點都是唯一的（ master-master複制） -在記憶體中同樣支援類似分布式緩存的緩存單元 -寫資料時通過去除重複資料來減少 IO -提供非常好的叢集管理 web界面 -更新軟體時軟無需停止資料庫服務 -支援連接配接池和多路複用的連接配接代理	适用于需要低延遲資料通路， 高并發支援以及高可用性的 應用程式	低延遲資料通路, 比如以廣告為 目标的應用， 高并發的 web 應用. 比如網絡遊戲 （例如 Zynga）
Neo4j	-所用語言： Java -特點：基于關系的圖形資料庫 -使用許可： GPL，其中一些特性使用 AGPL/商業許可 -協定： HTTP/REST（或嵌入在 Java中） -可獨立使用或嵌入到 Java應用程式 -圖形的節點和邊都可以帶有中繼資料 -很好的自帶web管理功能 -使用多種算法支援路徑搜尋 -使用鍵值和關系進行索引 -為讀操作進行優化 -支援事務（用 Java api） -使用 Gremlin圖形周遊語言 -支援 Groovy腳本 -支援線上備份，進階監控及高可靠性支援使用 AGPL/商業許可	适用于圖形一類資料。 這是 Neo4j與其他nosql 資料庫的最顯著差別	社會關系， 公共交通網絡， 地圖及網絡拓譜
Cassandra	-所用語言： Java -特點：對大型表格和 Dynamo支援得最好 -使用許可： Apache -協定： Custom, binary (節約型) -可調節的分發及複制(N, R, W) -支援以某個範圍的鍵值通過列查詢 -類似大表格的功能：列，某個特性的列集合 -寫操作比讀操作更快 -基于 Apache分布式平台盡可能地 Map/reduce -本身的臃腫和複雜性，也因為 Java的問題（配置，出現異常，等等）	當使用寫操作多過讀操作 （記錄日志）.如果每個 系統組建都必須用 Java編寫	銀行業，金融業 （雖然對于金融 交易不是必須的， 但這些産業對 資料庫的要求會 比它們更大）寫 比讀更快，是以 一個自然的特性 就是實時資料分析
HBase	-所用語言： Java -特點：支援數十億行X上百萬列 -使用許可： Apache -協定：HTTP/REST （支援 Thrift，見編注4） -在 BigTable之後模組化 -采用分布式架構 Map/reduce -對實時查詢進行優化 -高性能 Thrift網關 -通過在server端掃描及過濾實作對查詢操作預判 -支援 XML, Protobuf, 和binary的HTTP -Cascading, hive, and pig source and sink modules -基于 Jruby（ JIRB）的shell -對配置改變和較小的更新都會重新復原 -不會出現單點故障 -堪比MySQL的随機通路性能	需要對大資料進行随機、實時通路的場合。	Facebook消息 資料庫（更多通用的用例即将出現）

參考資料

• NOSQL資料庫 : http://www.oschina.net/project/tag/235/nosql
• NoSQL專題講座 : https://wenku.baidu.com/view/38446b51bed5b9f3f90f1caa.html
• 主流 NoSQL 資料庫的對比 : http://blog.jobbole.com/100934/