打破原则！MongoDB 引入 SQL？

来源丨公众号：分布式实验室（ID：DistributedLab）

大概六年前，在为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已经踏上了这段分析探索之旅，我们也期待着它能早传捷报。