MongoDB的得與失

　　MongoDB還存在許多需要改善的地方，比如全域性寫鎖（現在僅僅是一個資料庫級的寫鎖）。本文主要關注如何擴充套件以應對大資料，這裡的大資料體積為100GB。

　　當你著眼於底層儲存的實現時，它將更有意義。基本上，MongoDB由一堆BSON文件mmap（記憶體對映）連結串列組成，它們使用了簡單的B-tree索引，以及作為儲存耐久性機制的基本日誌。最終由OS寫入磁碟，並在頁面中讀取由作業系統載入到記憶體中的資料結果。

　　最初被稱為殺手級優勢的速度方面，其實只是使用了頁面快取的效果。很快你就會意識到“這僅僅是mmap”，所有BS架構相關優化也只是讓你的工作集更加適合RAM，如果在分片上進行刪除、增加記錄等操作，將會產生重大影響。 OS不知道你正在執行資料庫，它只是知道你想MMAP一些東西並給它最佳的訪問效果。幸運的是，該演算法是由一些非常聰明的人寫的，因此只要搜尋結果可以在快取命中，執行的也不錯，但是OS排程寫入時不會考慮你的儲存佈局，甚至是你的索引和資料之間的差異。這當然不能推斷出什麼樣的資料保持在快取中或預先載入，因為它不知道你的資料是什麼或在哪裡。

　　其實，類似MongoDB Tao這樣的天才有很多，多數的資料庫都使用了一些非常好的想法：Cassandra的一致性協議，Redis瘋狂的資料結構，或Hadoop的資料處理能力。MongoDB擁有mmap，不必設計自己的快取演算法或寫入策略，並利用一切儘可能簡單的實現，讓你快速進入市場並專注於你的銷售基準，應對你的競爭對手，或者併發學習。對比之前，你會更有吸引力。到那個時候你可能已經變現或者編寫了一個真正意義上的資料庫，在任何情況下，你的客戶都會被鎖定，他們百依百順以適應你的設計決策。但是請不要忽視，你正在向Oracle和IBM看齊，這並不是巧合。

　　就像上文所說，MongoDB還存在許多需要改善的地方。需要關注的是，當你專注於儲存引擎並忽略更廣泛的永續性策略問題，殺手級應用應該類似於處理線上遊戲中的使用者資料：在給定的時間段中擁有一個一致的工作集，相對於整個資料庫來說可能很小，讀寫操作都發生在同一個工作集上，你有大量的讀取相對於寫入來說，客戶端為你做了大量的計算，如果你想獲取更靈活的資料結構模式，你可以將其轉換成一個關係模型，使用類似hstore或JSON列來填充圖，或者像HBase或者Cassandra那樣使用blobs/text來儲存文件，但是絕對不會像使用MongoDB那麼糟糕。

　　原文連結： The Genius and Folly of MongoDB