2024年5月17日发(作者：)

ＭｙＳＱＬ￣ｑＭｏｎｇｏＤＢ　

一

视觉中国的ＮｏＳＱＬ之路　

维护量，如何有效监控和管理这些节点又成了新的问题。虽　

■　

文，潘凡　

起因　

人群的专业网站。２００９年以前，同很多公司一样，我们的　

使用７Ｍａｓｔｅｒ＋Ｍａｓｔｅｒ的部署方案；前端使用自己的ｐＨｐ）ｆｉｌ架　

进行开发；Ｍｅｍｃａｃｈｅｄ作为缓存；Ｎｇｉｎｘ进行ＷｅｂｆｉＥ务和负　

载均衡；Ｇｅａｒｍａｎ进行异步任务处理。在传统的基于静态内　

　

视觉中国网站（ｗｗｗ．ｃｈｉｎａｖｉｓｕａ１．ｃｏｍ）是国内最大的创意　

然虚拟化可以解决部分问题，但还是不能令人满意；

除了ＭｙＳＱＬ，能否找到一个更为简单、轻便的瑞士军　

　

ＣＭＳ￣Ｉ：］社区产品都构建于ＰＨＰ＋Ｎｇｉｎｘ＋ＭｙＳＱＬ之上；ＭｙＳＱＬ　

刀呢？我们的目光投向了ＮｏＳＱＬ的方案。

候选方案　

最初，对于ＮｏＳＱＬ的候选方案，我依据关注和熟悉程　

　

容（如文章，资讯，帖子）的产品，这个体系运行良好。通　

度，并且在甄别和选择合适的方案时特别制定了一些原则：

过分级的缓存，数据库端实际负载很轻。２００９年初，我们进　

是否节省系统资源，对于ＣＰＵ等资源是否消耗过大；客户　

行了新产品的开发。此时，我们遇到了如下一些问题。　

端／ＡＰ１支持，这直接影响应用开发的效率；文档是否齐全，　

用户数据激增：我们Ｉ￣ＭｙＳＱＬ某个信息表上线１个月的　

社区是否活跃；部署是否简单；未来扩展能力。按以上几点　

ｓ、ＭｏｎｇｏＤＢ和　

数据就达到千万。我们之前忽略的很多数据，在新形势下需　

经过一段测试后，我们候选名单中剩下Ｒｅｄｉ

要跟踪记录，这也导致了数据量的激增；　

Ｆｌａｒｅ。　

用户对于信息的实时性要求更高：对信息的响应速度　

和更新频度就要求更高。简单通过缓存解决的灵丹妙药不　

复存在；　

是惊人的。因此要求能够无痛的升级扩展，否则一旦停机，　

一

Ｒｅｄｉｓ对丰富数据类型的操作很吸引人，可以轻松解决　

些应用场景，其读写性能也相当高，唯一缺点就是存储能　

力和内存挂钩，这样如果存储大量的数据需要消耗太多的内　

Ｆｌａｒｅ的集群管理能力令人印象深刻，它可以支持节　

点的动态部署，支持节点的基于权重的负载均衡，支持　

　

对于Ｓｃａｌｅ．ｏｕｔ的要求更高：有些创新产品的增长速度　

存（最新的版本已经不存在这个问题）。

那么用户流失的速度也是惊人的；　

大量文件的备份工作：我们面向的是创意人群，产生的　

数据分区。同时允许存储大的数据，其ｋｅｙ的长度也不受　

内容是以图片为主。需要能够对这些图片及不同尺寸的缩略　

Ｍｅｍｃａｃｈｅｄ的限制。而这些对于客户端是透明的，客户端　

ａｒｅ的ｐｒｏｘｙ节点就可以了。由　

图进行有效的备份管理。我们之前使用的Ｌｉｎｕｘ　ｉｎｏｔｉｆｙ＋ｒｓｙｎｃ　

使用Ｍｅｍｃａｃｈｅｄ协议链接到ＦＩ

