MongoDB - 它是什嗎？從哪裡來？

標籤：style   blog   http   color   os   使用   java   strong   ar   

    適合讀者： 對於MongoDB目前尚未有整體認識的初學者。在這裡本ID將作一個簡要的介紹：

二、MongoDB簡介

MongoDB是一個高效能，開源，無模式的文檔型資料庫，是當前NoSql資料庫中比較熱門的一種。它在許多情境下可用於替代傳統的關係型資料庫或鍵/值儲存方式。Mongo使用C++開發。Mongo的官方網站地址是：http://www.mongodb.org/，讀者可以在此獲得更詳細的資訊。 

小插曲：什麼是NoSql？

NoSql，全稱是 Not Only Sql,指的是非關係型的資料庫。下一代資料庫主要解決幾個要點：非關係型的、分布式的、開源的、水平可擴充的。原始的目的是為了大規模web應用，這場運動開始於2009年初，通常特性應用如：模式自由、支援簡易複製、簡單的API、最終的一致性（非ACID）、大容量資料等。NoSQL被我們用得最多的當數key-value儲存，當然還有其他的文檔型的、列儲存、圖型資料庫、xml資料庫等。

特點:

高效能、易部署、易使用，儲存資料非常方便。主要功能特性有：

面向集合儲存，易儲存物件類型的資料。

模式自由。

支援動態查詢。

支援完全索引，包含內部對象。

支援查詢。

支援複製和故障恢複。

使用高效的位元據儲存，包括大型物件（如視頻等）。

自動處理片段，以支援雲端運算層次的擴充性

支援Python，PHP，Ruby，Java，C，C#，Javascript，Perl及C++語言的驅動程式，社區中也提供了對Erlang及.NET等平台的驅動程式。

檔案儲存體格式為BSON（一種JSON的擴充）。

可通過網路訪問。

功能:

面向集合的儲存：適合儲存物件及JSON形式的資料。

動態查詢：Mongo支援豐富的查詢運算式。查詢指令使用JSON形式的標記，可輕易查詢文檔中內嵌的對象及數組。

完整的索引支援：包括文檔內嵌對象及數組。Mongo的查詢最佳化工具會分析查詢運算式，並產生一個高效的查詢計劃。

查詢監視：Mongo包含一個監視工具用於分析資料庫操作的效能。

複製及自動容錯移轉：Mongo資料庫支援伺服器之間的資料複製，支援主-從模式及伺服器之間的相互複製。複製的主要目標是提供冗餘及自動容錯移轉。

高效的傳統儲存方式：支援位元據及大型物件（如照片或圖片）

自動分區以支援雲層級的伸縮性：自動分區功能支援水平的資料庫叢集，可動態添加額外的機器。

適用場合:

網站資料：Mongo非常適合即時的插入，更新與查詢，並具備網站即時資料儲存所需的複製及高度伸縮性。

緩衝：由於效能很高，Mongo也適合作為資訊基礎設施的緩衝層。在系統重啟之後，由Mongo搭建的持久化緩衝層可以避免下層的資料來源 過載。

大尺寸，低價值的資料：使用傳統的關係型資料庫儲存一些資料時可能會比較昂貴，在此之前，很多時候程式員往往會選擇傳統的檔案進行儲存。

高伸縮性的情境：Mongo非常適合由數十或數百台伺服器組成的資料庫。Mongo的路線圖中已經包含對MapReduce引擎的內建支援。

用於對象及JSON資料的儲存：Mongo的BSON資料格式非常適合文檔化格式的儲存及查詢。

在國內的整體環境之中，MongoDB在中小類型的公司之中，其流向程度遠超其他Nosql.

一旦您的業務擴充迅速，業務資料變大，請您先參閱如下位置：

 http://news.cnblogs.com/n/121155/

　為什麼不？

　　1）MongoDB 為了贏得 Benchmark 測試而預設使用了不安全的寫方式

　　如果你不調用 getLastError ()，MongoDB 就不會在確認資料庫寫操作完成就返回了，這會引入至少兩種問題：

在並發的環境下（串連池等），在一個讀操作“完成”後的連續地讀操作會出錯，MongoDB 沒有“柵欄條件鎖”來知道什麼時候完成寫。

未知個數的儲存操作會被丟棄，因為儲存操作的隊列會在不同的地方。比如 TCP 緩衝等。當你和資料庫連接因為一些意味情況斷開的時候，這些東西就被丟棄了。

10gen CTO 回複： 這和 Benchmark 沒有任何關係，並說這個就是 API 的設計，其交給使用者自己去選擇，因為寫的方式也有很多種。

　　2）MongoDB 會以令人震驚的方式遺失資料

　　下面是一個我們所經曆過的它丟資料的列表：

資料就是丟了，原因未知。

從損壞的資料庫中恢複資料不成功，如交易記錄。

主從結點間的資料複製有缺口，導致“從結點”丟失“主結點”有的資料。是的，沒有 CheckSum，並且是的，你還會看到複製狀態為“從結點”的目前狀態。

資料複製有時會停了，沒有錯誤。你要監控你的複製狀態！

10gen CTO 逐一回複：1）從來沒有一個資料丟失的 BUG 我們沒有馬上 fix 的事情。你能告訴我你報給我們的問題號嗎？我們至少要明白是怎麼一回事。如果是我們的問題，我們會馬上 fix 的。2）從損壞了的資料庫中不能完全恢複資料 ，這不挺正常的嗎？但是如果有主從伺服器互為備份應該會好一些。3）請告訴我你的問題號，我們從來沒有接到過這樣的錯誤報表。如果有，的確很嚴重。4）如果是說錯誤條件發生的時候沒有通知，這有可能。另外，你可以監控資料複製的寫操作，你可以使用 w=2 為 getLastError 的參數。

