MongoDB 3.2中的最新功能 第二部分：对关键型应用的新支持

欢迎来到MongoDB 3.2 博客系列的第二部分。

• 在第一部分，我们介绍了新的存储引擎及它们支持的新用例
• 在第三部分，我们将介绍支持数据分析师、数据库管理员及运维团队的新工具和集成。

在这篇博客中，我们将介绍专为支持任务关键型应用而设计的功能，包括文档验证及改进的复制集协议。记住，您可以通过下载 最新功能白皮书 来了解MongoDB 3.2提供的所有功能细节。

文档验证：动态模式的数据管理

动态模式提供了极大的灵活性，但是控制数据的质量也非常重要，特别是：数据库支撑着多个应用或者被集成到更大的数据管理平台，需要连接到上下游系统的情况下。与其将这些控制的实现放到应用代码中，MongoDB可以在数据库中提供文档验证。用户可以在文档结构、数据类型、数据范围及必须字段这些方面进行强制验证。因此，在数据库管理员可以运用数据管理标准的同时，让开发人员能够继续保持灵活文档模型的优势。

MongoDB 3.2中的文档验证

用户拥有很大的灵活性自定义对任意集合中的文档部分是否进行验证。对于任何合适用于检测的键：

• 确实存在
• 如果确实存在，对应的值必须是正确的类型
• 对应的值是特定的格式（正则表达式可用于检测字符串的内容是否匹配特定的模式-例如，是否为正确格式的邮箱地址）
• 对应的值落在给定的范围内

作为一个示例，下面的片段向contact集合中添加了一条规则，用于验证：

• 出生年份晚于1994年
• 文档中包括一个电话号码以及/或者一个电子邮箱地址
• 当出现相应的字段时，电话号码及电子邮箱地址都是字符串

db.runCommand({

collMod: "contacts",

validator: {

$and: [

{year_of_birth: {$lte: 1994}},

{$or: [

{phone: { $type: "string" }},

{email: { $type: "string" }}

]}]

}})

由于文档验证使用的是标准的MongoDB查询语言，向一个集合中添加一个验证规则对任何熟悉MongoDB的开发人员和数据库管理员而言都是非常直观的。

请查阅文档验证博客或者 文档，了解关于这个功能更深入的讨论，包括代码示例及指南。

改进的复制集协议：更快的故障转移和更严格的持久性保证

在分布式系统（例如：MongoDB）中，应该假定单个节点可能并且将会出现故障。在一个节点出现故障时，MongoDB的优先级如下：

• 确保数据的一致性
• 尽快恢复完整的服务以最大化可用性

MongoDB 3.2引入了一个改进的复制集协议，能够在面临主节点出现故障时提供更快的服务恢复以及更严格的持久性保证。改进的复制集协议拓展了Raft一致性算法，在维护之前MongoDB版本中提供的复制集构建兼容性的同时，提供了更高的部署灵活性。详细说来，该协议维护了对复制集仲裁节点、复制集成员选举优先级以及 从节点成员 从其它从节点复制以提供链式复制的支持。

改进的复制集协议通过优化用于检测复制集主节点故障和选举新主节点的算法来降低故障恢复间隔。故障恢复时间由一些因素决定，包括网络延迟等。对系统而言，避免不必要的故障恢复以及为不同部署需求提供灵活性非常重要。MongoDB 3.2 引入了一个名为electionTimeoutMillis 的新参数允许用户配置系统来优化故障恢复行为：

• 值越大意味着较慢的故障恢复，但是降低了对主节点上网络延迟和负载的敏感性
• 值越小意味着更快的故障恢复，但是增加了对主节点上网络延迟和负载的敏感性

electionTimeoutMillis 默认设置为10,000毫秒（10秒）。

查阅文档了解更多信息。

持久性保证

除了更快的故障恢复，改进协议还为复制集间的写操作提供了更严格的一致性和持久性控制。使用一个安全写入级别进行配置，使得在确认操作之前将写操作应用到一个或多个从节点上，改进协议在向应用报告成功完成之前，将会同时向内存和这些从节点成员的日志中提交操作。此外，当使用majority安全写入级别时，在进行确认之前，这些改变也将会提交到内存和主节点中的日志。

默认地，从MongoDB3.2版本之前升级过来的任何复制集都会使用之前的复制集协议，而新的复制集将会使用改进协议。可以通过将“`protocolVersion“设置为0或者1来分别手动切换成新协议或旧协议。

简化的分片集群管理

MongoDB使用一个名为分片(sharding)的技术将数据库扩展到商用硬件。配置服务器(config server)是一个分片集群中非常重要的部分，存储着mongos查询路由使用的元数据来将读写操作导向到合适的分片，从而降低了存取数据库应用的复杂性。

在MongoDB 3.2之前，配置服务器是通过使用它们自己的写入协议、协调程序以及一致性检验实现了三个特定目的的mongod实例。这个架构使得分片集群的管理非常复杂，并且在将MongoDB部署在超过3个数据中心时会增加延迟。

从MongoDB3.2开始，配置服务器将默认地被部署为一个MongoDB复制集。因为配置服务器现在可以利用标准复制集读写协议的优势，这一改变提高了元数据的一致性和可管理性。此外，配置服务器复制集可以跨越超过三个数据中心，支持高达50个数据集成员，提供了更高几倍的可用性以及更低的跨区域延迟。阅读文档了解更多。

下一步

上面就是博客系列第二部分的内容。注意：您现在可以通过下载最新功能白皮书来详细了解MongoDB 3.2提供的所有功能。

或者，如果您已经阅读了足够多的相关资料，希望马上开始编码，您可以：

•  马上下载MongoDB 3.2
• 评估MongoDB企业高级版和Ops Manager

为了尽可能快速高效地开始使用MongoDB 3.2，可以考虑咨询专家。MongoDB的咨询工程师可以根据您的需要提供3.2功能方面的私人培训，然后与您一起合作为您的部署制定一个个性化的升级计划。感兴趣吗？那就快点联系我们吧（jianfa.tang@mongodb.com）。

关于作者-Mat Keep

Mat是MongoDB产品市场部总监，主要负责MongoDB产品及服务的愿景、定位及内容构建，包括市场趋势和客户需求分析。在进入MongoDB之前，Mat是Oracle公司的产品经理总监，负责互联网、电信、云以及大数据工作负载上的MysQL数据库，带领着来自技术供应商和终端用户公司的一系列销售人员、业务开发人员、分析师/程序员。

翻译：周颖敏

审稿：TJ

本文译自：https://www.mongodb.com/blog/post/what-s-new-in-mongodb-3-2-part-2-new-support-for-mission-critical-applications