的增量备份方案效果不佳；　

于使用集群，Ｆｌａｒｅ支持ｆａｉｌ－ｏｖｅｒ，当某个数据节点宕掉，　

ｏｘｙ节点ｆｏｒｗａｒｄ￣０对应的　

需求变化频繁：开发要更加敏捷，开发成本和维护成本　

对于这个节点的访问都会自动被ｐｒ

ａｒｅ的缺点是实际应用　

要更低，要能够快速地更新进化，新功能要在最短的周期内　

后备节点，恢复后还可以自动同步。Ｆｌ

上线。　

案例较少，文档较为简单，目前只在Ｇｅｅｋ使用。　

以上方案都打算作为一个优化方案，我从未想过完全放　

最初，我们试图完全通过优化现有的技术架构来解决　

以上问题：对数据时效性进一步分级分层缓存，减小缓存　

弃ＭｙＳＱＬ。然而，用ＭｏｎｇｏＤＢ做产品的设计原型后，我彻　

　

粒度；改进缓存更新机制（线上实时和线下异步更新）提　

底被征服了，决定全面从ＭｙＳＱＬ迁移到ＭｏｎｇｏＤＢ。

高缓存命中率；尝试对业务数据的特点按照水平和垂直进　

行分表；使用ＭｏｇｉｌｅＦＳ进行分布存储；进一步优化Ｍｙｓｑｌ　

为什么ＭｏｎｇｏＤＢ可以替代ＭｙＳＱＬ？　

ＭｏｎｇｏＤＢ是一个面向文档的数据库，目前由１０ｇｅｎ开发　

的性能，同时增加ＭｙＳＱＬ节点等。但很快发现，即便实　

施了上述方案，也很难完全解决存在的问题：过度依赖　

并维护，它的功能丰富，齐全，完全可以替代ＭｙＳＱＬ。在　

Ｍｅｍｃａｃｈｅｄ导致数据表面一致性的维护过于复杂，应用程　

使用ＭｏｎｇｏＤＢ做产品原型的过程中，我们总结了ＭｏｎｏｇＤＢ　

序开发需要很小心，很多时候出现Ｍｅｍｃａｃｈｅｄ的失效会瞬　

的一些亮点：　

间导致后端数据库压力过大；不同类型数据的特点不同，数　

舍；ＭｏｇｉｌｅＦＳ对我们而言是脚小鞋大，维护成本远远超过了　

使用ＪＳＯＮ风格语法，易于掌握和理解：ＭｏｎｇｏＤＢ使　

ＭｏｎｇｏＤＢ的操作都使用ＪＳＯＮ，５￣．格语法，客户端提交或接收　

据量差别也很大；分表的机制和方式在效率平衡上很难取　用ＪＳＯＮ的变种ＢＳＯＮ作为内部存储的格式和语法。针对　

实际的效益；引入更多的ＭｙＳＱＬ数据库节点增大了我们的　的数据都使用ＪＳＯＮ形式来展现。相对于ＳＱＬ来说，更加直　

２０１０　Ｏ６　７９　

Ｃｏｖｅｒ　Ｓｔｏｒｙ封面报道　

观，容易理解和掌握。　

ＣＲＵＤ更加简单，支持ｉｎ－ｐｌａｃｅ　ｕｐｄａｔｅ：只要定义一个　

Ｓｃｈｅｍａ－Ｉｅｓｓ，支持嵌入子文档：ＭｏｎｇｏＤＢ是一　

数组，然后传递给ＭｏｎｇｏＤＢ的ｉｎｓｅｒｔ／ｕｐｄａｔｅ方法就可自动插　

个Ｓｃｈｅｍａ－ｆｒｅｅ的文档数据库。一个数据库可以有多个　入或更新；对于更新模式，ＭｏｎｇｏＤＢ支持一个ｕｐｓｅ￣选项，　

