【轉載】NoSQL開篇——為什麼要使用NoSQL

【編者按】NoSQL在2010年風生水起，大大小小的Web站點在追求高效能高可靠性方面，不由自主都選擇了NoSQL技術作為優先考慮的方面。今年伊始，InfoQ中文站有幸邀請到鳳凰網的孫立先生，為大家分享他之於NoSQL方面的經驗和體會。

非常榮幸能受邀在InfoQ開闢這樣一個關於NoSQL的專欄，InfoQ是我非常尊重的一家技術媒體，同時我也希望藉助InfoQ，在國內推動NoSQL的發展，希望跟我一樣有興趣的朋友加入進來。這次的NoSQL專欄系列將先整體介紹NoSQL，然後介紹如何把NoSQL運用到自己的專案中合適的場景中，還會適當地分析一些成功案例，希望有成功使用NoSQL經驗的朋友給我提供一些線索和資訊。

NoSQL概念

隨著web2.0的快速發展，非關係型、分散式資料儲存得到了快速的發展，它們不保證關係資料的ACID特性。概念在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關注在儲存上。

參考閱讀

1. NoSQL：
2. NoSQL在wiki上的介紹：
3. NoSQL相關部落格：http://nosql.mypopescu.com/
4. NoSQL相關部落格：http://blog.nosqlfan.com/
5. 新浪微博NoSQL微群：

關於作者

孫立，目前在鳳凰網負責底層組的研發工作。曾就職於搜狐和ku6。多年網際網路從業經驗和程式開發，對分散式搜尋引擎的開發，高併發，大資料量網站系統架構最佳化，高可用性，可伸縮性，分散式系統快取,資料庫分表分庫（sharding）等有豐富的經驗，並且對運維監控和自動化運維控制有經驗。開源專案phplock，phpbuffer的作者。近期開發了一個NOSQL資料庫儲存INetDB,是NoSQL資料庫愛好者。他的新浪微博是：

感謝對本文的策劃及審校。