本文译自《MongoDB_Architecture_Guide.pdf》，因无法上传该E文，需要的同学可以自行查找。

一.引言
“MongoDB并非在实验室设计。我们通过自己建造大规模、高可用、健壮系统的经验构建了MongoDB。我们不是从零开始的，我们实际上是真的想发现问题并解决它。因此，我对MongoDB看法是，如果你采用Mysql，将关系模型改为基于文档的模型，你将会得到很多特性：内嵌文档用于提高速度，可管理性，动态模式的敏捷开发，因为连接并不那么重要，所以，易于水平扩展。关系库中，很多东西很好用：索引，动态查询和更新等，我们在这些方面没太大变化。例如：MongoDB中设计索引的方式和Mysql到Oracle几乎一样，您可以选择为一个嵌入域建立索引。”——Eliot Horowitz，MongoDB CTO和合伙人。
MongoDB是为我们如何建立和运行利用现代开发技术、编程模型、计算资源和操作自动化的应用而设计的。

二.我们如何建立和运行现代应用
关系数据库在大多数机构中占有长期的地位，这是有原因的。关系数据库支持满足当前业务需求的现有应用程序;它们由一个广泛的工具生态系统所支持;有大量的劳动力有资格实施和维护这些系统。
但是，由于构建现代应用程序所面临的挑战，各机构正在越来越多地考虑传统关系基础设施的替代方案。考虑如下因素：
1.开发人员正在开发能够创建新的、快速变化的数据类型(结构化、半结构化、非结构化和多态数据)及其海量数据的应用程序。
2.12到18个月的瀑布式开发周期已经一去不复返了。现在，小型团队以敏捷冲刺的方式工作，每一两个星期快速迭代并推送代码，有些甚至每天多次。
3.曾经服务于有限用户的应用程序现在作为服务交付，这些服务必须始终打开（always-on），可以从许多不同的设备访问并在全球范围内扩展。
4.企业现在转向使用开源软件、商用服务器和云计算的可扩展架构，而不是大型单片服务器和存储基础设施。

三.Nexus架构
MongoDB的设计理念专注于将关系数据库的关键功能与NoSQL技术的创新相结合。我们的愿景是利用Oracle和其他公司在过去40年中所做的工作，使关系数据库成为今天的样子。
MongoDB并没有抛弃几十年来已证明成熟的数据库，而是通过将关键的关系数据库功能与Internet先驱们为满足现代应用程序的需求所做的工作结合起来，沿着原来的路继续前进。
关系数据库已经为应用程序提供了多年的可靠服务，并且提供的特性在开发人员构建下一代应用程序时仍然至关重要:
1.富有表现力的查询语言。用户应该能够使用强大的查询、投影、聚合和更新操作符以高级方式访问和操作他们的数据，以支持操作和分析应用程序。
2.二级索引。索引在数据库本地支持而不是在应用程序代码中维护，为数据的读写提供高效访问发挥着关键作用。
3.强一致性。应用应该立刻读取到写入到数据库中的数据。围绕最终一致的模型构建应用程序要复杂得多，这就给开发人员带来重大的工作，甚至对最高级的开发团队也是如此。
然而，现代应用产生了关系库解决不了的需求，这推动了NoSQL数据库的发展，其能提供如下特性：
1.灵活的数据模型。NoSQL数据库的出现解决了我们看到的支配现代应用数据的需求。无论文档，图形，键值或宽列，都提供了灵活的数据模型，这使其容易存储和组合任何结构的数据，且允许无需宕机就能动态修改这些数据的模式。
2.弹性扩展。NoSQL数据库的构建专注于扩展性，因此，它们都包括某种形式的分片或分区，允许数据库在预先部署的商业硬件或云上进行扩展，允许几乎无限的增长。
3.高性能。NoSQL数据库设计用来交付任何规模的吞吐和延迟方面的高性能。
提供这些创新的同时，NoSQL系统也牺牲了人们在关系库希望和依赖的某些重要特性。MongoDB提供了不同的方法。通过Nexus架构，MongoDB成为了维护关系库基础并利用NoSQL创新的唯一数据库。