Ｃｏｌｌｅｃｔｉｏｎ，每个Ｃｏｌｌｅｃｔｉｏｎ是Ｄｏｃｕｍｅｎｔｓ的集合。Ｃｏｌｌｅｃｔｉｏｎ　

即：“如果记录存在那么更新，否则插入”。ＭｏｎｇｏＤＢ的　

和Ｄｏｃｕｍｅｎｔ和传统数据库的Ｔａｂｌｅ和Ｒｏｗ并不对等。无需事　

ｕｐｄａｔｅ方法还支持Ｍｏｄｉｆｉｅｒ，通过Ｍｏｄｉｉｆｅｒ可实现在服务端即　

先定义Ｃｏｌｌｅｃｔｉｏｎ，随时可以创建。　

Ｃｏｌｌｅｃｔｉｏｎ中可以包含具有不同ｓｃｈｅｍａ的文档记录。　

时更新，省去客户端和服务端的通讯。这些ｍｏｄｉｆｅｒ可以让　

ＭｏｎｇｏＤＢ具有和Ｒｅｄｉｓ、Ｍｅｍｃａｃｈｅｄ等ＫＶ类似的功能：较　

这意味着，你上一条记录中的文档有３个属性，而下一条记　之ＭｙＳＱＬ，ＭｏｎｏＤＢ更加简单快速。Ｍｏｄｉｉｆｅｒ也是ＭｏｎｇｏＤＢ　

录的文档可以有１　０个　

可以作为对用户行为跟踪的容器。在实际中使用Ｍｏｄｉｆｉｅｒ来　

属性，属性的类型既可　

将用户的交互行为快速保存￣ｆＪＭｏｎｇｏＤＢ中以便后期进行统　

以是基本的数据类型　计分析和个性化定制。　

（如数字、字符串、日　

曩　２　

苷　

所有的属性类型都支持索引，甚至数组：这可以让某些　

一

期等），也可以是数组　任务实现起来非常的轻松。在ＭｏｎｇｏＤＢ中，“

ｉｄ”属性是　

或者散列，甚至还可以　

主键，默认ＭｏｎｇｏＤＢ会对ｉｄ￣ｌＪ建一个唯一索引。　

是一个子文档（ｅｍｂｅｄ　

ｄｏｃｕｍｅｎｔ）。这样，　

譬　

服务端脚本和ＭａｐｆＲｅｄｕｃｅ：ＭｏｎｇｏＤＢ允许在服务端　

执行脚本，可以用Ｊａｖａｓｃｒｉｐｔ编写某个函数，直接在服务　

用即可。ＭｏｎｇｏＤＢ不支持事务级别的锁定，对于某些需要　

自定义的“原子性”操作，可以使用Ｓｅｒｖｅｒ　ｓｉｄｅ脚本来实　

现，此时整个ＭｏｎｇｏＤＢ处于锁定状态。Ｍａｐ／Ｒｅｄｕｃｅ也是　

ＭｏｎｇｏＤＢ中比较吸引人的特性。Ｍａｐ／Ｒｅｄｕｃｅ可以对大数　

可以实现逆规范化　端执行，也可以把函数的定义存储在服务端，下次直接调　

（ｄｅｎｏ　ｒｍａｌｉｚｉｎｇ）的　

数据模型，提高查询的　

一　一　…　

速度。　

图１　ＭｏｎｇｏＤＢ是一个Ｓｃｈｅｍａ－ｆｒｅｅ的文档数据库　

据量的表进行统计、分类、合并的工作，完成原先ＳＱＬ的　

图２是一个例子，　

ＧｒｏｕｐＢｙ等聚合函数的功能。并Ｉ￣Ｍａｐｐｅｒ和Ｒｅｄｕｃｅｒｌ￣定义　

都是用Ｊａｖａｓｃｒｉｐｔ来定义服务端脚本。　

性能高效，速度快：ＭｏｎｇｏＤＢ使用ｃ＋＋／ｂｏｏｓｔ编写，在　

