『壹』 我們為什麼要使用NOSQL非關系資料庫
而傳統的關系資料庫在應付web2.0網站，特別是超大規模和高並發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對資料庫高並發讀寫的需求
web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此資料庫並發負載非常高，往往要達到每秒上萬次讀寫請求。關系資料庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬碟IO就已經無法承受了。其實對於普通的BBS網站，往往也存在對高並發寫請求的需求。
2、Huge Storage - 對海量數據的高效率存儲和訪問的需求
對於大型的SNS網站，每天用戶產生海量的用戶動態，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態，對於關系資料庫來說，在一張2.5億條記錄的表裡面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，關系資料庫也很難應付。
3、High Scalability && High Availability- 對資料庫的高可擴展性和高可用性的需求
在基於web的架構當中，資料庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的資料庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬體和服務節點來擴展性能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對資料庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，為什麼資料庫不能通過不斷的添加伺服器節點來實現擴展呢？
在上面提到的「三高」需求面前，關系資料庫遇到了難以克服的障礙，而對於web2.0網站來說，關系資料庫的很多主要特性卻往往無用武之地，例如：
1、資料庫事務一致性需求
很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此資料庫事務管理成了資料庫高負載下一個沉重的負擔。
2、資料庫的寫實時性和讀實時性需求
對關系資料庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這么高的實時性。
3、對復雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關系資料庫在這些越來越多的應用場景下顯得不那麼合適了，為了解決這類問題的非關系資料庫應運而生。
NoSQL 是非關系型數據存儲的廣義定義。它打破了長久以來關系型資料庫與ACID理論大一統的局面。NoSQL 數據存儲不需要固定的表結構，通常也不存在連接操作。在大數據存取上具備關系型資料庫無法比擬的性能優勢。該術語在 2009 年初得到了廣泛認同。
當今的應用體系結構需要數據存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業 NoSQL 實現。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。
『貳』 newsql和nosql的區別和聯系
在大數據時代，「多種架構支持多類應用」成為資料庫行業應對大數據的基本思路，資料庫行業出現互為補充的三大陣營，適用於事務處理應用的OldSQL、適用於數據分析應用的NewSQL和適用於互聯網應用的NoSQL。但在一些復雜的應用場景中，單一資料庫架構都不能完全滿足應用場景對海量結構化和非結構化數據的存儲管理、復雜分析、關聯查詢、實時性處理和控制建設成本等多方面的需要，因此不同架構資料庫混合部署應用成為滿足復雜應用的必然選擇。不同架構資料庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構資料庫的混合應用部署進行介紹。
OldSQL+NewSQL 在數據中心類應用中混合部署
採用OldSQL+NewSQL模式構建數據中心，在充分發揮OldSQL資料庫的事務處理能力的同時，藉助NewSQL在實時性、復雜分析、即席查詢等方面的獨特優勢，以及面對海量數據時較強的擴展能力，滿足數據中心對當前「熱」數據事務型處理和海量歷史「冷」數據分析兩方面的需求。OldSQL+NewSQL模式在數據中心類應用中的互補作用體現在，OldSQL彌補了NewSQL不適合事務處理的不足，NewSQL彌補了OldSQL在海量數據存儲能力和處理性能方面的缺陷。
商業銀行數據中心採用OldSQL+NewSQL混合部署方式搭建，OldSQL資料庫滿足各業務系統數據的歸檔備份和事務型應用，NewSQL MPP資料庫集群對即席查詢、多維分析等應用提供高性能支持，並且通過MPP集群架構實現應對海量數據存儲的擴展能力。
商業銀行數據中心存儲架構
與傳統的OldSQL模式相比，商業銀行數據中心採用OldSQL+NewSQL混合搭建模式，數據載入性能提升3倍以上，即席查詢和統計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應對新的業務需求，可隨著數據量的增長採用集群方式構建存儲容量更大的數據中心。
OldSQL+NoSQL 在互聯網大數據應用中混合部署
在互聯網大數據應用中採用OldSQL+NoSQL混合模式，能夠很好的解決互聯網大數據應用對海量結構化和非結構化數據進行存儲和快速處理的需求。在諸如大型電子商務平台、大型SNS平台等互聯網大數據應用場景中，OldSQL在應用中負責高價值密度結構化數據的存儲和事務型處理，NoSQL在應用中負責存儲和處理海量非結構化的數據和低價值密度結構化數據。OldSQL+NoSQL模式在互聯網大數據應用中的互補作用體現在，OldSQL彌補了NoSQL在ACID特性和復雜關聯運算方面的不足，NoSQL彌補了OldSQL在海量數據存儲和非結構化數據處理方面的缺陷。
數據魔方是淘寶網的一款數據產品，主要提供行業數據分析、店鋪數據分析。淘寶數據產品在存儲層採用OldSQL+NoSQL混合模式，由基於MySQL的分布式關系型資料庫集群MyFOX和基於HBase的NoSQL存儲集群Prom組成。由於OldSQL強大的語義和關系表達能力，在應用中仍然占據著重要地位，目前存儲在MyFOX中的統計結果數據已經達到10TB，占據著數據魔方總數據量的95%以上。另一方面，NoSQL作為SQL的有益補充，解決了OldSQL資料庫無法解決的全屬性選擇器等問題。
淘寶海量數據產品技術架構
基於OldSQL+NoSQL混合架構的特點，數據魔方目前已經能夠提供壓縮前80TB的數據存儲空間，支持每天4000萬的查詢請求，平均響應時間在28毫秒，足以滿足未來一段時間內的業務增長需求。
NewSQL+NoSQL 在行業大數據應用中混合部署
行業大數據與互聯網大數據的區別在於行業大數據的價值密度更高，並且對結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等都比互聯網大數據有更高的要求。行業大數據應用場景主要是分析類應用，如：電信、金融、政務、能源等行業的決策輔助、預測預警、統計分析、經營分析等。
在行業大數據應用中採用NewSQL+NoSQL混合模式，充分利用NewSQL在結構化數據分析處理方面的優勢，以及NoSQL在非結構數據處理方面的優勢，實現NewSQL與NoSQL的功能互補，解決行業大數據應用對高價值結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等要求，以及對海量非結構化數據存儲和精確查詢的要求。在應用中，NewSQL承擔高價值密度結構化數據的存儲和分析處理工作，NoSQL承擔存儲和處理海量非結構化數據和不需要關聯分析、Ad-hoc查詢較少的低價值密度結構化數據的工作。
當前電信運營商在集中化BI系統建設過程中面臨著數據規模大、數據處理類型多等問題，並且需要應對大量的固定應用，以及占統計總數80%以上的突發性臨時統計(ad-hoc)需求。在集中化BI系統的建設中採用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復雜分析、即席查詢等方面處理性能的優勢，及NoSQL在非結構化數據處理和海量數據存儲方面的優勢，實現高效低成本。
集中化BI系統數據存儲架構
集中化BI系統按照數據類型和處理方式的不同，將結構化數據和非結構化數據分別存儲在不同的系統中：非結構化數據在Hadoop平台上存儲與處理;結構化、不需要關聯分析、Ad-hoc查詢較少的數據保存在NoSQL資料庫或Hadoop平台;結構化、需要關聯分析或經常ad-hoc查詢的數據，保存在NewSQL MPP資料庫中，短期高價值數據放在高性能平台，中長期放在低成本產品中。
結語
當前信息化應用的多樣性、復雜性，以及三種資料庫架構各自所具有的優勢和局限性，造成任何一種架構的資料庫都不能完全滿足應用需求，因此不同架構資料庫混合使用，從而彌補其他架構的不足成為必然選擇。根據應用場景採用不同架構資料庫進行組合搭配，充分發揮每種架構資料庫的特點和優勢，並且與其他架構資料庫形成互補，完全涵蓋應用需求，保證數據資源的最優化利用，將成為未來一段時期內信息化應用主要採用的解決方式。
目前在國內市場上，OldSQL主要為Oracle、IBM等國外資料庫廠商所壟斷，達夢、金倉等國產廠商仍處於追趕狀態;南大通用憑借國產新型資料庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多採用Hadoop開源方案。
『叄』 為什麼要使用NoSQL資料庫
因為關系資料庫運行的慢
處理大數據的大多數情況是nosql比較高效
但是nosql也沒法完全取代關系資料庫
nosql不能處理復雜的邏輯
但是很多情況下只是簡單的mapping,匯總,
在目前互聯網大數據的環境下nosql會越來越普及
『肆』 什麼是NoSQL，它有什麼優缺點
NoSQL，指的是非關系型的資料庫。NoSQL有時也稱作Not Only SQL的縮寫，是對不同於傳統的關系型資料庫的資料庫管理系統的統稱。
NoSQL用於超大規模數據的存儲。（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多餘操作就可以橫向擴展。
NoSQL的優點/缺點
優點:
- 高可擴展性
- 分布式計算
- 低成本
- 架構的靈活性，半結構化數據
- 沒有復雜的關系
缺點:
- 沒有標准化
- 有限的查詢功能（到目前為止）
- 最終一致是不直觀的程序 （BY三人行慕課）
『伍』 為什麼要使用NoSQLNOSQL的優勢
非常榮幸能受邀在InfoQ開辟這樣一個關於NoSQL的專欄，InfoQ是我非常尊重的一家技術媒體，同時我也希望藉助InfoQ，在國內推動NoSQL的發展，希望跟我一樣有興趣的朋友加入進來。這次的NoSQL專欄系列將先整體介紹NoSQL，然後介紹如何把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之間的區別可以得出
關系型資料庫
關系型資料庫把所有的數據都通過行和列的二元表現形式表示出來。
關系型資料庫的優勢：
1.保持數據的一致性（事務處理）
2.由於以標准化為前提，數據更新的開銷很小（相同的欄位基本上都只有一處）
3.可以進行Join等復雜查詢
其中能夠保持數據的一致性是關系型資料庫的最大優勢。
關系型資料庫的不足：
不擅長的處理
1.大量數據的寫入處理（這點尤為重要）
2.為有數據更新的表做索引或表結構（schema）變更
3.欄位不固定時應用
4.對簡單查詢需要快速返回結果的處理
--大量數據的寫入處理
讀寫集中在一個資料庫上讓資料庫不堪重負，大部分網站已使用主從復制技術實現讀寫分離，以提高讀寫性能和讀庫的可擴展性。
所以在進行大量數據操作時，會使用資料庫主從模式。數據的寫入由主資料庫負責，數據的讀入由從資料庫負責，可以比較簡單地通過增加從資料庫來實現規模化，但是數據的寫入卻完全沒有簡單的方法來解決規模化問題。
第一，要想將數據的寫入規模化，可以考慮把主資料庫從一台增加到兩台，作為互相關聯復制的二元主資料庫使用，確實這樣可以把每台主資料庫的負荷減少一半，但是更新處理會發生沖突，可能會造成數據的不一致，為了避免這樣的問題，需要把對每個表的請求分別分配給合適的主資料庫來處理。
第二，可以考慮把資料庫分割開來，分別放在不同的資料庫伺服器上，比如將不同的表放在不同的資料庫伺服器上，資料庫分割可以減少每台資料庫伺服器上的數據量，以便減少硬碟IO的輸入、輸出處理，實現內存上的高速處理。但是由於分別存儲字不同伺服器上的表之間無法進行Join處理，資料庫分割的時候就需要預先考慮這些問題，資料庫分割之後，如果一定要進行Join處理，就必須要在程序中進行關聯，這是非常困難的。
--為有數據更新的表做索引或表結構變更
在使用關系型資料庫時，為了加快查詢速度需要創建索引，為了增加必要的欄位就一定要改變表結構，為了進行這些處理，需要對表進行共享鎖定，這期間數據變更、更新、插入、刪除等都是無法進行的。如果需要進行一些耗時操作，例如為數據量比較大的表創建索引或是變更其表結構，就需要特別注意，長時間內數據可能無法進行更新。
--欄位不固定時的應用
如果欄位不固定，利用關系型資料庫也是比較困難的，有人會說，需要的時候加個欄位就可以了，這樣的方法也不是不可以，但在實際運用中每次都進行反復的表結構變更是非常痛苦的。你也可以預先設定大量的預備欄位，但這樣的話，時間一長很容易弄不清除欄位和數據的對應狀態，即哪個欄位保存有哪些數據。
--對簡單查詢需要快速返回結果的處理 （這里的「簡單」指的是沒有復雜的查詢條件）
這一點稱不上是缺點，但不管怎樣，關系型資料庫並不擅長對簡單的查詢快速返回結果，因為關系型資料庫是使用專門的sql語言進行數據讀取的，它需要對sql與越南進行解析，同時還有對表的鎖定和解鎖等這樣的額外開銷，這里並不是說關系型資料庫的速度太慢，而只是想告訴大家若希望對簡單查詢進行高速處理，則沒有必要非使用關系型資料庫不可。
NoSQL資料庫
關系型資料庫應用廣泛，能進行事務處理和表連接等復雜查詢。相對地，NoSQL資料庫只應用在特定領域，基本上不進行復雜的處理，但它恰恰彌補了之前所列舉的關系型資料庫的不足之處。
優點：
易於數據的分散
各個數據之間存在關聯是關系型資料庫得名的主要原因，為了進行join處理，關系型資料庫不得不把數據存儲在同一個伺服器內，這不利於數據的分散，這也是關系型資料庫並不擅長大數據量的寫入處理的原因。相反NoSQL資料庫原本就不支持Join處理，各個數據都是獨立設計的，很容易把數據分散在多個伺服器上，故減少了每個伺服器上的數據量，即使要處理大量數據的寫入，也變得更加容易，數據的讀入操作當然也同樣容易。
典型的NoSQL資料庫
臨時性鍵值存儲（memcached、Redis）、永久性鍵值存儲（ROMA、Redis）、面向文檔的資料庫（MongoDB、CouchDB）、面向列的資料庫（Cassandra、HBase）
一、 鍵值存儲
它的數據是以鍵值的形式存儲的，雖然它的速度非常快，但基本上只能通過鍵的完全一致查詢獲取數據，根據數據的保存方式可以分為臨時性、永久性和兩者兼具 三種。
（1）臨時性
所謂臨時性就是數據有可能丟失，memcached把所有數據都保存在內存中，這樣保存和讀取的速度非常快，但是當memcached停止時，數據就不存在了。由於數據保存在內存中，所以無法操作超出內存容量的數據，舊數據會丟失。總結來說：
。在內存中保存數據
。可以進行非常快速的保存和讀取處理
。數據有可能丟失
（2）永久性
所謂永久性就是數據不會丟失，這里的鍵值存儲是把數據保存在硬碟上，與臨時性比起來，由於必然要發生對硬碟的IO操作，所以性能上還是有差距的，但數據不會丟失是它最大的優勢。總結來說：
。在硬碟上保存數據
。可以進行非常快速的保存和讀取處理（但無法與memcached相比）
。數據不會丟失
（3） 兩者兼備
Redis屬於這種類型。Redis有些特殊，臨時性和永久性兼具。Redis首先把數據保存在內存中，在滿足特定條件（默認是15分鍾一次以上，5分鍾內10個以上，1分鍾內10000個以上的鍵發生變更）的時候將數據寫入到硬碟中，這樣既確保了內存中數據的處理速度，又可以通過寫入硬碟來保證數據的永久性，這種類型的資料庫特別適合處理數組類型的數據。總結來說：
。同時在內存和硬碟上保存數據
。可以進行非常快速的保存和讀取處理
。保存在硬碟上的數據不會消失（可以恢復）
。適合於處理數組類型的數據
二、面向文檔的資料庫
MongoDB、CouchDB屬於這種類型，它們屬於NoSQL資料庫，但與鍵值存儲相異。
（1）不定義表結構
即使不定義表結構，也可以像定義了表結構一樣使用，還省去了變更表結構的麻煩。
（2）可以使用復雜的查詢條件
跟鍵值存儲不同的是，面向文檔的資料庫可以通過復雜的查詢條件來獲取數據，雖然不具備事務處理和Join這些關系型資料庫所具有的處理能力，但初次以外的其他處理基本上都能實現。
三、面向列的資料庫
Cassandra、HBae、HyperTable屬於這種類型，由於近年來數據量出現爆發性增長，這種類型的NoSQL資料庫尤其引入注目。
普通的關系型資料庫都是以行為單位來存儲數據的，擅長以行為單位的讀入處理，比如特定條件數據的獲取。因此，關系型資料庫也被成為面向行的資料庫。相反，面向列的資料庫是以列為單位來存儲數據的，擅長以列為單位讀入數據。
面向列的資料庫具有搞擴展性，即使數據增加也不會降低相應的處理速度（特別是寫入速度），所以它主要應用於需要處理大量數據的情況。另外，把它作為批處理程序的存儲器來對大量數據進行更新也是非常有用的。但由於面向列的資料庫跟現行資料庫存儲的思維方式有很大不同，故應用起來十分困難。
總結：關系型資料庫與NoSQL資料庫並非對立而是互補的關系，即通常情況下使用關系型資料庫，在適合使用NoSQL的時候使用NoSQL資料庫，讓NoSQL資料庫對關系型資料庫的不足進行彌補。
『柒』 為什麼大部分NoSQL不提供分布式事務
像MongoDB, Cassandra, HBase, DynamoDB, 和
Riak這些NoSQL缺乏傳統的原子事務機制，所謂原子事務機制是可以保證一系列寫操作要麼全部完成，要麼全部不會完成，不會發生只完成一系列中一兩個
寫操作;因為資料庫不提供這種事務機制支持，開發者需要自己編寫代碼來確保一系列寫操作的事務機制，比較復雜和測試。
這些NoSQL資料庫不提供事務機制原因在於其分布式特點，一系列寫操作中訪問的數據可能位於不同的分區伺服器，這樣的事務就變成分布式事務，在分
布式事務中實現原子性需要彼此協調，而協調是耗費時間的，每台機器在一個大事務過程中必須依次確認，這就需要一種協議確保一個事務中沒有任何一台機器寫操
作失敗。
這種協調是昂貴的，會增加延遲時間，關鍵問題是，當協調沒有完成時，其他操作是不能讀取事務中寫操作結果的，這是因為事務的all-or-
nothing原理導致，萬一協調過程發現某個寫操作不能完成，那麼需要將其他寫操作成功的進行回滾。針對分布式事務的分布式協調對整體資料庫性能有嚴重
影響，不只是吞吐量還包括延遲時間，這樣大部分NoSQL資料庫因為性能問題就選擇不提供分布式事務。
MongoDB, Riak, HBase, 和 Cassandra提供基於單一鍵的事務，這是因為所有信息都和一個鍵key有關，這個鍵是存儲在單個伺服器上，這樣基於單鍵的事務不會帶來復雜的分布式協調。
那麼看來擴展性性能和分布式事務是一對矛盾，總要有取捨?實際上是不完全是，現在完全有可能提供高擴展的性能同時提供分布式原子事務。
FIT是這樣一個在分布式系統提供原子事務的策略，在fairness公平性, isolation隔離性, 和throughput吞吐量(簡稱FIT)可以權衡。
一個支持分布式事務的可伸縮分布式系統能夠完成這三個屬性中兩個，公平是事務之間不會相互影響造成延遲;隔離性提供一種幻覺好像整個資料庫只有它自
己一個事務，隔離性保證當任何同時發生的事務發生沖突時，能夠保證彼此能看到彼此的寫操作結果，因此減輕了程序員為避免事務讀寫沖突的強邏輯推理要求;吞
吐量是指每單元時間資料庫能夠並發處理多少事務。
FIT是如下進行權衡：
保證公平性fairness 和隔離性isolation, 但是犧牲吞吐量
保證公平性fairness和吞吐量, 犧牲隔離性isolation
保證隔離性isolation和吞吐量throughput, 但是犧牲公平性fairness.
犧牲公平性：放棄公平性，資料庫能有更多機會降低分布式事務的成本，主要成本是分布式協調帶來的，也就是說，不需要在每個事務過程內對每個機器都依
次確認事務完成，這樣排隊式的確認commit事務是很浪費時間的，放棄公平性，意味著可以在事務外面進行協調，這樣就只是增加了協調時間，不會增加互相
沖突事務因為彼此沖突而不能運行所耽擱的時間，當系統不需要公平性時，需要根據事務的優先順序或延遲等標准進行指定先後執行順序，這樣就能夠獲得很好的吞吐
量。
G-Store是一種放棄公平性的 Isolation-Throughput
的分布式key-value存儲，支持多鍵事務(multi-key transactions)，MongoDB 和
HBase在鍵key在同樣分區上也支持多鍵事務，但是不支持跨分區的事務。
總之：傳統分布式事務性能不佳的原因是確保原子性(分布式協調)和隔離性同時重疊，創建一個高吞吐量分布式事務的關鍵是分離這兩種關注，這種分離原
子性和隔離性的視角將導致兩種類型的系統，第一種選擇是弱隔離性能讓沖突事務並行執行和確認提交;第二個選擇重新排序原子性和隔離性機制保證它們不會某個
時間重疊，這是一種放棄公平的事務執行，所謂放棄公平就是不再同時照顧原子性和隔離性了，有所傾斜，放棄高標准道德要求就會帶來高自由高效率。
『捌』 為什麼要用NoSQL資料庫管理系統
一、首先看看傳統關系型資料庫的瓶頸：
無法應對每秒上萬次的讀寫請求，硬碟IO此時也將變為性能瓶頸
表中存儲記錄數量有限，橫向可擴展能力有限，縱向數據可承受能力也是有限的，面對海量數據，勢必涉及到分庫分表，難以維護。大數據查詢SQL效率極低，數據量到達一定程度時，查詢時間會呈指數級別增長
難以橫向擴展，無法簡單地通過增加硬體、服務節點來提高系統性能。對於需要24小時不間斷提供服務的網站來說，資料庫升級、擴展將是一件十分麻煩的事，往往需要停機維護，數據遷移，為了避免服務間斷，如果網站使用伺服器集群，則根據集群策略，需要相應的考慮主從一致性、集群擴展性等一系列問題
二、然後看看NoSQL資料庫的優點：
海量數據下，讀寫性能優異
數據模型靈活
數據間無關系，易於擴展
三、NoSQL資料庫分類：
1，鍵值存儲資料庫。代表資料庫：Redis
適用場景：會話信息，用戶配置信息，購物車
2，列存儲資料庫
代表資料庫：BigTable，Cassandra，HBase
適用場景：事件記錄，內容管理，博客平台
不適合需要ACID事務的場合
3，文檔型資料庫
代表資料庫：MongoDB
適用場景：事件記錄，內容管理，博客平台，網站分析，實時分析，電子商務應用
4，圖資料庫：可以使用圖結構相關演算法，比如最短路徑定址
代表資料庫：Neo4j
適用場景：社交網路，推薦引擎，基於位置的服務