雲計算背後的祕密：NoSQL誕生的緣由和優缺點

轉載收藏一篇對nosql講解的比較全面的文章：http://blog.csdn.net/xlgen157387/article/details/47908797

這篇文章將和你們聊聊爲何NoSQL會在關係型數據庫已經很是普及的狀況下異軍突起?

誕生的緣由

隨着互聯網的不斷髮展，各類類型的應用層出不窮，因此致使在這個雲計算的時代，對技術提出了更多的需求，主要體如今下面這四個方面： 
1. 低延遲的讀寫速度：應用快速地反應能極大地提高用戶的滿意度; 
2. 支撐海量的數據和流量：對於搜索這樣大型應用而言，須要利用PB級別的數據和能應對百萬級的流量; 
3. 大規模集羣的管理：系統管理員但願分佈式應用能更簡單的部署和管理;

4.龐大運營成本的考量：IT經理們但願在硬件成本、軟件成本和人力成本可以有大幅度地下降;

目前世界上主流的存儲系統大部分仍是採用了關係型數據庫，其主要有一下優勢：

1.事務處理—保持數據的一致性；

2.因爲以標準化爲前提，數據更新的開銷很小（相同的字段基本上只有一處）；

3.能夠進行Join等複雜查詢。

雖然關係型數據庫已經在業界的數據存儲方面佔據不可動搖的地位，可是因爲其天生的幾個限制，使其很難知足上面這幾個需求： 
1. 擴展困難：因爲存在相似Join這樣多表查詢機制，使得數據庫在擴展方面很艱難; 
2. 讀寫慢：這種狀況主要發生在數據量達到必定規模時因爲關係型數據庫的系統邏輯很是複雜，使得其很是容易發生死鎖等的併發問題，因此致使其讀寫速度下滑很是嚴重; 
3. 成本高：企業級數據庫的License價格很驚人，而且隨着系統的規模，而不斷上升; 
4. 有限的支撐容量：現有關係型解決方案還沒法支撐Google這樣海量的數據存儲; 
業界爲了解決上面提到的幾個需求，推出了多款新類型的數據庫，而且因爲它們在設計上和傳統的NoSQL數據庫相比有很大的不一樣，因此被統稱爲「NoSQL」系列數據庫。總的來講，在設計上，它們很是關注對數據高併發地讀寫和對海量數據的存儲等，與關係型數據庫相比，它們在架構和數據模型方量面作了「減法」，而在擴展和併發等方面作了「加法」。如今主流的NoSQL數據庫有BigTable、Hbase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。接下來，將關注NoSQL數據庫到底存在哪些優缺點。

優缺點

在優點方面，主要體如今下面這三點： 
1. 簡單的擴展：典型例子是Cassandra，因爲其架構是相似於經典的P2P，因此能經過輕鬆地添加新的節點來擴展這個集羣; 
2. 快速的讀寫：主要例子有Redis，因爲其邏輯簡單，並且純內存操做，使得其性能很是出色，單節點每秒能夠處理超過10萬次讀寫操做; 
3. 低廉的成本：這是大多數分佈式數據庫共有的特色，由於主要都是開源軟件，沒有昂貴的License成本; 
4. 
但瑕不掩瑜，NoSQL數據庫還存在着不少的不足，常見主要有下面這幾個： 
1. 不提供對SQL的支持：若是不支持SQL這樣的工業標準，將會對用戶產生必定的學習和應用遷移成本; 
2. 支持的特性不夠豐富：現有產品所提供的功能都比較有限，大多數NoSQL數據庫都不支持事務，也不像MS SQL Server和Oracle那樣能提供各類附加功能，好比BI和報表等; 
3. 現有產品的不夠成熟：大多數產品都還處於初創期，和關係型數據庫幾十年的完善不可同日而語; 
上面NoSQL產品的優缺點都是些比較共通的，在實際狀況下，每一個產品都會根據本身所聽從的數據模型和CAP理念而有所不一樣，接下來，將給你們介紹NoSQL兩個最重要的概念：數據模型和CAP理念，並在本文最後，對主流的NoSQL數據庫進行分類。

