MongoDB還存在許多需要改善的地方，比如全局寫鎖（現(xiàn)在僅僅是一個(gè)數(shù)據(jù)庫級的寫鎖）。本文主要關(guān)注如何擴(kuò)展以應(yīng)對大數(shù)據(jù)，這里的大數(shù)據(jù)體積為100GB。
當(dāng)你著眼于底層存儲的實(shí)現(xiàn)時(shí)，它將更有意義?；旧?，MongoDB由一堆BSON文檔mmap（內(nèi)存映射）鏈表組成，它們使用了簡單的B-tree索引，以及作為存儲耐久性機(jī)制的基本日志。最終由OS寫入磁盤，并在頁面中讀取由操作系統(tǒng)加載到內(nèi)存中的數(shù)據(jù)結(jié)果。
最初被稱為殺手級優(yōu)勢的速度方面，其實(shí)只是使用了頁面緩存的效果。很快你就會意識到“這僅僅是mmap”，所有BS架構(gòu)相關(guān)優(yōu)化也只是讓你 的工作集更加適合RAM，如果在分片上進(jìn)行刪除、增加記錄等操作，將會產(chǎn)生重大影響。 OS不知道你正在運(yùn)行數(shù)據(jù)庫，它只是知道你想MMAP一些東西并給它最佳的訪問效果。幸運(yùn)的是，該算法是由一些非常聰明的人寫的，因此只要搜索結(jié)果可以在 緩存命中，運(yùn)行的也不錯，但是OS調(diào)度寫入時(shí)不會考慮你的存儲布局，甚至是你的索引和數(shù)據(jù)之間的差異。這當(dāng)然不能推斷出什么樣的數(shù)據(jù)保持在緩存中或預(yù)先載 入，因?yàn)樗恢滥愕臄?shù)據(jù)是什么或在哪里。
其實(shí)，類似MongoDB Tao這樣的天才有很多，多數(shù)的數(shù)據(jù)庫都使用了一些非常好的想法：Cassandra的一致性協(xié)議，Redis瘋狂的數(shù)據(jù)結(jié)構(gòu)，或Hadoop的數(shù)據(jù)處理 能力。MongoDB擁有mmap，不必設(shè)計(jì)自己的緩存算法或?qū)懭氩呗?，并利用一切盡可能簡單的實(shí)現(xiàn)，讓你快速進(jìn)入市場并專注于你的銷售基準(zhǔn)，應(yīng)對你的競 爭對手，或者并發(fā)學(xué)習(xí)。對比之前，你會更有吸引力。到那個(gè)時(shí)候你可能已經(jīng)變現(xiàn)或者編寫了一個(gè)真正意義上的數(shù)據(jù)庫，在任何情況下，你的客戶都會被鎖定，他們 百依百順以適應(yīng)你的設(shè)計(jì)決策。但是請不要忽視，你正在向Oracle和IBM看齊，這并不是巧合。
就像上文所說，MongoDB還存在許多需要改善的地方。需要關(guān)注的是，當(dāng)你專注于存儲引擎并忽略更廣泛的持久性策略問題，殺手級應(yīng)用應(yīng)該 類似于處理在線游戲中的用戶數(shù)據(jù)：在給定的時(shí)間段中擁有一個(gè)一致的工作集，相對于整個(gè)數(shù)據(jù)庫來說可能很小，讀寫操作都發(fā)生在同一個(gè)工作集上，你有大量的讀 取相對于寫入來說，客戶端為你做了大量的計(jì)算，如果你想獲取更靈活的數(shù)據(jù)結(jié)構(gòu)模式，你可以將其轉(zhuǎn)換成一個(gè)關(guān)系模型，使用類似hstore或JSON列來填 充圖，或者像HBase或者Cassandra那樣使用blobs/text來儲存文檔，但是絕對不會像使用MongoDB那么糟糕。