四.MongoDB通过键值创新来支持现代应用
MongoDB为现代应用的数据库：创新的，快速进入市场的，全球可扩展的，可靠的及操作廉价的。通过MongoDB，您能构建通过传统关系库从不可能的应用。具体如下所示。
1.快速、迭代开发。范围渐变和业务需求改变不再成为您和成功交付项目间的阻碍。具有动态模式的灵活数据模型和惯用的驱动使得开发者能快速构建和发展应用。自动化供应和管理使得能够进行连续集成和高产出操作。这与与静态关系模式和过去阻碍您的复杂操作形成了鲜明对比。
2.灵活的数据模型。MongoDB的文档数据模型使其很容易存储和组合任何结构的数据，同时，又不放弃高级数据访问和丰富的索引功能。您无需宕机就可以动态修改模式。您无需花费很多时间为数据库加工数据，而是将时间用在工作上。
3.多数据中心扩展性。MongoDB能在数据中心内和不同数据中心间进行扩展，提供新级别的可用性和扩展性。随着您部署数据量和吞吐量的增长，MongoDB无需宕机就能容易的扩展，也无需改变您的应用。随着您高可用和恢复目标的演化，MongoDB将会使您适应灵活性，跨数据中心和可调一致性。
4.集成特性集。分析，文本搜索，地理空间，内存性能和全局复制允许您交付各种技术、可靠和安全的实时应用。RDBMS系统需要另外的、需要单独开销和花费的复杂技术才能将其做好。
5.低TCO。当用MongoDB时应用开发组更高产。单击管理意味着操作组也是一样。MongoDB运行在商用硬件上，这戏剧性的降低了成本。最终，MongoDB提供负担得起的年度服务，包括24x7X365全球支持。与使用关系库相比，您应用的交付成本仅为1/10。
6.长期承诺。MongoDB公司和MongoDB生态系统支持着世界上增长最快的数据库。10M+的下载量和2000+客户包括财富100强的1/3多。超过1000个合作伙伴和比史上任何其他数据库都多的投资基金。您能确信您的投资是得到保护的。

五.MongoDB插件式存储引擎
MongoDB包含现代IT的两个关键趋势：
1.机构正在扩展他们交付的应用支持的业务范围。
2.CIO们正将他们的技术组合合理化，使之成为一组战略性的供应商，以便更有效地支持他们的业务。
通过MongoDB，各机构能够通过一种数据库技术解决不同的应用需求、硬件资源和部署设计。通过使用插件式存储架构，MongoDB能扩展新的功能，和配置特定硬件架构得以最优利用。与通过多个数据库支撑单一需求的应用相比较，该方法大大降低了开发者和操作复杂度。通过用不同的插件式MongoDB存储引擎支撑不同应用，用户能利用同样的MongoDB查询语言、数据模型、扩展性、安全性和跨越不同应用的操作工具。
MongoDB3.0附带了两个支持的存储引擎，两个引擎能共存于一个MongoDB复制集内，使其容易评估和它们之间进行迁移：
1.默认的MMAPv1引擎，先前MongoDB版本所用引擎的改进版本。
2.新的WireTiger存储引擎。很多应用，WiredTiger的更细粒度的并发控制和内部压缩，将在降低存储成本、增大硬件利用率和更可预期的性能方面提供重大的收益。
其他引擎正在开发并将成为MongoDB生态系统的成员。

六.MongoDB数据模型
1.数据即文档
MongoDB按照称为BSON(Binary JSON)的二进制表示法将数据存储为文档(documents)。BSON编码扩展了流行的JSON(Javascript Object Natation)表示法，以包括另外的类似int、long和floating point类型。BSON文档包含一个或多个域，每个域包含一个特定数据类型的数值，数据类型也包括数组、二进制数据和子文档。
倾向于共享类似结构的文档组织成集合(collections)。认为集合与关系库中的表类似也许是有帮助的：文档与数据行类似，域和列类似。
例如：考虑一个有关博客应用的数据模型。关系数据库中，数据模型包括多张表。为了简化该例，假设有Categories、Tages、Users、Comments和Articles几张表。
MongoDB中，数据能被建模成两个集合，一个是用户，另一个是文章。每个博客文档中，可以有多个评论，多个标签和多个类，每个通过嵌入数组表示。
象这个例子中说的，MongoDB文档倾向于当个文档的记录中包含所有数据，而关系库中记录的信息通常分散到多张表中。通过MongoDB的文档模型，数据更本地化，其极大减小了通过join连接表的必要。因为对数据库的单个读操作能获取包含所有相关数据的整个文档，其结果是在商用硬件上显著提高了性能和可扩展性。另外，MongoDB的BSON文档与编程语言中对象的结构更加一致。这使得开发人员建模将应用中的数据映射到数据库中存储的数据时变的更加简单和快速。
2.动态模式
MongoDB文档能改变结构。例如：描述用户的所有文档能包含用户ID和他们登录系统的最近日期，但只有部分文档也许包含一个或更多个第三方应用的标识。不同文档的域可以不同；没必要声明系统中文档的结构。
——文档是自描述的。如果一个新域需要加入一个文档，那么，该域能被创建而不会影响系统中其他文档，不会变更中心系统目录，也不需要系统离线。
开发人员能开始写代码并在创建对象时持久化它们。当开发人员增加更多功能时，MongoDB继续存储变更的对象而无需执行高成本的alter table操作，或更糟糕地，从头开始重新设计模式。
3.模式设计
虽然MongoDB提供模式灵活性，但模式设计还是很重要的。开发人员和DBA们应该考虑一些主题，包括应用将需执行的查询类型，对象在应用代码中如何管理，文档如何随时间改变等。模式设计是一个超出本文的广泛话题。想了解更多信息，请参考数据模型考量（Data Modeling Considerations）。

