大概六年前，在为ZDNet撰写文章时，我们曾经认真思考过一个问题：MongoDB未来要走向何方？随着时间推移，答案已经逐渐浮出水面：要让数据库更具可扩展性，支持开发者编写好的各种应用程序。为此，MongoDB增加了原生搜索功能，以支持内容管理；物联网用例也获得了时序数据支持；另外还有变更流，可帮助电商应用快速预测出下一佳行动。
顺带一说，MongoDB的客户还需要一种能够与开发工具良好匹配、易于上手的云解决方案。结果就是Atlas，这项托管云服务目前占MongoDB整体业务的60%。
但还有另外一个重要部分值得关注——分析。
刚开始，MongoDB被设计成了一套可操作数据库。主要用于管理在线订阅者的个人资料等用例，借此提供更好的游戏或娱乐体验。它还可以捕捉汽车远程信息，借此跟踪组件的运行状态；随时访问临床患者数据，管理医疗保健服务；或者为电子商务应用提供支持，实现无缝化的购物体验。
千万别误会，并不是说MongoDB只关注写入侧。只是作为其早的增强功能之一，MongoDB聚合框架能够很好地解决多步“分组”查询，而这正是交易型数据库的典型特征。
但平心而论，与大多数其他操作型数据库一样，MongoDB直到近才刚刚得到重视。毕竟大家可能很难想象要在一套操作型数据库中，执行涵盖多个表（或文档集合）的复杂查询。
一、为什么要引入分析？
大多数操作型应用程序的共同之处是一旦添加了分析功能，其实用性将马上飞升。例如，分析可以帮助汽车制造商增强预防性维护，医疗保健服务商能够确定佳护理方案，电子商务或游戏厂商则可以改善客户交互、防止客户流失。这些出于决策优化而设计出的分析功能，是对操作型数据库的良好补充。
把分析跟交易型数据库联系起来绝不是什么新鲜想法，HTAP、translytical或增强型交易数据库都是分析厂商们拿出的相应成果。
云原生提出的计算与存储彼此分离的理念，则让我们有了另一个在不影响性能或吞吐量的情况下、将操作数据处理与分析加以结合的好机会。近亮相的Oracle MySQL HeatWaev和谷歌AlloyDB，正是大厂在这个方向上的积极尝试。
大多数此类混合数据库都会使用专为分析而设计的柱状表，对传统行存储进行补充。顺带一提，它们也都使用相同的常见关系数据结构，确保转换更加简便易行。与之对应，如果引入包含分层和嵌套数据结构的文档模型，那么转译过程往往会更加困难。
那么，MongoDB是不是也该拥有自己的分析功能？这还是要看我们如何定义“分析”。如前所述，如果我们向交易中引入智能化操作分析，那么应用程序的实用性将大大增强。所以只要把范围设定在快速决策分析，而非复杂的分析建模，那么答案就是肯定的。
二、无法一蹴而就的事业
MongoDB已经开始尝试支持分析功能。它从可视化开始，着手提供自己的图表功能与商务智能（BI）连接器，现在的MongoDB在Tableaus与Qliks端看来已经几乎与MySQL无异。虽然一图胜万言，但对于分析来说，可视化还只是万里长征步。MongoDB尽管能提供趋势快照，但还无法进一步实现数据关联（往往涉及更复杂的查询），也无法完全回答“为什么”会出现哪些状况。
MongoDB决心已定，开始通过分析提升自身竞争力。但在这个分析复杂度愈发高企的时代，它显然无法取代Snowflake、Redshift、Databricks或者其他专业分析方案。但MongoDB分析面向的也并非数据分析师，而是应用程序开发者。回到操作型数据库的首要原则——尽量别把它，跟需要高度复杂的连接及/或高并发查询扯在一起。只要能让开发者构建起更好的应用程序，MongoDB就算是成功了。
Atlas能够灵活预留专门的分析节点。MongoDB也将在不久后，全面允许客户在更适合分析的节点上选择不同的计算实例。这些节点将提供在线数据复制功能，借此实现近实时分析。
但这还只是步：由于Atlas可运行在多种云环境上，因此客户还可以选择更多其他实例。不过大家无需担心，MongoDB未来将推出规范性指南，同时提供机器学习方案帮助大家自动选择适应工作负载的实例类型。
对分析的尝试当然不可能止步于此，去年预览发布的Atlas Serverless将于本周推出正式版。刚刚起步的分析自然也将成为受益者，因为分析类工作负载一般与交易事务不同、突发峰值往往更多。
三、有没有可能对接SQL？
其实引入SQL的想法在MongoDB发展早期一直备受反对，当时有声音认为MongoDB永远不该成为关系数据库。但是，理性终将战胜情绪。
本周，MongoDB引入了新的接口，可用于读取Atlas数据。这是一种全新结构，采用不同于BI连接器的通道。Atlas SQL将是MongoDB为数据提供SQL接口的次真正尝试，其思路绝不是简单把JSON扁平化以使其在Tableau中看起来像MySQL，而是提供更加精细的视图、反映JSON文档架构的丰富性。
但SQL接口编写工作不可能一蹴而就，所以预计Atlas SQL将在未来几年内逐渐发展完善。毕竟要想与各类SQL工具（不止是可视化）实现全面集成，MongoDB还得在丰富的数据仓库选项上多下工夫。我们还希望看到对upserts等操作的支持，分析平台没有了这些核心功能，就相当于分析表中失去了行插入功能。
与Atlas SQL接口一同推出预览版的全新列存储索引，则意在提高分析查询的性能水平。同样的，这还仅仅只是开始。例如，MongoDB用户目前仍需要手动设置列存储索引、指定字段。但从长远来看，我们可以通过分析访问模式来实现自动化。设想一下：后续我们可以丰富元数据以分析字段基数，添加Bloom过滤器以进一步优化扫描功能，也可以继续完善查询计划器。
接下来是Atlas Data Lake，负责为云对象存储中的JSON文档提供联合视图。Atlas Data Lake在改造完成后，将针对多个Atlas集群和云对象存储提供更多的通用联合查询功能。新的存储层会自动将Atlas集群数据集提取到云对象存储和内部技术目录 （并非Alation）组合当中，借此加快分析查询。
四、以人为本
长期以来，MongoDB一直是开发者们喜欢的数据库之一。这是因为开发者热爱JavaScript和JSON，目前JS在Tiobe人气指数中排名第七。而JavaScript、JSON和文档模型将是MongoDB的永恒主题。但很遗憾，由于MongoDB此前一直刻意回避SQL，所以也就失去了相应的庞大人才库——SQL开发者同样体量庞大，让这一查询语言在人气指数中位列第九。现在，是时候做出改变了。
虽然MongoDB仍然认为文档模型优于并有望取代关系模型（只是一家之言），但相信大家都认同一点：为了进一步扩大影响范围，MongoDB必须接纳那些以往被忽略的受众群体。要想双赢，两大阵营应该团结一致、实现简化；对于某些操作用例，我们不必将数据移动并转移至独立的数据仓库目标，而是简化为在统一平台内操作，终将数据提取转化为更简单的数据复制。
五、意不在取代数据仓库、
数据湖或智能湖仓
MongoDB绝不是要取代独立的数据仓库、数据湖或智能湖仓。目前复杂建模与发现已经成为分析工作中的重要组成部分，所以必须与操作型系统分别执行。更重要的是，在操作型数据库中支持分析，大的意义其实是实现流程内联并尽可能实时化。
换言之，MongoDB将由此实现与Snowflakes或者Databricks的全面协同。大家可以在数据仓库、数据湖或智能湖仓中开发用于识别异常值的模型，再将结果整理为一个相对简单、易于处理的分类、预测或规范模型。这样只要交易中出现异常，该模型就会被自动触发。
如今，在MongoDB中实现这样的闭环流程已经颇具可行性，但具体方法仍然非常复杂。大家需要将MongoDB中的变更流、触发器和函数拼凑起来，共同组织成某种封闭式的分析反馈循环。相信在不久的将来，MongoDB将把这些复杂性要素隐藏在后台，直接提供简单易用的闭环与近实时分析选项。这绝不是凭空想象，而是技术发展趋势的必然结果。如今，MongoDB已经踏上了这段分析探索之旅，我们也期待着它能早传捷报。
来源丨公众号：分布式实验室（ID：DistributedLab）
