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