Naresh Kumar是位軟件工程師與熱情的博主，對於編程與新事物擁有極大的興趣，很是樂於與其餘開發者和程序員分享技術上的研究成果。近日，Naresh撰文比較了NoSQL與RDBMS，並詳細介紹了他們各自的特色與適用的場景。

NoSQL並非關係型數據庫管理系統，本文將會介紹NoSQL數據庫與關係型數據庫之間的差異，同時還會討論在何種場景下應該使用NoSQL，何種場景下不該該使用。因爲NoSQL仍是個相對較新的技術，所以它還面臨着不少挑戰。

時至今日，互聯網上有數以億計的用戶。大數據與雲計算已經成爲不少主要的互聯網應用都在使用或是準備使用的技術，這是由於互聯網用戶天天都在不斷增加，數據也變得愈來愈複雜，並且有不少非結構化的數據存在，這是很難經過傳統的關係型數據庫管理系統來處理的。NoSQL技術則能比較好地解決這個問題，它主要用於非結構化的大數據與雲計算上。從這個角度來看，NoSQL是一種全新的數據庫思惟方式。

爲什麼要使用NoSQL數據庫？

1.NoSQL具備靈活的數據模型，能夠處理非結構化/半結構化的大數據

如今，咱們能夠經過Facebook、D&B等第三方輕鬆得到與訪問數據，如我的用戶信息、地理位置數據、社交圖譜、用戶產生的內容、機器日誌數據以及傳感器生成的數據等。對這些數據的使用正在快速改變着通訊、購物、廣告、娛樂以及關係管理的特質。沒有使用這些數據的應用很快就會被用戶所遺忘。開發者但願使用很是靈活的數據庫，可以輕鬆容納新的數據類型，而且不會被第三方數據提供商內容結構的變化所累。不少新數據都是非結構化或是半結構化的，所以開發者還須要可以高效存儲這種數據的數據庫。但遺憾的是，關係型數據庫所使用的定義嚴格、基於模式的方式是沒法快速容納新的數據類型的，對於非結構化或是半結構化的數據更是無能爲力。NoSQL提供的數據模型則能很好地知足這種需求。不少應用都會從這種非結構化數據模型中獲益，好比說CRM、ERP、BPM等等，他們能夠經過這種靈活性存儲數據而無需修改表或是建立更多的列。這些數據庫也很是適合於建立原型或是快速應用，由於這種靈活性使得新特性的開發變得很是容易。

2.NoSQL很容易實現可伸縮性（向上擴展與水平擴展）

若是有不少用戶在頻繁且併發地使用你的應用，那麼你就須要考慮可伸縮的數據庫技術而非傳統的RDBMS了。對於關係型技術來講，不少應用開發者會發現動態的可伸縮性是難以實現的，這時就應該考慮切換到NoSQL數據庫上。對於雲應用來講，關係型數據庫一開始是廣泛的選擇。然而，在使用過程當中卻遇到了愈來愈多的問題，緣由就在於他們是中心化的，向上擴展而非水平擴展的。這使得他們不適合於那些須要簡單且動態可伸縮性的應用。NoSQL數據庫從一開始就是分佈式、水平擴展的，所以很是適合於互聯網應用分佈式的特性。

在三層互聯網架構的Web/應用層上，多年來向上擴展已經成爲默認的擴展方式了。隨着應用使用人數的激增，咱們須要添加更多的服務器，性能則是經過負載均衡來實現的，這時的代價與用戶數量成線性比例關係。在NoSQL數據庫以前，數據庫層的默認擴展方式就是向上擴展。爲了支持更多的併發用戶以及存儲更多的數據，你須要愈來愈好的服務器，更好的CPU、更多的內存、更大的磁盤來維護全部表。然而，好的服務器意味着更加複雜、私有、而且也更加昂貴。這與Web/應用層所使用的便宜的硬件造成了鮮明的對比。

