打破原则引入SQL,MongoDB到底想要干啥???

2022-07-25 00:00:00 数据 分析 数据库 操作 提供

大概六年前,在为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)


相关文章