MogoDB--http://www.infoq.com/cn/interviews/pf-mongodb-develop

您好，谢谢您作为QCon的演讲嘉宾为观众带来了精彩的演讲，也谢谢您接受我们的访问。首先请您简单地介绍一下自己，以及现在一些工作的状况？

    大家好，我叫潘凡，我来自视觉中国网站，我现在在视觉中国主要从事一些网站的架构，还有一些底层数据技术方案的研究和管理工作。   

您这次演讲的主题是视觉中国MongoDB的应用实践，针对这个主题我想问一下，视觉中国为什么会选择MongoDB呢？

    视觉中国选择MongoDB实际上是有一个过程，最初我们是想选择一个KV的方案。在选择KV的过程中，偶然发现MongoDB，然后就对MongoDB的特性做了一些研究，最后非常惊奇地发现，MongoDB的一些特性正好符合我们的要求。因为我们视觉中国网站本身不是一个大公司，是一个中小规模的公司，网站的数据量不大不小。MongoDB它比较简单、实用，运维方面也比较简单。这样会减轻我们团队的压力，所以我们最终选择了MongoDB。   

你是说主要是基于业务应用数据量不算特别大，又易维护这样的一些特性？

    对，因为MongoDB实际上是一个文档型数据库，这种模式与普通传统的比如关系型数据库不一样，与普通的基于简单KV的这种数据库也不太一样，它正好处在中间，就是能够既有KV的灵活性，又有MySQL那些关系型数据库大部分的操作，尤其是针对互联网的应用，我觉得在开发方面它提升了开发的效率。在使用MongoDB的过程中我们发现，你可以基于你所使用的开发语言中最基本的一些内容，例如数据类型像数组、散列，基于这种形式去做一些查询、更新，还有删除的工作，而不用再去研究SQL优化这样的东西。   

根据我了解的资料，视觉中国之前采用的MySQL，在从MySQL到MongoDB的迁移过程中，是怎样的执行过程呢？

    实际上我们是分了好几个阶段，在初期是MySQL和MongoDB并行，但是这个时间不长，大概也就两个月。之后就把它切到了MongoDB上，我们是从一个小产品，一个叫原创网的小产品，把它做为使用MongoDB生产环境的一个测试。三到六个月以后，我们把剩余的一些主要产品陆陆续续地切到了MongoDB上。实际上这个切换的过程持续了一年多，我们经历了MongoDB的版本从最早0.9版到最近的1.6版，当然现在新的1.8版本我们还没有使用。   

目前MongoDB客户端的支持做得怎么样？

MongoDB最主要的官方客户端，主要有这几种比较好，Ruby的、PHP的，还有Perl的。最好的两个，一个是Ruby的，一个PHP的。从它一开始出来，这两个就做为官方支持的客户端，后来加入了一个Perl的。到现在，它的客户端已经很丰富了。官方最近把.NET也加进来了，其他的，我们能想到那些常用的小语种，可能都会有，例如像Node.js都有客户端。   

好的，今天我们的访问就到这里，谢谢你接受我们的访问，谢谢。

    谢谢。   

也就是说MongoDB它有很丰富的客户端？适用大小各种语言？

    对，在09年之前，它的客户端相对来说少一点。但是在去年一年，它的各种客户端出来的特别快，基本上现可以说大多数的客户端都有，而且都处于一种活跃的状态。   

其实MongoDB它客户端方面做得是比较好的。除了客户端这方面，MongoDB在性能方面的表现怎么样呢？

MongoDB的单机性能现在看其实不错，稳定性也挺好。我们自己在使用的时候，它对于资源的消耗小，CPU都占的很小。一般像我们自己的服务，MongoDB并不是一个独立服务器，往往和其他一些应用服务器，或者是一些Web Server混在一起，而且一般是一台物理机器会放大概四到五个实例。数据量方面，因为现在是我们自己控制它的数据量，在每一个组里，数据量大概是六七百万到七八千万。   

在性能这方面，你们有一些实测数据吗？

    现在我们每天繁忙的时候，每天大概一万到两万QBS，这是很常见的，再高一点，实际上几十万也做过，但是那个数据是比较有限的。现在在生产上，可能因为前端也做了一些限制，相对原先我们自己的MySQL来说，吞吐量有一点提升。   