3.動態模式

關係型數據庫須要在添加數據前先定義好模式。好比說，你須要存儲客戶的電話號碼、姓名、地址、城市與州等信息，SQL數據庫須要提早知曉你要存的是什麼。這對於敏捷開發模式來講是場災難，由於每次完成新特性時，數據庫的模式一般都須要改變。所以，若是在開發過程當中想將客戶喜歡的條目加到數據庫中，那就得向表中添加這一列才行，而後要作的就是將整個數據庫遷移到新的模式上。

4.自動分片

因爲是結構化的，關係型數據庫一般會垂直擴展，單臺服務器要持有整個數據庫來確保可靠性與數據的持續可用性。這樣作的代價就是很是昂貴、擴展受到限制，而且數據庫基礎設施會成爲失敗點。這個問題的解決方案就是水平擴展，添加服務器而不是爲單臺服務器增長更多的能力。NoSQL數據庫一般都支持自動分片，這意味着他們本質上就會自動在多臺服務器上分發數據，應用甚至都不知道這些事情。數據與查詢負載會自動在多臺服務器上作到平衡，當某臺服務器當機時，它能快速且透明地被替換掉。

5.複製

大多數NoSQL數據庫也支持自動複製，這意味着你能夠得到高可用性與災備恢復功能。從開發者的角度來看，存儲環境本質上是虛擬化的。

NoSQL數據庫面臨的挑戰

1.成熟度

RDBMS系統由來已久。NoSQL擁護者們會說RDBMS的高齡是其衰退的標誌，不過對於大多數CIO來講，RDBMS的成熟讓人放心。對於大多數狀況來講，RDBMS系統是穩定且功能豐富的。相比較而言，大多數NoSQL數據庫則還有不少特性有待實現。

2.支持

企業須要的是安心，若是關鍵系統出現了故障，他們能夠得到即時的支持。全部RDBMS廠商都在竭盡全力地提供良好的企業支持。與之相反，大多數NoSQL系統都是開源項目，雖然每種數據庫都有那麼幾家公司提供支持，不過這些公司大多都是小的初創公司，沒有全球支持資源，也沒有Oracle、微軟或是IBM那種使人放心的公信力。

3.分析與商業智能

NoSQL數據庫在Web 2.0應用時代開始出現。所以，大多數特性都是面向這些應用的須要的。然而，應用中的數據對於業務來講是有價值的，這種價值遠遠超出了Web應用那種CRUD。企業數據庫中的業務信息能夠幫助改進效率並提高競爭力，商業智能對於大中型企業來講是個很是關鍵的IT問題。

4.管理

NoSQL的設計目標是提供零管理的解決方案，不過當今的現實卻離這個目標還相去甚遠。如今的NoSQL須要不少技巧才能用好，而且須要很多人力、物力來維護。

5.專業

全球有不少開發者，每一個業務部門都會有熟悉RDBMS概念與編程的人。相反，幾乎每一個NoSQL開發者都處於學習模式。這種情況會隨着時間的流逝而發生改觀。但如今，找到一個有經驗的RDBMS程序員或是管理員要比NoSQL專家容易多了。

結論

NoSQL數據庫正在成爲數據庫領域的重要力量。若是使用恰當，那麼它會帶來不少好處。然而，企業應該很是當心並注意到這些數據庫的限制與問題。

NoSQL這兩年愈來愈熱，尤爲是大型互聯網公司很是熱衷這門技術。根據筆者的經驗，並非任何場景，NoSQL都要優於關係型數據庫。下面咱們來具體聊聊，何時使用NoSQL比較給力：

1) 數據庫表schema常常變化 
好比在線商城，維護產品的屬性常常要增長字段，這就意味着ORMapping層的代碼和配置要改，若是該表的數據量過百萬，新增字段會帶來額外開銷（重建索引等）。NoSQL應用在這種場景，能夠極大提高DB的可伸縮性，開發人員能夠將更多的精力放在業務層。

