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那么糟糕。