七.MongoDB查询模型
1.惯用的驱动
MongoDB为所有流行编程语言和框架提供本地驱动以使开发工作顺利。支持的驱动包括Java，.NET，Ruby，PHP，Javascript，node.js，Python，Perl，Scala和其他。MongoDB驱动对确定语言设计为惯用的。
和关系库相比一个根本不同是MongoDB查询模型作为特定编程语言的API内的方法或函数实施的，这和完全独立的SQL语言恰恰相反。加上MongoDB的JSON文档模型与面向对象编程语言中用的数据结构间的相似性，使得与应用的集成变得简单。驱动的完整列表可以参考MongoDB Drivers部分。
2.Mongo Shell
mongo shell是一个包含于所有MongoDB发行版本中的丰富的、交互的Javascript shell。几乎所有MongoDB支持的命令都可以通过该shell发布，其中，包括管理操作。mongo shell是与MongoDB交互进行特别操作的流行方式。MongoDB手册中的所有例子都基于该shell。有关mongo shell的更多内容，请参考MongoDB手册中的相应部分。
3.查询类型
不像NoSQL数据库，MongoDB并不限定于简单的键值（Key-Value）操作。开发人员能通过复杂查询和解锁结构化、半结构化和非结构化数值的二级索引构建丰富的应用。
该灵活性的一个关键因素是MongoDB对多类型查询的支持。一个查询也许返回一个文档，而该文档特定域的子集或对很多文档的汇聚具体如下：
1）键值查询根据文档中任何域返回结果，通常为主键。
2）范围查询根据定义为不等式值返回结果（例如：大于，小于等于，位于。。。之间）。
3）地理空间查询根据点、线、圆或多边形指定的邻近标准、交集和包含返回结果。
4）文本搜索查询根据用布尔操作符的参数按相关顺序返回结果（例如：AND，OR,NOT）。
5）汇聚框架查询返回查询返回值的汇聚（例如：count，min，max，average，类似一个SQL GROUP BY语句）。
6）MapReduce查询执行JavaScript表示的复杂和跨库数据处理。