多数场合，其查询速度对Ｉ；ＬＭｙＳＱＬ要快的多，对于ＣＰＵ占　

用非常小。部署也很简单，对大多数系统，只需下载后二进　

制包解压就可以直接运行，几乎是零配置。　

作品和评论可以设计　

为一个ｃｏｌｌｅｃｔｉｏｎ，评　

论作为子文档内嵌在　

ａ　ｒｔ的ＣＯｍｍｅｎｔｓ属性　

中，评论的回复则作　

为ｃｏｍｍｅｎｔ子文档的　

支持多种复制模式：ＭｏｎｇｏＤＢ支持不同的服务器问进　

行复制，包括双机互备的容错方案。　

Ｍａｓｔｅｒ－Ｓｌａｖｅ是最常见的。通过Ｍａｓｔｅｒ－Ｓｌａｖｅ可以实现数　

据的备份。在我们的实践中，我们使用的是Ｍａｓｔｅｒ－Ｓｌａｖｅ模　

图２　ＭｏｎｇｏＤＢ支持嵌入子文档　

式，Ｓｌａｖｅ只用于后备，实际的读写都是从Ｍａｓｔｅｒ节点执行。　

Ｒｅｐｌｉｃａ　Ｐａｉｒｓ／Ｒｅｐｌｉｃａ　Ｓｅｔｓ允许２个ＭｏｎｇｏＤＢ相互监　

子文档内嵌于ｒｅＰＩｌｅｓ　

属性。按照这种设计　

模式，只需要按照作　

品ｉｄ检索一次，即可获　

得所有相关的信息了。在ＭｏｎｇｏＤＢ中，不强调一定对数据　

　

进行Ｎｏｒｍａｌｉｚｅ，很多场合都建议Ｄｅ－ｎｏｒｍａｌｉｚｅ，开发人员　

听，实现双机互备的容错。

可以扔掉传统关系数据库各种范式的限制，不需要把所有　

的实体都映射为一个Ｃｏｌｌｅｃｔｉｏｎ，只需定义最顶级的ｃｌａｓｓ。　

ＭｏｎｇｏＤＢ的文档模型可以让我们很轻松就能将自己的　

Ｏｂｊｅｃｔ映射￣Ｊｃｏｌｌｅｃｔｉｏｎ中实现存储。　

ＭｏｎｇｏＤＢ只能支持有限的双主模式（Ｍａｓｔｅ卜　

Ｍａｓｔｅｒ），实际可用性不强，可忽略。　

内置ＧｒｉｄＦＳ，支持大容量的存储：这个特点是最吸引　

我眼球的，也是让我放弃其他ＮｏＳＱＬ的一个原因。ＧｒｉｄＦＳ　

ｊｉｆｌｅｓ．　

简单易用的查询方式：ＭｏｎｇｏＤＢ中的查询让人很舒　

具体实现其实很简单，本质仍然是将文件分块后存储￣ｌ

ｉｌｅ和ｆｉｌｅｓ．ｃｈｕｎｋ　２个ｃｏｌｌｅｃｔｉｏｎ中，在各个主流的ｄｒｉｖｅｒ实现　

适，没有ＳＱＬ难记的语法，直接使用ＪＳＯＮ，相当的直观。　

ｆ

ｉｄＦＳ的操作。由于ＧｒｉｄＦＳ自身也是一　

对不同的开发语言，你可以使用它最基本的数组或散列格式　

中，都封装了对于Ｇｒ

进行查询。配合附加的ｏｐｅｒａｔｏｒ，ＭｏｎｇｏＤＢ支持范围查询，　

个Ｃｏｌｌｅｃｔｉｏｎ，你可以直接对文件的属性进行定义和管理，　

正则表达式查询，对子文档内属性的查询，可以取代原来大　

通过这些属性就可以快速找到所需要的文件，轻松管理海量　

的文件，无需费神如何ｈａｓｈ才能避免文件系统检索性能问　

