Memcache and Mongodb

轉自：http://www.cnblogs.com/lovecindywang/archive/2010/05/19/1739025.html

先說說自己對Memcache和Mongodb的1些看法，主要是拋磚引玉了，希望看到大家的意見和補充。 

Memcache

Memcache的優勢我覺得總結下來主要體現在：

1） 散布式。可以由10臺具有4G內存的機器，構成1個40G的內存池，如果覺得還不夠大可以增加機器，這樣1個大的內存池，完全可以把大部份熱門業務數據保存進去，由內存來阻擋大部份對http://www.vxbq.cn/db/讀的要求，對http://www.vxbq.cn/db/釋放可觀的壓力。

2） 單點。如果Webhttp://www.vxbq.cn/server/或Apphttp://www.vxbq.cn/server/做負載均衡的話，在各自內存中保存的緩存可能各不相同，如果數據需要同步的話，比較麻煩（各自自己過期，還是分發數據同步？），即便數據其實不需要同步，用戶也可能由于數據的不1致而產生用戶體驗上的不友好。

3） 性能強。不用懷疑和http://www.vxbq.cn/db/相比確切是，本源上還是內存的讀寫和磁盤讀寫效力上幾個數量級的差距。有的時候我們在抱怨http://www.vxbq.cn/db/讀寫太差的情況下可以看看磁盤的IO，如果確切是瓶頸的話裝啥強勁的http://www.vxbq.cn/db/估計也檔不了，強不強不過是這個http://www.vxbq.cn/db/多少充分的利用了內存。

但是也不太建議在任何情況下使用Memcache替換任何緩存：

1） 如果Value特別大，不太合適。由于在默許編譯下Memcache只支持1M的Value（Key的限制到不是最大的問題）。其實從實踐的角度來講也不建議把非常大的數據保存在Memcache中，由于有序列化反序列化的進程，別小視它消耗的CPU。說到這個就要提1下，我1直覺得Memcache合適面向輸出的內容緩存，而不是面向處理的數據緩存，也就是不太合適把大塊數據放進去拿出來處理以后再放進去，而是合適拿出來就直接給輸出了，或是拿出來不需要處理直接用。

2） 如果不允許過期，不太合適。Memcache在默許情況下最大30天過期，而且在內存到達使用限制后它也會回收最少使用的數據。因此，如果我們要把它當作static變量的話就要斟酌到這個問題，必須有重新初始化數據的進程。其實應當這么想，既然是緩存就是拿到了存起來，如果沒有一定有1個重新獲得重新緩存的進程，而不是想著它永久存在。

在使用Memcache的進程中固然也會有1些問題或說最好實踐：

1） 清除部份數據的問題。Memcache只是1個Key/Value的池，1個公共汽車誰都可以上。我覺得對類似的公共資源，如果用的人都依照自己的規則來的話很容易出現問題。因此，最好在Key值的規范上上使用類似命名空間的概念， 每個用戶都能很明確的知道某1塊功能的Key的范圍，或說前綴。帶來的好處是我們如果需要清空的話可以根據這個規范找到我們自己的1批Key然后再去清空，而不是清空所有的。固然有人是采取版本升級的概念，老的Key就讓它過去吧，到時候自然會清空，這也是1種辦法。不過Key有規范總是有好處的，在統計上也方便1點。

2） Value的組織問題。也就是說我們存的數據的粒度，比如要保存1個列表，是1個保存在1個鍵值還是統1保存為1個鍵值，這取決于業務。如果粒度很小的話最好是在獲得的時候能批量獲得，在保存的時候也能批量保存。對跨網絡的調用次數越少越好，可以想1下，如果1個頁面需要輸出100行數據，每個數據都需要獲得1次，1個頁面進行上百次連接這個性能會不會成問題。

那末Memcache主要用在哪些功能上呢？

其實我覺得平時能想到在內存中做緩存的地方我們都可以斟酌下是否是可以去適用散布式緩存，但是主要的用處還是用來在前端或中部擋1下讀的需求來釋放Webhttp://www.vxbq.cn/server/Apphttp://www.vxbq.cn/server/和DB的壓力。

Mongodb

Mongodb是1款比較良好的非關系型http://www.vxbq.cn/db/的文檔型的http://www.vxbq.cn/db/。它的優勢主要體現在：

1） 開源。意味著即便我們不去改也能夠充分發掘它，MS SQL除看那些文檔，誰又知道它內部如何實現。

2） 免費。意味著我們可以在大量垃圾http://www.vxbq.cn/server/上裝大量的實例，即便它性能不怎樣高，也架不住非常多的點啊。

3） 性能高。其它沒比較過，和MS SQL相比，一樣的利用（主要是寫操作）1個撐500用戶就掛了，1個可以撐到2000。在數據量上到百萬以后，即便沒索引，MS SQL的插入性能降落的也1塌胡涂。其實任何事物都有相對性的，在變得復雜變得完善了以后會犧牲1部份的性能，MS SQL體現的是非常強的安全性數據完全性，這點是Mongodb辦不到的。