4.索引
索引是优化系统性能和扩展性、同时提供数据灵活访问的重要机制。象大多数数据库管理系统一样，索引在数量级提升某些操作性能的同时，也会带来写操作、磁盘使用率和内存消耗的相关开销。默认地，WiredTiger存储引擎压缩RAM中的索引，为文档释放更多的工作集。
MongoDB支持很多类型的、能在文档的任何域上声明的二级索引，其中包括数组内的域，具体如下所示：
1）唯一索引。通过将索引确定为唯一索引，MongoDB将拒绝与该索引已有域值相同新文档的插入或已有文档的修改。默认地，所有索引不会设置为唯一索引。如果一个复合索引确定为唯一索引，则其域值的组合必须是唯一的。
2）复合索引。为确定了多个谓词的查询创建复合索引可能是有用的。例如：考虑存储有关客户数据的应用。应用也许需要根据last name，first name和city of residence找到客户。通过在last name，first name和city of residence上创建一个复合索引，查询就能够快速定位到等于这三个域值的所有客户。复合索引的另一个好处就是索引的任何先导域都能使用，因此，有必要减少单个域上的索引：上述复合索引也将会优化通过last name查找客户的查询。
3）数组索引。对包含数组的域，每个数组值存储为一个单独的索引项。例如：描述产品的文档也许包括一个组件域。如果在该组件域上建一个索引，则每个组件被索引，针对该组件域的查询能通过该索引得以优化。
创建数组索引没有特殊语法——如果域包含一个数组，其将被创建为数组索引。
4）TTL索引。某些场景下，系统中的数据将自动过期。生存时间索引允许用户确定一个时间段，超过该时间数据将自动从数据库中删除。TTL索引的一个常见使用是维护类似点击流的用户行为历史滚动窗（例如：最近100天）的应用。
5）地理空间索引。MongoDB支持地理空间索引以优化二维空间内位置相关的查询，象地球投影系统。这些索引允许MongoDB对包含最接近给定点或线的点或多边形的；在圆形、矩形或多边形内的;或与圆、矩形或多边形相交的文档的查询进行优化。
6）稀疏索引。稀疏索引仅包含特定域所在文档的索引项。因为MongoDB的文档数据模型允许文档间数据模型的灵活性，某些域仅出现于部分文档中是常见的。当域并不出现于所有文档中时，稀疏索引索引更小、更高效。
7）文本检索索引。MongoDB为文本搜索提供了一种特殊索引，该索引使用高级的、特定语言词干提取、标识化和停止词规则。使用文本搜索索引的查询将按照相关顺序返回文档。本文索引可以包含一个或多个域。
5.查询优化。
MongoDB自动优化查询以使评估尽可能高效。评估通常包括根据谓词选择数据，及根据提供的排序规则对数据排序。通过定期运行可选查询计划并选出每个查询类型最佳响应时间的索引，查询优化器选择使用最佳索引。
这种实证测试结果作为缓冲查询计划存储，并定期变更。通过使用有力的explain方法和索引过滤，开发人员能预览并优化计划。
通过开启MongoDB运行特定查询时使用多个索引，索引交集提供另外的灵活性。
6.覆盖查询（Covered Queries）
返回结果只包含索引域的查询成为覆盖查询。这些结果无需读取源文档就可以被返回。如果索引合理，工作负载能被优化以主要使用覆盖查询。

八.MongoDB数据管理
1.自动分片（sharding）
MongoDB通过一种叫做分片的、对应用透明的技术支持对低成本、商用硬件或云基础架构上的数据库进行水平扩展。分片将数据分布到多个称为分片的物理分区上。分片允许MongoDB部署解决单个服务器在类似RAM或磁盘I/O瓶颈的硬件限制，而无需增加应用的复杂度。
当数据量增长或簇规模增加或减少时，MongoDB自动平衡分片簇中的数据。
不像关系库，分片是自动的且内置于数据库中。开发人员无需面对其应用中构建复杂的分片逻辑，这些分片逻辑在分片迁移时需要进行变更。
操作组不必部署另外的簇软件来管理进程和数据分布。
不像其他分布式数据库，MongoDB可以提供多个分片策略使开发人员和管理员能根据查询模式或数据位置，将数据分布到簇的各个节点上。结果，MongoDB可以为不同的工作负载交付高得多的扩展性：
1）基于范围的分片。文档通过分片键值分布到各个分片。分片键值相互接近的文档可能会共同位于相同分片。该方法很适合优化基于范围查询的应用。
2）基于哈希的分片。根据分片键值的MD5哈希计算，文档被统一分布到个分片。分片键值互相接近的文档不可能共同位于相同分片上。这种方法可以保证写操作同一分布到各个分片，但对基于范围的查询优化有限。
3）位置感知的分片。根据用户确定的、将分片键值范围与特定分片和硬件相关联的配置将文档进行分片。用户能连续调整应用要求的文档物理位置，象将数据定位到特定数据中心或多温度存储上（例如：最近的数据放在SSD上，较旧的数据放在HHD上）。
数以万计的机构使用MongoDB构建大规模高性能系统。更多内容您可以参考MongoDB scaling部分。
2.查询路由
分片对应用是透明的；一个或一百个分片，对查询MongoDB的应用来讲都是一样的。应用对查询路由发布查询，查询路由将这些查询指派到适当的分片上。
对基于分片键的键值查询，查询路由将该查询指派到管理拥有请求键值文档的分片上。当用基于范围的分片时，指定分片键值范围的查询仅被分派到拥有指定键值范围内数值的文档所在的分片上。对于并不使用分片键的查询，查询路由器将查询广播到所有的分片并对结果汇聚和适当排序。一个MongoDB系统可以使用多个查询路由器，其合理数目由应用需要的性能和可用性决定。