多数任务的ＳＱＬ查询。　

８Ｏ　程序员　

题，结合下面的Ａｕｔ０．ｓｈａｒｄｉｎｇ，ＧｒｉｄＦＳ￣扩展能力是足够　￣

片和各种尺寸的缩略图。　

内置Ｓｈａｒｄｉｎｇ，提供基　

于Ｒａｎｇｅ的Ａｕｔｏ　Ｓｈａｒｄｉｎｇ机　

制：一个ｃｏｌｌｅｃｔｉｏｎ可按照记录　

Ｍａｐ／Ｒｅｄｕｃｅ来完成这种表数据的处理；属性的类型插　

询时用数字１是不匹配的；　

优化ＭｏｎｇｏＤＢ的性能可以　

从磁盘速度和内存着手；　

ＭｏｎｇｏＤＢ对每个Ｄｏｃｕｍｅｎｔ　

的限制是最大不超过４ＭＢ；　

在符合上述条件下多启用　

Ｅｍｂｅｄ　Ｄｏｃｕｍｅｎｔ，避免使　

用ＤａｔａｂａｓｅＲｅｆｅｒｅｎｃｅ；　

我们使用了。在实践中，我们用ＭｏｎｇｏＤＢ￣ＧｒｉｄＦｓ存储图　入和查询时应该保持一致。若插入时是字符串“１”，则查　

的范围，分成若干个段，切分　

到不同的Ｓｈａｒｄ上。Ｓｈａｒｄｓ可　，一　

以和复制结合，配合Ｒｅｐｌｉｃａ　

ｓｅｔｓ￣，够实现Ｓｈａ　ｒｄｉｎｇ＋ｆａ．１－　：　

ｏｖｅｒ，不同的Ｓｈａｒｄ之间可以　

内部缓存可以避免Ｎ＋１次查　

询问题（ＭｏｎｇｏＤＢ不支持　

ｊｏｉｎｓ）。　

用Ｃａｐｐｅｄ　Ｃｏｌｌｅｃｔｉｏｎ　

负载均衡。查询是对客户端是　

透明的。客户端执行查询，统　

计，ＭａｐＲｅｄｕｃｅ等操作，这些　

会被ＭｏｎｇｏＤＢ自动路由到后　

端的数据节点。这让我们关注　

图３　ＭｏｎｇｏＤＢ的Ａｕｔｏ－ｓｈａｒｄｉｎｇ结构　

解决需要高速写入的场合，　

如实时日志；大数据量情况　

于自己的业务，适当的时候可以无痛的升级。ＭｏｎｇｏＤＢ的　下，新建同步时要调高ｏｐｌｏｇＳｉｚｅ的大小，并且自己预先生　

Ｓｈａｒｄｉｎｇ设计能力最大可支持约２０　ｐｅｔａｂｙｔｅｓ，足以支撑一　成数据文件，避免出现客户端超时；Ｃｏｌｌｅｃｔｉｏｎ＋ｌｎｄｅｘ合　

般应用。　

计数量默认不能超过２４０００；当前版本（＜ｖ１．６）删除数据　

第三方支持丰富：　ＭｏｎｇｏＤＢ社区非常活跃，很多开发　

的空间不能被回收，如果你频繁删除数据，那么需要定期　

框架都迅速提供了对ＭｏｎｇＤＢ的支持。不少知名大公司和网　

执行ｒｅｐａｉｒＤａｔａｂａｓｅ，释放这些空间。　

站也在生产环境中使用ＭｏｎｇｏＤＢ，越来越多的创新型企业转　

而使用ＭｏｎｇｏＤＢ作为和Ｄｊａｎｇｏ，ＲｏＲ来搭配的技术方案。　

擎ｉ　ｑ　

结束语　

ＭｏｎｇｏＤＢ的里程碑是１．６版本，预计今年７月份发布，　

届时，ＭｏｎｇｏＤＢ的Ｓｈａｒｄｉｎｇ将首次具备在生产环境中使用　

