MongoDB 3.2中的最新功能 第三部分：为数据分析师和DBA提供的工具和集成

lyhabc

在这篇博客中，我将会简要介绍一些关于支持数据分析人员、数据库管理员及运维团队的工具和集成。记住，您可以通过下载新功能白皮书来了解MongoDB 3.2提供的所有功能细节。

新用户

伴随着MongoDB部署在更广范围内的公司应用中，数据分析人员、数据库管理员以及运维团队将会需要将MongoDB集成到他们现有的进程及工具集。MongoDB 3.2允许分析人员从未经开发的数据源中得到新洞察来支撑业务，而数据库管理员和运维团队可以在运行现有关系型数据库的同时实施MongoDB，以保留管理平台和技能储备中的已有投资。

数据分析师和工程师

MongoDB BI 连接件

针对自助分析、基于实时操作型数据的快速发现和预测以及集成多结构和流式数据集需求的不断增长，商务智能和分析平台成为增长速度最快的软件市场之一。

为了满足这些需求，用户可以非常容易地使用符合产业标准的、基于SQL的商务智能和分析平台对存储在MongoDB中的现代应用数据进行研究。通过使用MongoDB BI连接件，分析员、数据科学家以及业务用户现在可以无缝地使用部署在无数企业中相同商务智能工具可视化 MongoDB中管理的半结构化和非结构化数据以及SQL数据库中存储的传统数据。

bi_images-ffae146804


图1：使用MongoDB生成的强大可视化获取新洞察

MongoDB BI连接件 实现

基于SQL的商务智能工具一般使用一个固定的模式表示表格数据来连接到数据源。当使用MongoDB的动态模式及丰富的多维文档时，这是一个非常大的挑战。为了使得BI工具将查询MongoDB作为一个数据源，BI连接件实现了以下操作：

为BI 工具提供希望可视化MongoDB集合的模式。用户可以校验模式输出以保证正确表示数据类型、子文档及数组
将BI 工具生成的SQL语句翻译为等同的MongoDB查询，之后发送给MongoDB处理
将返回的结果转化为商务智能工具需要的表格格式，基于用户需求对数据进行可视化
BI 连接件可以在MongoDB企业高级版中获取。观看演示了解BI连接件的运行，查阅文档了解更多。您也可以下载BI连接件对其进行评估。

动态查找$lookup：将Left Outer Join引入到MongoDB

通过将一起存取的数据整合到一个单一文档，应用可以从MongoDB中获取极大的性能提高。相反地，典型的传统数据库模式将相关的数据分散到一系列表中：例如，一个博客网站将与博客相关的每个标签、类别、评论、作者及callback作为单独表中的列。

通常，从操作型数据库中选择非规范化数据模型方法的最大优势在于：在单一操作中读取或写入一条完整记录的效率优先于存储需求的增加。然而，下面是一个规范化数据的案例，尤其是需要混合多来源的数据用于分析的时候。考虑一个购物车，有两个用于处理订单和产品信息的选项：

在相同文档中包括一个订单的所有数据

更快的读取-一个find可以获取所有需要的数据
文档中包括的产品细节在订单存储时是正确的，产品的价格之后可能会变化，但是订单文档中仍然会维护订单的准确表示
占用额外的存储：每个产品的细节可能存储在多个订单文档中，但是伴随着内存和存储价格的下降，这将变得越来越不是问题
订单文档引用产品文档

空间的高效性-产品细节只存储一次
更慢的读取-多数据库的多次读取
如果产品的某个属性（例如单价）之后发生改变，任何之前的订单文档都是不正确的，因为他们引用的是更新的版本
额外的应用逻辑-一个应用必须在订单文档中对产品ID进行迭代，再从产品文档中进行获取
MongoDB 3.2 通过在$lookup 操作符中实现left out join操作引入了从多个集合中组合数据的供您使用，现在已经可以作为MongoDB聚合框架管道中的一个阶段。新的$lookup 阶段在数据建模方面提供了更大的灵活性，并且提供了更高的性能和更少的应用方代码运行更丰富的分析。

实时分析和检索

MongoDB 3.2扩展了在实时、操作型数据上执行分析的选项，保证能够基于现有数据快速简单地处理结果。现在可以在数据库上执行 之前需要在客户端节点实现的工作：使开发人员能够更聚焦于开发新功能。

改进的聚合

聚合管道是一个非常强大的方式，在MongoDB数据上执行复杂的分析查询时使用。聚合管道阶段允许 来自一个集合一连串文档的操作 要么通过 游标 返回给客户端（与find相似），要么在一个最后的$out阶段存储在一个新的集合中。

在分析非常庞大的数据集时，对文档的随机样本进行分析比对所有数据进行分析要高效很多。例如，如果你想对比 在咖啡店里签到的数目与在酒吧签到的数据，您可以不必检索每个单一的签到就能够获得一个较好的估计。在过去，这样的取样只能在应用中实现，但是现在MongoDB引入了 $sample操作符，可以在聚合管道的任何阶段使用。