九.一致性&持久性
1.事务模型&可配置写可用性
MongoDB在文档级别兼容ACID。单个操作中可以写一个或多个域，包括对一个数组的多个子文档和元素进行变更。MongoDB支持的ACID确保文档修改时的完全隔离；任何错误将引起该操作被回滚，且客户端收到该文档的一致性视图。
MongoDB也允许用户用一个称为写关系（write concern）的选项指定系统的写可用性。默认的写关系确认来自应用程序的写操作，允许客户端扑捉网络例外和重复键值错误。开发人员能通过MongoDB的写关系配置操作仅在特定策略满足后才提交到应用——例如：仅在操作被刷到磁盘的日志后。这在很多传统关系库中采用同样的模式以保证持久性。作为分布式系统，MongoDB使用户获得他们渴望的持久性目标方面提供另外的
灵活性，例如：必须写到一个数据中心的至少两个副本且另一个数据中心的一个副本。每个查询都能指定合理的写关系，从为确认到确认写已被提交到所有的副本。
2.并发控制
通过协调多线程对共享数据结构和对象的访问，MongoDB强制多个客户端对数据库的并发控制。并发控制的粒度取决于MongoDB配置的存储引擎。WireTiger强制文档级的并发控制，而MMAPv1存储引擎实施了集合级的并发控制。通过支持多个会话访问一个集合中多个文档的并发写访问，MongoDB为很多应用提供了更大硬件利用率和更可预期的性能。存储引擎支持对一个文档的无限读操作。更多信息请参考有关并发控制的文档。
3.日志（Journaling）
MongoDB实施了预写操作日志，以使存储引擎能进行快速崩溃恢复和持久化。服务器崩溃的场景中，会自动进行日志项恢复。
日志行为取决于配置的存储引擎：
1）MMAPv1日志默认至少每100ms提交一次。除了持久性，日志也在非干净系统关闭事件中阻止崩溃。默认地，有MMAPv1的MongoDB开启日志。生产环境部署都应该配置开启日志。
2）WiredTiger日志确保检查点间的写操作被持久化到磁盘。WiredTiger默认每隔60秒或2GB数据被写入后，用检查点将数据刷出到磁盘。这样，默认地，如果WiredTiger为开启日志，则最多能丢失60秒内的写操作。
——虽然如果通过复制实现持久化，则该损失的风险通常要低的多。在非干净关闭事件中，WiredTiger事务日志不需要保持数据文件处于一致状态，因此，不开启日志运行是安全的，虽然为了确保可用性，应该配置“安全复制品”的写关系。WiredTiger存储引擎的另一个特性是能压缩磁盘上的日志以减少存储空间。
为了额外的保证，管理员能为两个存储引擎配置日志写关系，这样，MongoDB仅在将数据提交至日志后才会承认写操作。更多内容可以参考相关文档。

