NoSQL簡介

寫在前面，本文就是學習的記錄筆記，大部分内容都屬于參考，分享給大家

     那麼應該了解下影響關系資料庫性能的主要原因：

     在關系型資料庫中，導緻性能欠佳的最主要因素是多表的關聯查詢，以及複雜的資料分析類型的複雜SQL報表查詢;

     即使不是每個元組都需要所有的字段，但資料庫會為每個元組配置設定所有的字段，這樣的結構可以便于表與表之間進行連接配接等操作，但從另一個角度來說它也是關系型資料庫性能瓶頸的一個因素。

      非關系型資料庫提出另一種理念，以鍵值對存儲，且結構不固定，每一個元組可以有不一樣的字段，每個元組可以根據需要增加一些自己的鍵值對，這樣就不會局限于固定的結構，可以減少一些時間和空間的開銷。使用這種方式，使用者可以根據需要去添加自己需要的字段，這樣，為了擷取使用者的不同資訊，不需要像關系型資料庫中，要對多表進行關聯查詢，僅需要根據id取出相應的value就可以完成查詢。

High performance - 對資料庫高并發讀寫的需求 

　　web2.0網站要根據使用者個性化資訊來實時生成動态頁面和提供動态資訊，是以基本上無法使用動态頁面靜态化技術，是以資料庫并發負載非常高，往往要達到每秒上萬次讀寫請求。關系資料庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫資料請求，硬碟IO就已經無法承受了。其實對于普通的BBS網站，往往也存在對高并發寫請求的需求，例如像JavaEye網站的實時統計線上使用者狀态，記錄熱門文章的點選次數，投票計數等，是以這是一個相當普遍的需求。

Huge Storage - 對海量資料的高效率存儲和通路的需求 

    　　 類似Facebook，twitter，Friendfeed這樣的SNS網站，每天使用者産生海量的使用者動态，以Friendfeed為例，一個月就達到了2.5億條使用者動态，對于關系資料庫來說，在一張2.5億條記錄的表裡面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的使用者登入系統，例如騰訊，盛大，動辄數以億計的帳号，關系資料庫也很難應付。 

High Scalability && High Availability- 對資料庫的高可擴充性和高可用性的需求 

     　　在基于web的架構當中，資料庫是最難進行橫向擴充的，當一個應用系統的使用者量和通路量與日俱增的時候，你的資料庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬體和服務節點來擴充性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對資料庫系統進行更新和擴充是非常痛苦的事情，往往需要停機維護和資料遷移，為什麼資料庫不能通過不斷的添加伺服器節點來實作擴充呢？ 

資料庫事務一緻性需求

資料庫的寫實時性和讀實時性需求 

對複雜的SQL查詢，特别是多表關聯查詢的需求 

滿足極高讀寫性能需求的Kye-Value資料庫：Redis，Tokyo Cabinet， Flare 

滿足海量存儲需求和通路的面向文檔的資料庫：MongoDB，CouchDB 

滿足高可擴充性和可用性的面向分布式計算的資料庫：Cassandra，Voldemort 

     redis是一個key-value存儲系統。和Memcached類似，它支援存儲的value類型相對更多，包括string(字元串)、list(連結清單)、set(集合)和zset(有序集合)、Hash(哈希類型的映射表)。這些資料類型都支援push/pop、add/remove及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。

　　在此基礎上，redis支援各種不同方式的排序。與memcached一樣，為了保證效率，資料都是緩存在記憶體中。差別的是redis會周期性的把更新的資料寫入磁盤或者把修改操作寫入追加的記錄檔案，并且在此基礎上實作了master-slave(主從)同步。Redis 是一個高性能的key-value資料庫。 redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部分場合可以對關系資料庫起到很好的補充作用。Redis的主要缺點是資料庫容量受到實體記憶體的限制，不能用作海量資料的高性能讀寫。

     mongodb是一種分布式文檔存儲資料庫，c++編寫，是基于文檔的存儲的（而非表） 

     mongo主要解決的是海量資料的通路效率問題。因為Mongo主要是支援海量資料存儲的，是以mongo還自帶了一個出色的分布式檔案系統GridFS，可以支援海量的資料存儲。由于Mongo可以支援複雜的資料結構，而且帶有強大的資料查詢功能，是以非常受到歡迎。

　　根據官方的文檔，當資料量達到50GB以上的時候，Mongo的資料庫通路速度是MySQL的10倍以上。Mongo的并發讀寫效率不是特别出色，根據官方提供的性能測試表明，大約每秒可以處理0.5萬－1.5次讀寫請求。

本文轉自cococo點點部落格園部落格，原文連結：http://www.cnblogs.com/coder2012/p/4063790.html，如需轉載請自行聯系原作者