　　3）MongoDB 需要全域寫鎖來請求寫操作

　　在寫操作頻繁的時候，這等同於殺了你。如果你運行一個 blog，你也許不會關心這個事，因為你的讀寫操作不高。

10gen CTO 回複：讀寫鎖永遠都是問題，但是2.0會好很多，2.2會解決得更好一些。

　　4）MongoDB 的 Sharding (分區) 在高負載下會停止工作

　　在高負載下加一個 shard 是一場惡夢。Mongo 要麼會移動其資料區塊太快而導致 DOS 攻擊產生很多流量佔用頻寬，要麼就完全地拒絕更多的資料區塊。這會使一個高流量的網站承受著沉重地寫操作。

10gen CTO 回複：如果系統已經超過了其負載，那麼移動資料當然會變得很難。我每一次的演講都說得很清楚，不要在系統效能不行的時候才去加 shard，這不行的。

　　5）Mongo 不可靠

　　Mongod/設定管理員/mongos 的架構確實合理且聰明。不幸的是，mongos 完全就是垃圾。在有負載的情況下，它時不時就都會崩潰，有時幾個小時，有時幾天。進程重啟監控有時也不管用，因為它會拋出一些斷言偽造出一個關鍵線程，導致進程還在運行。Double Fail。

　　最壞的是，唯一可行的方式是在一堆 mongos 執行個體前放一個 HaProxy (一種負載平衡器)，運行一個作業緩慢地輪著訪問這些 mongos 執行個體，並定期 kill 掉他們，以便可以重新啟動新的執行個體。我沒有在開玩笑。

10gen CTO 回複：不可能有這種事，你能不能告訴我更多的細節？

　　6）MongoDB 有一次甚至刪除了整個資料庫

　　MongoDB 1.6，在資料同步配置中，有時會配置了一個錯誤的結點（經常是一個空結點）作為一個最新的資料結點。於是其它同步資料的結點上的資料就這樣被幹掉了（我說的是700GB 的好資料），因為其把這個空結點的資料同步回有資料的結點上。資料庫永遠永遠都不應該幹這個。如果出現這種問題，資料庫應該拋出一個錯誤而讓 DBA 來選擇合理的操作，或是強制使用正確的配置。而不應該刪除所有的資料（那天真是太糟糕了）。

　　他們在1.8中修複了這個問題，偶滴神啊。

10gen CTO 回複：找不到這樣的事，也找不到相應提交的代碼，你能多給點資訊嗎？

　　7）發布了一些不應該發布東西

　　眾所周知，在穩定版裡能找到一些尷尬的 bug 會導致資料問題——而我們總是在出了問題後他們才告訴我們這些問題，這是因為我們購買了 10gen 他們那超級詐騙的白金支援人員。他們回應是，發給我們一個 hot patch，他們內部叫 RC 的玩意，然後讓這個 hot patch 運行在我們的資料上。

10gen CTO 回複：關於白金的支援人員，我們所接手的所有問題都會公開，fix 也會公開。沒有特定的情景，這種事很難討論。我們會根據不同的情況作出不同的反應。我們希望我們的使用者的問題能儘快得到解決。

　　8）複製器在繁忙的伺服器上黯然失色

　　複製器經常性的向 Master 發起 DOS 攻擊，或是複製非常慢，花了巨長無比的時間，而 oplog 幾乎被耗盡（就算是 50GB 的 oplog）。

　　我們有一個繁忙的，大的資料集，我們不會複製它，因為它是動態。那是令人痛苦的一個月，或是我們需要在選擇不同的資料庫系統前交叉雙指（註：好運的手勢）

10gen CTO 回複：這看起來像上伺服器負載過重了。我前面提到過了。

　　但是最糟糕的問題是：

　　你可能會說，我這些問題都是過去式了；他們修複了所有這些問題或是他們會在下一版本中修複這些問題；X問題可以用Y實踐來減輕。等等，等等。

　　不幸的是，你說這些東西一點用也沒有。

　　真正的問題是，這麼多的問題都是首要的問題。 資料庫開發人員要能 hold 住比一般程式員更高的標準。也就是說，你的優先順序應該像下面這個樣子：

別搞丟資料，對資料要有完全的把握

通過實踐保證可用性

多結點的效能擴充性

最小延遲應該保持在99%和95%之間

每個資源的每秒請求數

　　10gen 的順序好像是 #5 為第一，其它項隨便，#1 並不在前3位。

10gen CTO 回複：這明顯不是真的。看一看我們提交的代碼，看一看我們的 fix。 我們從來不會在 release 版中隱藏一個 bug。如果我們非常在乎效能的 benchmark 的話，我們會花精力解決那些鎖的問題，這樣一來，多線程並發會更快一些。

MongoDB 是一個新生的東西，還有很多東西需要打磨。如果你想來認識一下我們，我們歡迎你來認識一下我們。

　　這些失敗，還有那所暗示的公司的優先順序，指出了一個最基本的企業文化的問題，其會讓問題出現在任一發布版中：因為他們缺乏尊守必要的資料庫系統的設計律條。

　　請謹慎考慮這些警告。

MongoDB - 它是什嗎？從哪裡來？