十.可用性
1.复制（Replication）
MongoDB通过本地复制维护多个称为副本集的数据拷贝。一个副本集是用于防止数据库宕机的、完全可以自己修复的分片。副本失败切换是完全自动的，这减少了管理员手工干涉的必要。
一个副本集包含多个副本。任何给定的时间，一个成员充当主副本集成员，其他成员作为二级副本集成员。MongoDB默认为强一致的：读和写都被发布到数据的主拷贝上。如果主成员因为任何原因失败了（例如：硬件失败，网络分区），则自动选出一个二级成员作为新的主成员并开始处理所有的写操作。
MongoDB副本集中的副本数是可以配置的，大量的副本可以在数据库宕机事件中提供更高的数据持久性和保护（例如：多台机器失败，机架失败，数据中心失败，或网络分区等场景）。每个副本集最多可以包含50个成员。
为了进一步提高持久性，管理员能配置副本集返回应用前将数据写到向多个副本成员——这样，提供了类似同步复制的功能。
应用可以选择从二级副本上读取数据，这些二级副本上的数据默认为最终一致的。在可以接受数据稍微过期的类似报表应用的场景中，从二级副本读取是有用的。当地理延迟比一致性更重要时，应用也能从通过ping距离测量的数据的最近拷贝读取。更多从二级副本读取的内容请参考Read Preference项目。
除了增强弹性和更广泛的数据分布，副本集也能配置一个成员执行特殊任务：
1）可以为需要与常规操作负载隔离的类似分析和报表类应用提供隐藏的副本集成员。
2）可以部署延迟副本集成员按照不同时间间隔提供数据的“历史”快照，用于从某些类似“fat-finger”错误导致的删除数据库或集合的某些错误中恢复数据。
副本集也可以通过数据库在线升级硬件和软件的方式提供操作灵活性。因为这类操作站传统系统宕机时间的1/3，所以，该特点是个重要功能。有关副本集的更多内容请参考Replication项目。
2.副本集操作日志（Replica Set Oplog）
对数据库主副本的修改通过一种称为操作日志的日志复制到二级副本。操作日志包含一套有序的在二级副本重演的幂等操作。可以配置操作日志的大小，其默认大小为磁盘空闲空间的5%。对大多数应用来说，该大小代表数个小时的操作，如果一个二级副本下线一段时间且上线后需要追上主副本，则需为该副本定义一个恢复窗。
如果一个二级副本成员下线时间比操作日志维护的时间长，那么，该二级副本必须通过一个称为初始化同步的过程从主副本恢复。期间，所有数据库及其集合都从主副本或其他副本拷贝到该二级副本及其操作日志，接着，将创建索引。当向一个副本集添加新成员时，也会执行初始化同步。更多内容请参考Replica Set Data Synchronization。
3.选举和失败切换
副本集减少了操作开销和提高了系统可用性。如果一个分片的主副本失败了，二级副本在一个称为选举的过程中共同决定哪一个副本将成为新的主副本。一旦决定了新的主副本，其余二级副本被配置从新的主副本接受更新。如果原来的主副本再次上线，其将识别出自己不再是主副本且将配置自己变成一个二级副本。
4.选举优先权
高级算法控制副本集选举过程，确保仅最合适的二级副本成员提升为主副本成员，且减少不必要失败切换（也被称为“假阳性”）的风险。选举算法处理一系列包括鉴定已应用主副本最新变更的副本集成员的时间戳、心跳、联通状态和用户定义指派给副本集成员的权限等参数。选举中，副本集选出一个最高权限值的、合格成员作为新主副本成员。默认地，所有成员有权限1且有相同机会称为主副本成员；然而，也能对一个副本成员的权限值进行设置一影响其变为主副本成员的可能性。
某些部署中，也许有选举权限能解决的操作需求。例如：能配置位于二级数据中心的所有副本的权限，以便如果主数据中心失败，这些副本中的一个能变为主副本成员。

十一.性能&压缩
1.内存与磁盘性能（In-Memory Performance With On-Disk Capacity）
MongoDB广泛使用RAM来加速数据库操作。从内存读数据以纳秒（nanoseconds）度量。而从机械磁盘读数据以毫秒（milliseconds）度量；从内存读数据比从机械磁盘读数据快几乎100,000倍。当不要求所有数据都在RAM中，频繁访问的索引和所有数据应该能放入RAM。例如：数据库最近事件或流行产品相关部分数据被应用频繁访问的场景。如果频繁访问的数据量超出单台机器的容量，MongoDB能通过自动分片进行跨多台服务器进行水平扩展。
因为MongoDB提供内存中性能，对大部分应用来说，单独缓冲层是没必要的。
更多内容可以参考MongoDB性能最佳实践白皮书。
2.压缩存储效率（Storage Efficiency with Compression）
WiredTiger存储引擎支持本地压缩，其可以减少80%之多的物理存储空间。除了减少存储空间，由于只需从磁盘上读取较少的位，压缩也能提高存储I/O扩展性。
管理员可以为连接、索引和日志灵活的配置特定的压缩算法，可选址如下：
1）Snappy（文档和日志的默认库），其在高文档压缩率——通常约70%，具体根据数据类型，与低CPU开销间提供最优平衡。
2）zlib，为存储密集型应用以额外CPU开销提供较高的文档压缩比。
3）索引前缀压缩可以将索引的内存空间降低约50%，以为频繁访问的文档释放更多的工作集内存空间。就像snappy，实际压缩比依赖于工作负载。
管理员能修改所有集合和索引的默认压缩设置。集合和索引创建期间，每个集合和索引的压缩可以有自己的压缩设置。
通过使用MongoDB中可用的压缩算法，操作组能使每个节点性能更高并降低存储成本。
3.安全
当今互联的世界，数据安全和隐私是非常重要的问题。从社交媒体、日志、移动设备和传感器网络等新来源分析的数据，已变得与后台系统生成的传统事务性数据一样敏感。
1）认证。MongoDB简化了对数据库的访问控制，它提供了与包括LDAP、Windows Active Directory、Kerberos和x.509证书外部安全机制的集成。
2）授权。用户定义的角色使管理员能够根据完成工作所需的权限为用户或应用程序配置细粒度权限。此外，域级编校可以与受信任的中间件一起工作，以管理对文档中单个域的访问，从而使在单个文档中存放具有多个安全级别的数据成为可能。
3）审计。为了管理兼容性，安全管理员能用MongoDB的本地审计日志来跟踪对数据库的任何操作——无论DML，DCL或DDL。
4）加密。MongoDB能在网络和磁盘上进行加密。对SSL的支持允许客户端通过加密通道连接到MongoDB。为了了解更多，下载MongoDB安全参考架构白皮书（MongoDB Security Reference Architecture Whitepaper）。