MongoDB有一个特点，就是处理较大的并发，它是怎么去做的？在运行的稳定性方面表现得怎么样？

    其实它所谓处理较大并发，可能一方面它是去掉了原先我们发现数据库的比如很多事务和一些限制；另外它锁的使用几率相对小一点。在稳定性上，说实在的，MongoDB自身的稳定性，从单机来看还不是太高。它的稳定性是通过集群，通过这种主从，或是现在叫ReplicaSet的这种模式来保证的。1.8版以后，增加了一个写文件，能够提高单机的可靠性。但是可能这点上做得比MySQL要弱一些。   

其实它相对来说一种是用备份的方式，另外一种是用预读后写的方式？

    对，但是因为这种预读刚刚实现，或多或少还会有一些问题，比如刚发布的时候，它修复了Memory use在预写的时候索引不正常。所以可能对于单机问题，MongoDB的确有这样的弱点，现在它是一个弱点，但我相信在2.0以后，可能这部分就不会是一个大问题了。   

MongoDB在文件系统方面使用的是GridFS吗？

    不是，GridFS其实只是它的一个标准。   

是它的一个标准？

    因为MongoDB中是使用GridFS来做存储的，它有一部分限制，就是单个文档不能超过4兆，在1.8版以后把这个限制扩展到8兆。这样的话，如果我们希望在数据库中存比较大的文件，比如，它不像传统关系数据库中一个BLOG类似的字段，它只能使用GridFS这个标准了。它的本质是把大于4兆的数据给你切成一片一片的，分成了两个collection把它插进去。但是这个一般是怎么实现的呢，其实服务端并不实现，而是通过你的驱动，也就是客户端去实现。   

客户端，对吗？

    对。   

它是一个文件存储的、处理数据的方式，是这样的吗？

    只能说它是能够存储超过4兆大小文件的一个处理方法。只不过派生出来说，存储一般的文件也是没有问题的，就是中小规模的文件。   

MongoDB在视觉中国已经使用一段时间了，在MongoDB使用和开发的过程中，你有什么经验和教训可以和大家分享呢？

    教训挺多的。经验吗，其实我刚才PPT中也讲了一些，我们认为可能比较严重的教训有一点，就是说MongoDB本身它还算比较年轻的一个产品，所以它的问题，就是成熟度肯定没有传统MySQL那么成熟稳定。所以在使用的时候，第一，尽量使用稳定版，不要在线上使用开发版，这是一个大原则；另外一点，备份很重要，MongoDB如果出现一些异常情况，备份一定是要能跟上。除了通过传统的复制的方式来做备份，离线备份也还是要有，不管你是用什么方式，都要有一个完整的离线备份。往往最后出现了特殊情况，它能帮助到你；另外，MongoDB性能的一个关键点就是索引，索引是不是能有比较好的使用效率，索引是不是能够放在内存中，这样能够提升随机读写的性能。如果你的索引不能完全放在内存中，一旦出现随机读写比较高的时候，它就会频繁地进行磁盘交换，这个时候，MongoDB的性能就会急剧下降，会出现波动。另外，MongoDB还有一个最大的缺点，就是它占用的空间很大，因为它属于典型空间换时间原则的类型。那么它的磁盘空间比普通数据库会浪费一些，而且到目前为止它还没有实现在线压缩功能，在MongoDB中频繁的进行数据增删改时，如果记录变了，例如数据大小发生了变化，这时候容易产生一些数据碎片，出现碎片引发的结果，一个是索引会出现性能问题，另外一个就是在一定的时间后，所占空间会莫明其妙地增大，所以要定期把数据库做修复，定期重新做索引，这样会提升MongoDB的稳定性和效率。在最新的版本里，它已经在实现在线压缩，估计应该在2.0版左右，应该能够实现在线压缩，可以在后台执行现在repair DataBase的一些操作。如果那样，就解决了目前困扰我们的大问题。   

根据你的说明，其实在视觉中国使用MongoDB的过程中，还是在性能和一些开发版与正式版的版本方面是有一些经验教训的。

    对，非常多，因为MongoDB毕竟是比较新的东西，而且在我们刚开始使用的时候，相关的资源比较少，资料不齐全，包括MongoDB的手册也不是很齐全，很多时候问题解决不了，你只能通过阅读它的源码来找问题。现在可能不会那么复杂了，各种各样的应用案例，各种各样的分享PPT都有，而且它自身的一些文档，包括中文版现在也有很多人在翻译，书籍也出了两本，所以我觉得现在来说，MongoDB的学习过程会更简单一点。