实施结果　

实施ＭＯｎｏＤＢ的过程是令人愉快的。我们对自己的　的条件。作为ＭｏｎｇｏＤＢ的受益者，我们目前也在积极参与　

ＰＨＰ开发框架进行了修改以适应ＭｏｎｇｏＤＢ。在ＰＨＰ中，对　

ＭｏｎｇｏＤＢ社区活动，改进Ｐｅｒｌ／ＰＨＰ对于ＭｏｎｇｏＤＢ的技术　

ＭｏｎｇｏＤＢ的查询、更新都是围绕Ａｒｒａｙ进行的，实现代码变　

方案。在１．６版本后也将年内推出基于ＭｏｎｇｏＤＢ的一些开源　

得很简洁。由于无需建表，ＭｏｎｏＤＢ运行测试单元所需要的　

项目。　

时间大大缩短，对于ＴＤＤ敏捷开发的效率也提高了。当然，　

对于那些刚刚起步，或者正在开发创新型互联网应用的　

由于ＭｏｎｇｏＤＢ的文档模型和关系数据库有很大不同，在实　公司来说，ＭｏｎｇｏＤＢ的快速、灵活、轻量和强大扩展性，　

践中也有很多的困惑，幸运的是，ＭｏｎｇｏＤＢ开源社区给了　

正适合我们快速开发产品，快速迭代，适应用户迅速变化和　

我们很大帮助。最终，我们使用了２周就完成了从ＭｙＳＱＬ￣０　

更新的种种需求。　

ＭｏｎｇｏＤＢ的代码移植比预期的开发时间大大缩短。从我们　总而言之，ＭｏｎｇｏＤＢ是一个最适合替代ＭｙＳＱＬＩ￣全功　

的测试结果看也是非常惊人，数据量约２千万，数据库３００Ｇ　能的ＮｏＳＱＬ产品，使用ＭｏｎｇｏＤＢ＋Ｐｅｒｌ／ＰＨＰ／Ｄｊａｎｇｏ／ＲｏＲ　

的情况下，读写２０００ｒｐｓ，ＣＰＵ等系统消耗是相当的低（我　的组合将很快成为开发Ｗｅｂ２．０、３．０的产品的最佳组合，就　

们的数据量还偏小，目前陆续有些公司也展示了他们的经典　

像当年ＭｙＳＱＬ替代Ｏｒａｃｌｅ／ＤＢ２／Ｉｎｆｏｒｍｉｘ－－样，历史总是惊　

案例：ＭｏｎｇｏＤＢ存储的数据量已超过５Ｏ亿，＞１．５ＴＢ）。目　

人的相似，让我们拭目以待吧！．置Ｉ　．　

前，我们将ＭｏｎｇｏＤＢ和其他服务共同部署在一起，大大节　

约了资源。　

一

些小提示　

切实领会ＭｏｎｇｏＤＢ￣Ｄｏｃｕｍｅｎｔ模型，从实际出发，扔　

掉关系数据库的范式思维定义，重新设计类；在服务端运行　

Ｉ￣ＪａｖａＳｃｒｉｐｔ代码避免使用遍历记录这种耗时的操作，相反　

一　潘联计Ｐｎ作ｉｅｇ凡合和、ｒｈ者ｌ编ｔ（创底分ｓｎａ程ｉ布始层简ｇｌｅｈ人产式。ｒｔ　ｓｃ介Ｔａ品文，ｏｗｉｍｌ家研件ｅｔ：／ｒ　发存，有Ｎ工储：１　狗＠Ｓ作、２．）Ｎｎ。猫，ｏｉｇ视当。Ｓｈ觉前Ｑｔｓ目Ｌａ关中前、ｉｌｅ国注负高ｒ　网：责性Ｂ站Ａ网能Ｉｏｐ技ｇ站后ｓ：术平现ｈ总ｔ台代ｐ监设的：／，　

２Ｏ１０　０６　８１