2)數據庫表字段是複雜數據類型

對於複雜數據類型，好比SQL Sever提供了可擴展性的支持，像xml類型的字段。不少用過的同窗應該知道，該字段無論是查詢仍是更改，效率很是通常。主要緣由是是DB層對xml字段很難建高效索引，應用層又要作從字符流到dom的解析轉換。NoSQL以json方式存儲，提供了原生態的支持，在效率方便遠遠高於傳統關係型數據庫。

3)高併發數據庫請求

此類應用常見於web2.0的網站，不少應用對於數據一致性要求很低，而關係型數據庫的事務以及大表join反而成了」性能殺手」。在高併發狀況下，sql與no-sql的性能對比因爲環境和角度不一樣一直是存在爭議的，並非說在任何場景，no-sql老是會比sql快。有篇article和你們分享下，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers

4)海量數據的分佈式存儲

海量數據的存儲若是選用大型商用數據，如Oracle，那麼整個解決方案的成本是很是高的，要花不少錢在軟硬件上。NoSQL分佈式存儲，能夠部署在廉價的硬件上，是一個性價比很是高的解決方案。Mongo的auto-sharding已經運用到了生產環境。http://www.mongodb.org/display/DOCS/Sharding

並非說NoSQL能夠解決一切問題，像ERP系統、BI系統，在大部分狀況仍是推薦使用傳統關係型數據庫。主要的緣由是此類系統的業務模型複雜，使用NoSQL將致使系統的維護成本增長。

爲何要使用NoSQL

NoSQL概念 
隨着web2.0的快速發展，非關係型、分佈式數據存儲獲得了快速的發展，它們不保證關係數據的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最多見的解釋是「non-relational」，「Not Only SQL」也被不少人接受。（「NoSQL」一詞最先於1998年被用於一個輕量級的關係數據庫的名字。）

NoSQL被咱們用得最多的當數key-value存儲，固然還有其餘的文檔型的、列存儲、圖型數據庫、xml數據庫等。在NoSQL概念提出以前，這些數據庫就被用於各類系統當中，可是卻不多用於web互聯網應用。好比cdb、qdbm、bdb數據庫。

傳統關係數據庫的瓶頸 
傳統的關係數據庫具備不錯的性能，高穩定型，久經歷史考驗，並且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯網領域，MySQL成爲了絕對靠前的王者，絕不誇張的說，MySQL爲互聯網的發展作出了卓越的貢獻。

在90年代，一個網站的訪問量通常都不大，用單個數據庫徹底能夠輕鬆應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站很少。

到了最近10年，網站開始快速發展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。在初期，論壇的流量其實也不大，若是你接觸網絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，能夠想象通常的論壇的流量有多大。

Memcached+MySQL 
後來，隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序再也不僅僅專一在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力，可是當訪問量繼續增大的時候，多臺web機器經過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就天然的成爲一個很是時尚的技術產品。

Memcached做爲一個獨立的分佈式的緩存服務器，爲多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，而後又出現了一致性hash來解決增長或減小緩存服務器致使從新hash帶來的大量緩存失效的弊端。當時，若是你去面試，你說你有Memcached經驗，確定會加分的。

Mysql主從讀寫分離 
因爲數據庫的寫入壓力增長，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製技術來達到讀寫分離，以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。

分表分庫 
隨着web2.0的繼續高速發展，在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數據增加的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster集羣，可是因爲在互聯網幾乎沒有成功案例，性能也不能知足互聯網的要求，只是在高可靠性上提供了很是大的保證。

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

MySQL數據庫也常常存儲一些大文本字段，致使數據庫表很是的大，在作數據庫恢復的時候就致使很是的慢，不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小，若是能把這些數據從MySQL省去，MySQL將變得很是的小。

關係數據庫很強大，可是它並不能很好的應付全部的應用場景。MySQL的擴展性差（須要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

