MongoDB还有很多地方需要改进，比如全局写锁（现在只是数据库级别的写锁）。本文主要关注如何扩展处理大数据，其中大数据量为100GB。当您查看底层存储的实现时，它更有意义。基本上，MongoDB由一堆BSON文档的mmap（内存映射）链表组成，使用简单的B树索引和一个基本的日志作为存储持久性机制。最后OS写入磁盘，在页面中读取操作系统加载到内存的数据结果。速度方面，原本被称为杀手级优势，其实只是使用pagecache的效果而已。很快你就会意识到“它只是mmap”，所有BS架构相关的优化只是让你的工作集更适合RAM。如果在shard上删除、添加记录等，都会有很大的影响。操作系统不知道你正在运行一个数据库，它只知道你想要MMAP一些东西并给它最好的访问权限。幸运的是，该算法是由一些非常聪明的人编写的，因此只要搜索结果可以在缓存中命中，它就可以正常工作，但是操作系统在调度写入时没有考虑您的存储布局，甚至没有考虑您的索引和之间的差异数据。这当然不能推断出什么样的数据保存在缓存中或预加载，因为它不知道你的数据是什么或在哪里。其实像MongoDB道的天才很多，而且大部分数据库都使用了一些非常好的想法：Cassandra的一致性协议，Redis的疯狂数据结构，或者Hadoop的数据处理能力。MongoDB有mmap，让你不用自己设计缓存算法，不用写策略，用尽一切，尽可能简单的实现，让你快速进入市场，专注于你的销售标杆，应对你的竞争对手，或并行学习。你会比以前更有吸引力。到那时你可能已经货币化或编写了一个真实的数据库，无论如何你的客户都被锁定并且他们服从你的设计决策。但是请不要忘记，您仰望Oracle和IBM并非巧合。如上所述，MongoDB仍有许多需要改进的地方。需要注意的是，当你专注于存储引擎而忽略更广泛的持久性策略问题时，杀手级应用应该类似于处理在线游戏中的用户数据：在给定的时间段内拥有一致的工作集，相对来说可能对于整个数据库来说很小，读写操作发生在同一个工作集上，你有很多读与写相比，客户端为你做了很多计算，如果你想变得更灵活你可以将它转换为关系模型，使用hstore或JSON列之类的东西来填充图形，或者使用HBase或Cassandra之类的blob/文本来存储文档，但它绝对没有使用MongoDB那么糟糕。
