NoSQL開篇——為什么要使用NoSQL

來源: infoq  發布時間: 2011-01-16 18:08  閱讀: 3204 次  推薦: 2   原文鏈接   [收藏]  
摘要:NoSQL在2010年風生水起,大大小小的Web站點在追求高性能高可靠性方面,不由自主都選擇了NoSQL技術作為優先考慮的方面。今年伊始,InfoQ中文站有幸邀請到鳳凰網的孫立先生,為大家分享他之于NoSQL方面的經驗和體會。

  非常榮幸能受邀在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關注在存儲上。

  參考閱讀

  1. NoSQL:http://nosql-database.org/
  2. NoSQL在wiki上的介紹:http://en.wikipedia.org/wiki/NoSQL
  3. NoSQL相關博客:http://nosql.mypopescu.com/
  4. NoSQL相關博客:http://blog.nosqlfan.com/
  5. 新浪微博NoSQL微群:http://q.t.sina.com.cn/127870

  關于作者

  孫立,目前在鳳凰網負責底層組的研發工作。曾就職于搜狐和ku6。多年互聯網從業經驗和程序開發,對分布式搜索引擎的開發,高并發,大數據量網站系統架構優化,高可用性,可伸縮性,分布式系統緩存,數據庫分表分庫(sharding)等有豐富的經驗,并且對運維監控和自動化運維控制有經驗。開源項目phplock,phpbuffer的作者。近期開發了一個NOSQL數據庫存儲INetDB,是NoSQL數據庫愛好者。他的新浪微博是:http://t.sina.com.cn/sunli1223

2
0
 
標簽:NoSQL
 
 

文章列表

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()