4） 配置簡單并且靈活。在生產環境中對http://www.vxbq.cn/db/配置故障轉移群集和讀寫分離的http://www.vxbq.cn/db/復制是很常見的需求，MS SQL的配置繁瑣的步驟還是很恐怖的，而Mongodb可以在5分鐘以內配置自己所需要的故障轉移組，讀寫分離更是只需要1分鐘。靈活性體現在，我們可以配置1個M1個S，兩個M1個S（兩個M寫入的數據會合并到S上供讀取），1個M兩個S（1個M寫入的數據在兩個S上有鏡像），乃至是多個M多個S（理論上可以創建10個M，10個S，我們只需要通過輪詢方式隨意往哪一個M上寫，需要讀的時候也能夠輪訓任意1個S，固然我們要知道不可能保證在同1時間所有的S都有1致的數據）。那末也能夠配置兩個M的對作為1套故障轉移群集，然后這樣的群集配置兩套，再對應兩個S，也就是4個M對應2個S，保證M點具有故障轉移。

5） 使用靈活。在之前的文章中我提到乃至可以通過SQL到JS表達式的轉換讓Mongodb支持SQL語句的查詢，不管怎樣說Mongodb在查詢上還是很方便的。

之前也說過了，其實不是所有http://www.vxbq.cn/db/利用都使用采取Mongodb來替換的，它的主要缺點是：

1） 開源軟件的特點：更新快，利用工具不完善。由于更新快，我們的客戶端需要隨著它的更新來升級才能享遭到1些新功能，更新快也意味著極可能在某1階段會缺少某個重要功能。另外我們知道MS SQL在DEV/DBA/ADM多個維度都提供了非常好的GUI工具對http://www.vxbq.cn/db/進行保護。而Mongodb雖然提供了1些程序，但是其實不是非常友好。我們的DBA可能會很愁悶，去優化Mongodb的查詢。

2） 操作事務。Mongodb不支持內建的事務（沒有內建事務不意味著完全不能有事務的功能），對某些利用也就不合適。不過對大部份的http://www.vxbq.cn/Internet/利用來講其實不存在這個問題。

在使用Mongodb的進程中主要遇到下面的問題：

1） 真實的橫向擴大？在使用Memcache的進程中我們已體會到這類爽了，基本可以無窮的增加機器來橫向擴大，由于甚么，由于我們是通過客戶端來決定鍵值保存在那個實例上，在獲得的時候也很明確它在哪一個實例上，即便是1次性獲得多個鍵值，也是一樣。而對http://www.vxbq.cn/db/來講，我們通過各種各樣的方式進行了Sharding，不說其它的，在查詢的時候我們根據1定的條件獲得批量的數據，怎樣樣去處理？比如我們依照用戶ID去分片，而查詢根本不在意用戶ID，在意的是用戶的年齡和教育程度，最后依照姓名排序，到哪里去取這些數據？不論是基于客戶端還是基于服務真個Sharding都是非常難做的，并且即便有了自動化的Sharding性能不1定能有保障。最簡單的是盡可能依照功能來分，再下去就是歷史數據的概念，真正要做到實時數據分散在各個節點，還是很困難。

2） 多線程，多進程。在寫入速度達不到預期的情況下我們多開幾個線程同時寫，或多開幾個Mongodb進程（同1機器），也就是多個http://www.vxbq.cn/db/實例，然后向不同的實例去寫。這樣是不是能提高性能？很遺憾，非常有限，乃至可以說根本不能提高。為何使用memcache的時候多開線程可以提高寫入速度？那是由于內存數據交換的瓶頸我們沒到達，而對磁盤來講，IO的瓶頸每秒那末幾10兆的是很容易到達的，1旦到達這個瓶頸了，不管是開多少個進程都沒法提高性能了。還好Mongodb使用內存映照，看到內存使用的多了，其實我對它的信心又多了1點（內存占用多了我覺得CPU更容易讓它不閑著），怕就怕某個DB不使用甚么內存，看著IO瓶頸到了，內存和CPU還是吃不飽。

Memcache和Mongodb的配合

其實有了Memcache和Mongodb我們乃至可讓80%以上的利用擺脫傳統關系型http://www.vxbq.cn/db/。我能想到它們其實可以相互配合彌補對方的不足：

Memcache合適根據Key保存Value，那末有的時候我們其實不知道需要讀取哪些Key怎樣辦呢？我在想是否是可以把Mongodb或說http://www.vxbq.cn/db/當作1個原始數據，這份原始數據中分為需要查詢的字段（索引字段）和普通的數據字段兩部份，把大量的非查詢字段保存在Memcache中，小粒度保存，在查詢的時候我們查詢http://www.vxbq.cn/db/知道要獲得哪些數據，1般查詢頁面也就顯示20⑴00條吧，然后1次性從Memcache中獲得這些數據。也就是說，Mongodb的讀的壓力主要是索引字段，而數據字段只是在緩存失效的時候才有用，使用Memcache擋住大部份實質數據的查詢。反過來講，如果我們要清空Memcache中的數據也知道要清空哪些Key。

附錄：

對Memcached本身對value值大小的限制，筆者在這里單獨強調下，踩過坑。可以查看這個文章：http://blog.csdn.net/billfeller/article/details/17200245

案例分析：公司使用LimeSurvey開源問卷調查系統進行用戶調查，但是上線1段時間后出現用戶明白提交了問題答案，系統卻總是提示該題必填，追蹤結果表明是由于LimeSurvey把大量問卷相干信息寫到會話時，而php會話配置是存儲到memcached的，當信息超過1M時就會出現數據丟失，致使系統認為用戶未提交問題，所以需要強調下Memcached使用方法――Memcached只是散布式緩存，請盡可能不要將其做為數據容器進行業務數據存儲。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