NOSQL的優點

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

大數據量，高性能 
NoSQL數據庫都具備很是高的讀寫性能，尤爲在大數據量下，一樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。通常MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，因此NoSQL在這個層面上來講就要性能高不少了。

靈活的數據模型 
NoSQL無需事先爲要存儲的數據創建字段，隨時能夠存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件很是麻煩的事情。若是是很是大數據量的表，增長字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤爲明顯。

高可用 
NoSQL在不太影響性能的狀況，就能夠方便的實現高可用的架構。好比Cassandra，HBase模型，經過複製模型也能實現高可用。

總結 
NoSQL數據庫的出現，彌補了關係數據（好比MySQL）在某些方面的不足，在某些方面能極大的節省開發成本和維護成本。 
MySQL和NoSQL都有各自的特色和使用的應用場景，二者的緊密結合將會給web2.0的數據庫發展帶來新的思路。讓關係數據庫關注在關係上，NoSQL關注在存儲上。

關係數據庫仍是NoSQL數據庫

上一篇簡單的說明了爲何要使用NoSQL。接下來咱們看下如何把NoSQL引入到咱們的項目中，咱們到底要不要把NoSQL引入到項目中。

在過去，咱們只須要學習和使用一種數據庫技術，就能作幾乎全部的數據庫應用開發。由於成熟穩定的關係數據庫產品並非不少，而供你選擇的免費版本就更加少了，因此互聯網領域基本上都選擇了免費的MySQL數據庫。在高速發展的WEB2.0時代，咱們發現關係數據庫在性能、擴展性、數據的快速備份和恢復、知足需求的易用性上並不老是能很好的知足咱們的須要，咱們愈來愈趨向於根據業務場景選擇合適的數據庫，以及進行多種數據庫的融合運用。幾年前的一篇文章《One Size Fits All - An Idea Whose Time Has Come and Gone》就已經闡述了這個觀點。

當咱們在討論是否要使用NoSQL的時候，你還須要理解NoSQL也是分不少種類的，在NoSQL百花齊放的今天，NoSQL的正確選擇比選擇關係數據庫還具備挑戰性。雖然NoSQL的使用很簡單，可是選擇倒是個麻煩事，這也正是不少人在觀望的一個緣由。

NoSQL的分類

NoSQL僅僅是一個概念，NoSQL數據庫根據數據的存儲模型和特色分爲不少種類。 

以上NoSQL數據庫類型的劃分並非絕對，只是從存儲模型上來進行的大致劃分。它們之間沒有絕對的分界，也有交差的狀況，好比Tokyo Cabinet / Tyrant的Table類型存儲，就能夠理解爲是文檔型存儲，Berkeley DB XML數據庫是基於Berkeley DB之上開發的。

NoSQL仍是關係數據庫 
雖然09年出現了比較激進的文章《關係數據庫已死》，可是咱們內心都清楚，關係數據庫其實還活得好好的，你還不能不用關係數據庫。可是也說明了一個事實，關係數據庫在處理WEB2.0數據的時候，的確已經出現了瓶頸。

那麼咱們究竟是用NoSQL仍是關係數據庫呢？我想咱們沒有必要來進行一個絕對的回答。咱們須要根據咱們的應用場景來決定咱們到底用什麼。

若是關係數據庫在你的應用場景中，徹底可以很好的工做，而你又是很是善於使用和維護關係數據庫的，那麼我以爲你徹底沒有必要遷移到NoSQL上面，除非你是個喜歡折騰的人。若是你是在金融，電信等以數據爲王的關鍵領域，目前使用的是Oracle數據庫來提供高可靠性的，除非遇到特別大的瓶頸，否則也別貿然嘗試NoSQL。

然而，在WEB2.0的網站中，關係數據庫大部分都出現了瓶頸。在磁盤IO、數據庫可擴展上都花費了開發人員至關多的精力來優化，好比作分表分庫（database sharding）、主從複製、異構複製等等，然而，這些工做須要的技術能力愈來愈高，也愈來愈具備挑戰性。若是你正在經歷這些場合，那麼我以爲你應該嘗試一下NoSQL了。

