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