MongoDB的得与失

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

原文链接: The Genius and Folly of MongoDB