選擇合適的NoSQL 
如此多類型的NoSQL，而每種類型的NoSQL又有不少，到底選擇什麼類型的NoSQL來做爲咱們的存儲呢？這並非一個很好回答的問題，影響咱們選擇的因素有不少，而選擇也可能有多種，隨着業務場景，需求的變動可能選擇又會變化。咱們經常須要根據以下狀況考慮：

1.數據結構特色。包括結構化、半結構化、字段是否可能變動、是否有大文本字段、數據字段是否可能變化。

2.寫入特色。包括insert比例、update比例、是否常常更新數據的某一個小字段、原子更新需求。

3.查詢特色。包括查詢的條件、查詢熱點的範圍。好比用戶信息的查詢，可能就是隨機的，而新聞的查詢就是按照時間，越新的越頻繁。

NoSQL和關係數據庫結合 
其實NoSQL數據庫僅僅是關係數據庫在某些方面（性能，擴展）的一個彌補，單從功能上講，NoSQL的幾乎全部的功能，在關係數據庫上都可以知足，因此選擇NoSQL的緣由並不在功能上。

因此，咱們通常會把NoSQL和關係數據庫進行結合使用，各取所長，須要使用關係特性的時候咱們使用關係數據庫，須要使用NoSQL特性的時候咱們使用NoSQL數據庫，各得其所。

舉個簡單的例子吧，好比用戶評論的存儲，評論大概有主鍵id、評論的對象aid、評論內容content、用戶uid等字段。咱們能肯定的是評論內容content確定不會在數據庫中用where content=’’查詢，評論內容也是一個大文本字段。那麼咱們能夠把 主鍵id、評論對象aid、用戶id存儲在數據庫，評論內容存儲在NoSQL，這樣數據庫就節省了存儲content佔用的磁盤空間，從而節省大量IO，對content也更容易作Cache。

//從MySQL中查詢出評論主鍵id列表 commentIds=DB.query(「SELECT id FROM comments where aid=’評論對象id’ LIMIT 0,20」); //根據主鍵id列表，從NoSQL取回評論實體數據 CommentsList=NoSQL.get(commentIds);NoSQL代替MySQL 
在某些應用場合，好比一些配置的關係鍵值映射存儲、用戶名和密碼的存儲、Session會話存儲等等，用NoSQL徹底能夠替代MySQL存儲。不但具備更高的性能，並且開發也更加方便。

NoSQL做爲緩存服務器 
MySQL+Memcached的架構中，咱們到處都要精心設計咱們的緩存，包括過時時間的設計、緩存的實時性設計、緩存內存大小評估、緩存命中率等等。

NoSQL數據庫通常都具備很是高的性能，在大多數場景下面，你沒必要再考慮在代碼層爲NoSQL構建一層Memcached緩存。NoSQL數據自己在Cache上已經作了至關多的優化工做。

Memcached這類內存緩存服務器緩存的數據大小受限於內存大小，若是用NoSQL來代替Memcached來緩存數據庫的話，就能夠再也不受限於內存大小。雖然可能有少許的磁盤IO讀寫，可能比Memcached慢一點，可是徹底能夠用來緩存數據庫的查詢操做。

規避風險 
因爲NoSQL是一個比較新的東西，特別是咱們選擇的NoSQL數據庫還不是很是成熟的產品，因此咱們可能會遇到未知的風險。爲了獲得NoSQL的好處，又要考慮規避風險，魚與熊掌如何兼得？

如今業內不少公司的作法就是數據的備份。在往NoSQL裏面存儲數據的時候還會往MySQL裏面存儲一份。NoSQL數據庫自己也須要進行備份（冷備和熱備）。或者能夠考慮使用兩種NoSQL數據庫，出現問題後能夠進行切換（避免出現digg使用Cassandra的悲劇）。