MongoDB文档可以存储数据，也可以存储简单的值。尽管这个功能非常强大，但是在聚合阶段并不需要对应的在文档中操作和过滤数组的能力，它们的作用被限制于分析的环境中。在处理数组时，MongoDB添加了新的操作符以提供更大的灵活性： $slice, $arrayElemAt, $concatArrays,$isArray, $filter, 以及 $min。

MongoDB 3.2 还增加了新的数学操作符，例如截断、向上取整、向下取整、求绝对值、四舍五入、平方根、取对数以及标准差等操作。相关人员可以直接通过使用这些操作符，将代码从客户端层迁移到数据库层，以较低的开发复杂性获取更高的性能。

通过组合新的和已有的操作符，可以构建聚合管道使用一个单一查询得到复杂的结果。查阅文档了解更多关于聚合管道的所有改进。

改进的文本检索

对MongoDB中数据的文本检索可以在数据库中执行，也可以使用一个外部的搜索引擎执行。在数据库中执行检索对管理员而言更加高效和简单，因此如果可能的话，在数据库中执行是更佳的选项。

MongoDB通过增加对大小写敏感检索以及额外语言（包括阿拉伯语、波斯语、乌尔都语、简体中文及繁体中文）的支持，扩展了数据库内文本检索的用户案例。为了提供对这些语言的支持，MongoDB企业高级版提供了与Basis Technology Rosette Linguistics Platform (RLP) 的集成，以实现基于语言的归一化、分词、断句、词干提取及分词。

可以在文档中找到关于文本检索的更多信息。

数据库管理员：MongoDB Compass

MongoDB的动态模式及富文档模型使得开发人员更加高效，但是也使得对底层数据和结构的探究和理解更加复杂，特别是对那些不熟悉MongoDB查询语言的非开发人员而言。MongoDB Compass图形化用户界面允许用户借助它在没有任何MongoDB查询语言基础的情况下，理解数据库中的数据结构、执行ad hoc查询。典型的用户包括：构建新MongoDB项目的架构师或者从一个工程师团队接手数据库、现在必须维护生产中数据库的数据库管理员，他们必须了解展示的数据类型、定义好合适的索引、判断是否应该添加文档验证规则来保证一致的文档结构。

直到现在，如果用户希望了解他们数据的类型就不得不连接到MongoDB shell，然后写查询语句来逆向获取文档结构、字段名称和数据类型。类似地，任何想在数据上运行定制化查询的用户都需要了解MongoDB的查询语言。

MongoDB Compass通过从一个集合中抽取文档的子集为用户提供了他们MongoDB模式的图形化视图。通过使用采样，MongoDB Compass最小化数据库支出并且能够几乎即时向用户展示结果。

compass_document_overview-73295c5295


图2：MongoDB Compass展示的文档结构和内容

查询数据

正如图3展示的，可以通过在MongoDB Compass用户接口简单地选择文档元素来构建和执行一个查询。通过选择多个值，也可以构建复杂的查询。点击一个按钮就可以执行该查询并且同时以图形化和一系列JSON文档的形式查看结果。

compass_build_query-010a86ecf8

图 3：使用MongoDB Compass交互式构建和执行数据库查询

无论数据库多庞大，MongoDB Compass都可以对数据库进行抽样以提供一个快速的交互式体验。如果需要得到完整结果，可以简单地将查询复制粘贴到一个MongoDB shell窗口中。

MongoDB 专业版和MongoDB企业高级版中都提供了MongoDB Compass。你可以在文档中了解更多关于Compass的信息，并且在我们简短的演示系列中查看它的具体功能：

第一部分：Compass介绍
第二部分：模式可视化
第三部分：可视化查询构建
你可以前往MongoDB下载中心体验评估MongoDB Compass。

运维团队

MongoDB Ops Manager和Cloud Manager 都是运行MongoDB的最佳方式，它们将类似于部署、扩展、升级及备份都简化到一系列的点击或者一个API调用。运维团队使用Ops或Cloud Manager平台之后可以提高10-20倍的生产效率。

MongoDB 3.2对Ops和Cloud Manager同时进行了改进，管理员可以：

将MongoDB与现有的应用性能监控平台进行集成，在一个单一的虚拟管理平台中可视化地了解整个IT资产全局的健康
通过使用Ops Manager对数据库测报进行粒度的监控，包括新的查询分析器可视化来对任何MongoDB特有的问题进行进一步挖掘
使用Ops Manager自动工具来初始化零宕机维护和升级行为，例如在一个分片集群中推出新索引
对标准的、网络挂载的文件系统中的数据库创建即时的、连续的快照，并且从备份文件中恢复完整的、运行着MongoDB的集群。
应用性能监控集成：New Relic & AppDynamic

许多运维团队使用应用性能监控（APM）平台例如New Relic和AppDynamic在一个单一的管理用户界面获取对他们完整IT架构的全局概览，可以快速识别出有高风险会影响客户体验的问题并且定位到特定的组件中：设备、硬件架构、网络、API、应用代码、数据库还是其它模块。

