MongoDB還存在許多需要改善的地方，比如全局寫鎖(現(xiàn)在僅僅是一個數(shù)據(jù)庫級的寫鎖)。本文主要關(guān)注如何擴(kuò)展以應(yīng)對大數(shù)據(jù)，這里的大數(shù)據(jù)體積為100GB。

當(dāng)你著眼于底層存儲的實現(xiàn)時，它將更有意義?；旧?，MongoDB由一堆BSON文檔mmap(內(nèi)存映射)鏈表組成，它們使用了簡單的B-tree索引，以及作為存儲耐久性機制的基本日志。最終由OS寫入磁盤，并在頁面中讀取由操作系統(tǒng)加載到內(nèi)存中的數(shù)據(jù)結(jié)果。

最初被稱為殺手級優(yōu)勢的速度方面，其實只是使用了頁面緩存的效果。很快你就會意識到“這僅僅是mmap”，所有BS架構(gòu)相關(guān)優(yōu)化也只是讓你的工作集更加適合RAM，如果在分片上進(jìn)行刪除、增加記錄等操作，將會產(chǎn)生重大影響。 OS不知道你正在運行數(shù)據(jù)庫，它只是知道你想MMAP一些東西并給它***的訪問效果。幸運的是，該算法是由一些非常聰明的人寫的，因此只要搜索結(jié)果可以在緩存命中，運行的也不錯，但是OS調(diào)度寫入時不會考慮你的存儲布局，甚至是你的索引和數(shù)據(jù)之間的差異。這當(dāng)然不能推斷出什么樣的數(shù)據(jù)保持在緩存中或預(yù)先載入，因為它不知道你的數(shù)據(jù)是什么或在哪里。

其實，類似MongoDB Tao這樣的天才有很多，多數(shù)的數(shù)據(jù)庫都使用了一些非常好的想法：Cassandra的一致性協(xié)議，Redis瘋狂的數(shù)據(jù)結(jié)構(gòu)，或Hadoop的數(shù)據(jù)處理能力。MongoDB擁有mmap，不必設(shè)計自己的緩存算法或?qū)懭氩呗?，并利用一切盡可能簡單的實現(xiàn)，讓你快速進(jìn)入市場并專注于你的銷售基準(zhǔn)，應(yīng)對你的競爭對手，或者并發(fā)學(xué)習(xí)。對比之前，你會更有吸引力。到那個時候你可能已經(jīng)變現(xiàn)或者編寫了一個真正意義上的數(shù)據(jù)庫，在任何情況下，你的客戶都會被鎖定，他們百依百順以適應(yīng)你的設(shè)計決策。但是請不要忽視，你正在向Oracle和IBM看齊，這并不是巧合。

就像上文所說，MongoDB還存在許多需要改善的地方。需要關(guān)注的是，當(dāng)你專注于存儲引擎并忽略更廣泛的持久性策略問題，殺手級應(yīng)用應(yīng)該類似于處理在線游戲中的用戶數(shù)據(jù)：在給定的時間段中擁有一個一致的工作集，相對于整個數(shù)據(jù)庫來說可能很小，讀寫操作都發(fā)生在同一個工作集上，你有大量的讀取相對于寫入來說，客戶端為你做了大量的計算，如果你想獲取更靈活的數(shù)據(jù)結(jié)構(gòu)模式，你可以將其轉(zhuǎn)換成一個關(guān)系模型，使用類似hstore或JSON列來填充圖，或者像HBase或者Cassandra那樣使用blobs/text來儲存文檔，但是絕對不會像使用MongoDB那么糟糕。