1、基本概念
NoSQL，泛指非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的社交性網(wǎng)絡服務的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，如：
1、Highperformance——對數(shù)據(jù)庫高并發(fā)讀寫的需求
Web2.0網(wǎng)站要根據(jù)用戶個性化信息來實時生成動態(tài)頁面和提供動態(tài)信息，所以基本上無法使用動態(tài)頁面靜態(tài)化技術，因此數(shù)據(jù)庫并發(fā)負載非常高，往往要達到每秒上萬次讀寫請求。關系數(shù)據(jù)庫應付上萬次SQL查詢還勉強頂?shù)米?，但是應付上萬次SQL寫數(shù)據(jù)請求，硬盤IO就已經(jīng)無法承受了。其實對于普通的BBS網(wǎng)站，往往也存在對高并發(fā)寫請求的需求，例如像JavaEye網(wǎng)站的實時統(tǒng)計在線用戶狀態(tài)，記錄熱門帖子的點擊次數(shù)，投票計數(shù)等，因此這是一個相當普遍的需求。
2、HugeStorage——對海量數(shù)據(jù)的高效率存儲和訪問的需求
類似Facebook，twitter，F(xiàn)riendfeed這樣的社交性網(wǎng)站，每天用戶產(chǎn)生海量的用戶動態(tài)，以Friendfeed為例，一個月就達到了2.5億條用戶動態(tài)，對于關系數(shù)據(jù)庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動輒數(shù)以億計的帳號，關系數(shù)據(jù)庫也很難應付。
3、HighScalability&&HighAvailability——對數(shù)據(jù)庫的高可擴展性和高可用性的需求
在基于web的架構當中，數(shù)據(jù)庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候，你的數(shù)據(jù)庫卻沒有辦法像webserver和appserver那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數(shù)據(jù)遷移，數(shù)據(jù)庫不能通過不斷的添加服務器節(jié)點來實現(xiàn)擴展。
為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應用難題，NoSQL這種非關系型的數(shù)據(jù)應運而生。
2、NoSQL數(shù)據(jù)庫分類
1、鍵值(Key-Value)存儲數(shù)據(jù)庫
這一類數(shù)據(jù)庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key/value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。
2、列存儲數(shù)據(jù)庫
這部分數(shù)據(jù)庫通常是用來應對分布式存儲的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。列存儲數(shù)據(jù)庫存儲每一列，允許更快的掃描時，只涉及一小部分列。
一個數(shù)據(jù)庫索引是一種數(shù)據(jù)結構，允許在存儲空間上快速查找數(shù)據(jù)和額外的寫(索引更新)。索引映射到數(shù)據(jù)的行數(shù)，而一個列數(shù)據(jù)庫將數(shù)據(jù)映射到行數(shù)，這樣計算變得更快。
3、文檔型數(shù)據(jù)庫
文檔型數(shù)據(jù)庫的靈感是來自于LotusNotes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型數(shù)據(jù)庫可以看作是鍵值數(shù)據(jù)庫的升級版，允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫比鍵值數(shù)據(jù)庫的查詢效率更高。
文檔型存儲以報紙為例，報紙上一篇文章也可以存儲為一個單一的實體，這降低了對于習慣看到文章內(nèi)容所消耗的時間。
4、圖形(Graph)數(shù)據(jù)庫
圖形結構的數(shù)據(jù)庫同其他行列以及剛性結構的SQL數(shù)據(jù)庫不同，它是使用靈活的圖形模型，并且能夠擴展到多個服務器上。圖或網(wǎng)絡數(shù)據(jù)主要有2個組成部分：
節(jié)點：實體本身。在社交網(wǎng)絡中，這可能是人。
邊：實體間的關系。這種關系用一條線來表示，并且有它自己的特性。邊可以有一個方向。
圖可以變的非常復雜來給定足夠的關系和實體類型。
因此，我們總結NoSQL數(shù)據(jù)庫在以下的這幾種情況下比較適用：
1、數(shù)據(jù)模型比較簡單；
2、需要靈活性更強的IT系統(tǒng)；
3、對數(shù)據(jù)庫性能要求較高；
4、不需要高度的數(shù)據(jù)一致性；
5、對于給定key，比較容易映射復雜值的環(huán)境。
3、常見NoSQL數(shù)據(jù)庫
1）Redis
Redis是一個開源的使用ANSIC語言編寫、支持網(wǎng)絡、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。從2010年3月15日起，Redis的開發(fā)工作由VMware主持。從2013年5月開始，Redis的開發(fā)由Pivotal贊助。
Redis本質上是一個Key-Value類型的內(nèi)存數(shù)據(jù)庫，很像memcached，整個數(shù)據(jù)庫系統(tǒng)加載在內(nèi)存當中進行操作，定期通過異步操作把數(shù)據(jù)庫數(shù)據(jù)flush到硬盤上進行保存。因為是純內(nèi)存操作，Redis的性能非常出色，每秒可以處理超過10萬次讀寫操作。
Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存List鏈表和Set集合的數(shù)據(jù)結構，而且還支持對List進行各種操作，例如從List兩端push和pop數(shù)據(jù)，取List區(qū)間，排序等等，對Set支持各種集合的并集交集操作，此外單個value的最大限制是1GB，不像memcached只能保存1MB的數(shù)據(jù)，因此Redis可以用來實現(xiàn)很多有用的功能，比方說用他的List來做FIFO雙向鏈表，實現(xiàn)一個輕量級的高性能消息隊列服務，用他的Set可以做高性能的tag系統(tǒng)等等。另外Redis也可以對存入的Key-Value設置expire時間，因此也可以被當作一個功能加強版的memcached來用。
Redis的主要缺點是數(shù)據(jù)庫容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫，并且它沒有原生的可擴展機制，不具有scale（可擴展）能力，要依賴客戶端來實現(xiàn)分布式讀寫，因此Redis適合的場景主要局限在較小數(shù)據(jù)量的高性能操作和運算上。目前使用Redis的網(wǎng)站有github，EngineYard。
2）MongoDB
MongoDB是一個開源的面向文檔的NoSQL數(shù)據(jù)庫系統(tǒng)，目前由10gen開發(fā)并維護，介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的產(chǎn)品，是非關系數(shù)據(jù)庫當中功能最豐富，最像關系數(shù)據(jù)庫的。他支持的數(shù)據(jù)結構非常松散，是類似json的bjson格式，因此可以存儲比較復雜的數(shù)據(jù)類型。
Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現(xiàn)類似關系數(shù)據(jù)庫單表查詢的絕大部分功能，而且還支持對數(shù)據(jù)建立索引。
Mongo主要解決的是海量數(shù)據(jù)的訪問效率問題，根據(jù)官方的文檔，當數(shù)據(jù)量達到50GB以上的時候，Mongo的數(shù)據(jù)庫訪問速度是MySQL的10倍以上。Mongo的并發(fā)讀寫效率不是特別出色，根據(jù)官方提供的性能測試表明，大約每秒可以處理0.5萬－1.5次讀寫請求。
因為Mongo主要是支持海量數(shù)據(jù)存儲的，所以Mongo還自帶了一個出色的分布式文件系統(tǒng)GridFS，可以支持海量的數(shù)據(jù)存儲。
3）HBASE
HBase–HadoopDatabase，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用HBase技術可在廉價PCServer上搭建起大規(guī)模結構化存儲集群。
與FUJITSUCliq等商用大數(shù)據(jù)產(chǎn)品不同，HBase是GoogleBigtable的開源實現(xiàn)，類似GoogleBigtable利用GFS作為其文件存儲系統(tǒng)，HBase利用HadoopHDFS作為其文件存儲系統(tǒng)；Google運行MapReduce來處理Bigtable中的海量數(shù)據(jù)，HBase同樣利用HadoopMapReduce來處理HBase中的海量數(shù)據(jù)；GoogleBigtable利用Chubby作為協(xié)同服務，HBase利用Zookeeper作為對應。