十二.管理MongoDB——服务开通，监控和灾难恢复
由开发数据库的工程师创建的MongoDB Ops Manager是运行MongoDB，使操作组容易部署、监控、备份和扩展MongoDB的最简单方式。Ops Manager很多功能在托管在云上的MongoDB Cloud Manager服务也可用。今天，Cloud Manager支持数以千计的部署，包括来自一台到100台服务器的系统。运行MongoDB Enterprise Advanced的机构可以为他们的部署选择Ops Manager和Cloud Manager。
Ops Manager和Cloud Manager结合了最佳实践帮助保持管理的数据库健康和最优。他们通过点击一个按钮将复杂的手工任务转换为可靠的、自动化过程来确保操作的连续性。
1）部署。任何拓扑，任何规模；
2）升级。数分钟内，且无宕机时间；
3）扩展。增加容量，无需下线应用；
4）时间点，调度备份。恢复到任意时间点，因为灾难是不可预期的；
5）性能预警。监控100+个系统指标，且系统性能降级前发出定制预警。
1.部署和升级
Ops Manager（和Cloud Manager）协调MongoDB系统的服务器上的关键操作任务。
其通过安装在每台服务器上的代理与基础架构进行通信。服务器能在公有云或私有数据中心。Ops Manager可靠的协调管理员传统手工执行的任务——部署一个新簇，升级，创建备份时间点，和很多其他操作活动。
1）通过Chef或Pupper配置工具或管理员，将Ops Manager代理安装在服务器（其上将部署MongoDB）。
2）管理员为系统创建一个新的设计目标，修改一个已有的部署（例如，升级，调整oplog大小，添加分片），或创建一个新系统。
3）代理周期地检查向Ops Manager中心服务器报道并接受新的设计指示。
4）代理创建和遵从一个实施该设计的计划。用一个高级规则引擎，当条件改变时代理连续调整他们自己的计划。面对很多失败的场景——代理将修订他们的计划已达到一个安全状态。
5）数分钟后，系统被安全、可靠的部署。
Ops Manager能在任何连接的服务器上部署MongoDB，但在AWS上，Colud Manager做的更多。一旦AWS秘钥不被提供，Cloud Manager能在部署MongoDB时配置亚马逊上的虚机。该集成删除了一个步骤，从而使得更容易开始。
Cloud Manager用MongoDB最优配置配置你的AWS虚机。
除了最初部署，Ops Manager和Cloud Manager使得通过添加分片和副本集成员进行容量调整成为可能。其他类似升级MongoDB或调整oplog大小的维护任务能通过点击按钮减少数十数百个手工步骤，且都是零宕机时间。
管理员能直接用Ops Manager借口，或从已有企业工具上运行Ops Manager RESTful API，包括流行监控和编排框架。
2.监控
高性能分布式系统从综合监控受益。Ops Manager和Cloud Manager开发用于给管理员所需的洞察以确保最终用户操作平滑和富有经验。
赋予图标、定制仪表盘和自动预警功能，Ops Manager对100+个关键数据库和14个包括操作计数、内存和CPU利用率、复制状态、打开连接、队列和任何节点状态等系统健康指标进行跟踪。
这些指标被安全的报告给Ops Manager和Cloud Manager进行处理、汇聚、预警和浏览器中可视化，以便项目组可见性能限制到他们自己的应用，同时，系统管理员能监控机构中的所有MongoDB部署。
为了创建操作基线和支持容量规划，可以回顾历史性能。通过Ops Manager RESTful API与已有监控工具的集成也是简单的,通过统一视图的Ops Manager部分对您的操作进行深入洞察。
Ops Manager和Cloud Manager允许管理员设置关键指标超出范围时的定制预警。预警可以配置影响单个主机、副本集、代理和备份的系列参数。预警能通过SMS和email发送，或集成进现有的类似PagerDuty和HipChat突发管理系统，以便潜在问题升级为昂贵的停机前对其进行前瞻性的警告。
如果用Cloud Manager，对实时监控数据的访问也能与MongoDB支持工程师共享，以通过消除不同组件传递日志的必要而快速问题解决。
3.灾难恢复：备份&时间点恢复
为了在类似数据中心火灾或洪水、或敲错代码或意外删除集合的人为错误等灾难失败中保护关键任务数据，需要制定一个备份和恢复策略。有备份恢复策略，管理员就能恢复业务操作而不会丢失数据，机构也能符合法规和合规要求。定期进行备份也能提供其他好处。备份能用于创建开发、展示或QA环境而不会影响生产环境。
Ops Manager和Cloud Manager会连续维护备份，比操作系统仅延迟几秒钟。如果MongoDB簇失败了，最近的备份仅稍延迟一点，将数据丢失的损失降到最低。Ops Manager和Cloud Manager是MongoDB提供副本集时间点备份和共享簇簇范围快照的唯一解决方案。您能快速安全地恢复到需要的任何精确时刻。
因为Ops Manager和Cloud Manager只读取oplog，所以，持续的性能影响是最小的——类似于向副本集增加一个另外的副本。
通过使用MongoDB Enterprise Advanced，您能部署Ops Manager对本地数据中心的备份进行控制，或用Cloud Manager服务提供现收现付的、一个完全管理的备份解决方案。专业MongoDB工程师24X365对用户备份进行监控，如果发生问题将会对操作组进行预警。
4.MongoDB与外部监控方案集成
Ops Manager和Cloud Manager API支持通过对自动化特性和监控数据编程访问与外部管理框架进行集成。
除了Ops Manager和Cloud Managr，MongoDB Enterprise Advanced能向SNMP陷阱、中心数据收集支持和外部监控方案汇聚报告系统信息。SNMP集成更多内容请参考相关文档。

