最近聽說了很多關于NoSQL的新聞，比如之前Sourceforge改用MongoDB，Digg改用Cassandra等等。再加上之前做數據庫比較時有人推薦我mongodb，所以也搜索了一下NoSQL，覺得NoSQL可能真的是未來的趨勢。

　　NoSQL vs SQL

　　傳統SQL數據庫為了實現ACID(atomicity, consistency, isolation, durability)，往往需要頻繁應用文件鎖，這使得其在現代的Web2.0應用中越來越捉襟見肘。現在SNS網站每一個點擊都是一條/多條查詢，對數據庫寫的并發要求非常之高，而傳統數據庫無法很好地應對這種需求。而仔細想來SNS中大部分需求并不要求ACID，比如Like/Unlike投票等等。

　　NoSQL吸取了教訓，比如有些NoSQL采用了eventually consistency的概念，在沒有Update操作一段時間后，數據庫將最終是consistency的，顯然這樣的數據庫將能更好的支持高并發讀寫。

　　SQL數據庫是基于schema的，這對時時刻刻更新著的Web2.0應用開發者來說是個噩夢：隨時隨地有新的應用出現，舊的數據庫無法適應新的應用，只能不停地更新schema，或者做補丁表，如此一來要么schema越發混亂，要么就是數據庫頻繁升級而耗時耗力耗錢。

　　NoSQL一般就沒有schema這種概念，大部分NoSQL都直接保存json類的Row，比如一個記錄可以是{ id = 1, name = Bob, phone = 38492839 }，這樣擴展升級非常方便，比如需要地址信息直接加入 address=blahblah 即可。

　　傳統SQL很難進行分布式應用，即使可以也往往代價高昂。而NoSQL則很好地解決了這個問題：他們一般都直接從分布式系統中吸取了Map/Reduce方法，從而很容易就可以處理規模急速增加的問題。

　　推薦robbin牛的NoSQL數據庫探討之一 － 為什么要用非關系數據庫？一文，介紹了主流的一些NoSQL系統，還有這個站http://nosql-database.org/收集了基本上目前所有的NoSQL系統。

　　總結一下我對NoSQL的看法，NoSQL出現的目的就是為了解決高并發讀寫的問題，而高并發應用往往需要分布式的數據庫來實現高性能和高可靠性，所以NoSQL的關鍵字就是concurrency和scalability。

　　我的瓶頸

　　我之前主要關注數據庫的select性能也就是read性能，在讀性能方面SQL數據庫并沒有明顯的劣勢，應該說純粹高并發讀的性能的話往往要優于NoSQL數據庫，然而一旦涉及寫，事情就不一樣了。

　　我本來以為自己不會遇到大量寫的問題，后來發現即使在simplecd這種簡單的應用環境下也會產生大量的并發寫：這就是爬VC用戶評論的時候。事實上，sqlite3在處理這個問題上非常的力不從心，所以我產生了換個數據庫的想法。

　　既然我是要求能高并發讀寫，干脆就不用SQL了，但是同時我也想測試一下其他SQL的寫性能。

　　我的數據有180萬條，總共350M，測試用了10個線程，每個線程做若干次100個數據的bulk寫入，然后記錄總共耗時。結果如下:

innodb: 15.19
myiasm: 14.34
pgsql: 23.41
sqlite3: 鎖住了
sqlite3(單線程): 300+
mongodb: 3.82
couchdb: 90
couchdb(單線程)：66

　　作為一個MySQL黑，看到這組測試數據我表示壓力很大。在SQL數據庫中，mysql意外地取得了最佳的成績，好于pgsql，遠好于sqlite。更令人意外的是myisam居然優于號稱insert比較快的innodb。不管如何，對我的應用來說，用mysql保存評論數據是一個更為明智的選擇。我對mysql徹底改觀了，我宣布我是mysql半黑。以后select-intensive的應用我還是會選擇sqlite，但是insert/update-intensive的應用我就會改用mysql了。

　　MongoDB和CouchDB同為NoSQL，表現卻截然相反，MongoDB性能很高，CouchDB的并發性能我只能ORZ，這種性能實在太抱歉了。

　　NoSQL的碎碎念

　　其實我本來還打算測試cassandra的，可是cassandra用的是java，這首先讓我眉頭一皺，內存大戶我養不起啊，其次看了cassandra的文檔，立刻崩潰，這簡直就是沒有文檔么。（BTW，CouchDB也好不到哪里去，我都是用python-couchdb然后help(couchdb.client)看用法的）

　　至于CouchDB，可能是因為采用http方式發送請求，所以并發性能糟糕的一塌糊涂，很懷疑它是否有存在的理由。

　　MongoDB是我用下來最討人喜歡的一個NoSQL。不但文檔豐富，使用簡單，性能也非常好，它的Map/Reduce查詢(很多NoSQL都有)讓我驚嘆，數據庫可以非常簡單地就擴大規模，完全不用理會什么分區分表之類繁瑣的問題，可惜這方面我暫時沒有需求。但是MongoDB有兩大致命問題。

　　第一是刪除鎖定問題，當批量刪除記錄時，數據庫還是會鎖定不讓讀寫。這意味著進行數據清理時會讓網站應用失去響應。見locking problems

　　第二是內存占用問題，MongoDB用了操作系統的內存文件映射，這導致操作系統會把所有空閑內存都分配給MongoDB，當MongoDB有這個需要時。更可怕的是，MongoDB從來不主動釋放已經霸占的內存，它只會滾雪球一樣越滾越大，除非重啟數據庫。這樣的上下文環境下，MongoDB只適合一臺主機就一個數據庫，而沒有其他應用的環境，否則一會兒功夫MongoDB就會吃光內存，然后你都fork不出新進程，徹底悲劇。見memory limit

　　總之NoSQL雖然讓我眼前一亮，可是目前嘗試的一些產品都讓人望而生畏，現在的NoSQL都把目光放在了巨型網站上，而沒有一個小型的，可以在VPS里面應用的高性能NoSQL，令我有點失望。NoSQL尚未成熟，很期待它的將來發展，目前來說MySQL還是更好的選擇。