MongoDB驱动程序已经通过将查询性能度量指标暴露给应用性能管理工具的新API进行改进。管理员可以监控每个操作花费的时间，找到需要进一步分析和优化的、正在运行的慢查询。

此外，Cloud Manager将会提供与New Relic平台的打包集成。Cloud Manager中的关键度量指标将可以从应用性能监控中获取，并用于可视化，使得用户可以在剩余的应用资产中监控和关联MongoDB健康。

apm-31ed29b9c0


图4：将MongoDB集成到一个应用性能的单一视图

正如图4展示的，应用性能监控的用户接口中展示了Cloud Manager用户所熟悉的度量指标总结。管理员也可以运行New Relic Insight 对监控中的数据进行分析，生成仪表盘，提供对关键性能指标（KPIs）的实时追踪。

如果运维团队需要更细粒度的监控指标，他们可以对Cloud Manager维护的100+系统度量指标进行进一步挖掘。例如，新的可视化查询分析器帮助诊断正在运行的慢查询，随后可以通过增加一个新索引，并且将新索引自动地部署到集群中的每一个节点而解决这个问题。

查询性能优化：启动快速和简单查询优化

MongoDB数据库分析工具收集可用于分析查询性能的细粒度信息。然而，由于输出非常难以解析，使得正在运行的慢查询难以正确。此外，不得不单独激活每个MongoDB实例的分析工具，将每个节点中的输出进行手动整合以提供对整个部署的全局视图。

Ops Manager和Cloud Manager已经发布了新的可视化查询分析器，为运维团队和数据库管理员提供了一个快速和方便的方式用于分析特定的查询或者查询族。可视化查询分析器（如图5所示）展示了查询和写延迟随着时间的变化趋势，简化了识别相同模式和特征的慢查询及识别任何延迟峰值的操作。只需要在Ops Manager的用户界面进行一个简单的点击，激活分析器，就可以在一个单独的界面统一展示每个节点的度量指标。

profiler-32bd2838e7


图5： MongoDB Ops Manager中的可视化查询分析器

索引建议&自动化索引构建

为了进一步简化操作，可视化查询分析器将会对其收集的数据进行分析，为新索引的构建提供建议，以提高查询性能。

一旦确定，这些新索引将会需要铺开到生产系统中。为了最小化对真实系统的影响，运行滚动索引的最佳实践是：从每个从节点开始，最后在原始的主节点和其它从节点之一进行换主之后，再在该节点上建立索引。滚动的过程可以手动执行，但是Ops Manager和Cloud Manager现在可以在MongoDB复制集间自动化这个流程，降低了运维支出及由错误顺序管理流程而产生故障的风险。

新索引选项：部分索引

从节点索引是MongoDB区分与其它NoSQL数据库不同的地方之一：允许应用使用多种方式高效地读取它们的数据。然而，从节点索引确实带来了一些消耗：

由于需要更新从节点索引，数据库的写入将会变得更加缓慢
需要内存和存储来保存从节点索引
部分索引在提供优秀的查询性能和消耗更少的系统资源之间有一个很好的平衡。例如，考虑一个订单处理应用：应用会频繁查询订单集合以展示某个特定用户的所有未完成订单。为了高效的性能，在集合的userID字段上创建一个索引是非常有必要的。然而，在一个给定的时间内，只有非常小部分的订单满足条件。将索引限制在userID上只包含“活跃”状态的订单将会使得索引条目的数量从百万级降低到数千条，节约了工作集内存和磁盘空间，同时还进一步加速了查询：因为更少的索引将会带来更快的检索。

通过在索引创建阶段指定一个过滤表达式，一个用户可以使得MongoDB只包括那些满足特定条件的文档。

在执行数据库find操作时，为了让优化器使用部分索引，应用应该包括用于过滤的值以及被索引的值。查阅文档了解更多。

其它Ops Manager改进

除了上面讨论的功能之外，还有一些其它的大量改进提高了运维团队的生产效率，简化了安装和管理：

运维团队现在可以使用Ops Manager和Cloud Manager安全可靠地自动化数据库恢复。只需要几个简单的点击就可以进行完整的开发、测试和恢复集群。
与现有存储架构进行集成，MongoDB备份文件目前可以被存储在一个标准网络挂载的文件系统中。
运维团队只能对特定集合的备份进行配置，而不是整个数据库，从而加速了备份并且减少了所需的存储空间。这个改进在Cloud Manager平台中可以看到。
现在可以直接通过集中的Ops Manager用户接口进行所有应用和备份组件的安装和配置，并且也提供了一个用于健康监控的、单一的一览仪表盘。
备份架构的改进提高了对第一个数据库快照的读取速度。
目前可以定义被排除的错误警报及维护窗口，在这个阶段，Ops Manager和Cloud Manager的警报将不会被触发。
从应用性能管理集成到使用索引建议和自动化滚动索引构建的可视化分析器、再到平台简化和自动化集群恢复，Ops Manager可以帮助您的团队更加高效。