十三.以关系库成本的1/10运行
与关系库相比，MongoDB能以其1/10的成本进行创建和运行。成本优势主要因为如下：
1.MongoDB增加了易用性和开发灵活性，这降低了开发和操作应用的成本；
2.MongoDB能在商用服务器硬件和存储上进行扩展。
3.MongoDB大大降低了商业授权的价格，提供高级功能和支持。
此外，MongoDB的技术和成本优势也转换成销售优势，象更快的上市时间和扩展时间。
为了了解更多，可以下载我们关于Oracle和MongoDB比较的TCO。

十四.结论
MongoDB是当今应用的数据库：创新、快速上市、全局扩展、可靠和操作廉价。本指导中我们已经探索了基本概念和作为MongoDB架构基础的假设。有关该主题的其他指导见mongodb.com，象操作最佳实践（Operations Best Practices）。

十五.我们提供的帮助
我们是MongoDB专家。2000多家机构依赖于我们的商业产品，包括创建和多于1/3财富100强企业。我们提供让您的生活更好的软件和服务：
MongoDB Enterprise Advanced是在您的数据中心运行MongoDB的最好方式。其为一款高级软件、支持、认证和为您业务设计的其他服务的精致包。
MongoDB Cloud Manager是云上运行MongoDB的最好方式。其使MongoDB成为你最不担心、最喜欢管理的系统。
MongoDB Professional帮您管理您的部署并保持其持续运行。其包括来自MongoDB工程师的支持和访问MongoDB Cloud Manager。
Development Support帮助您快速开启和运转。其为您提供项目早期阶段软件和服务的完整包。
MongoDB Consulting包让您更快的投产，帮助您调整生产库性能，帮助您将更多精力专注于下一版本。
MongoDB Training帮助您成为一个MongoDB专家，从设计到操作关键任务的大规模系统。
无论您是开发人员、DBA或架构师，我们都能使您在MongoDB方面变的更好。