上周，Snowflake公布了一系列扩大其足迹的公告。它正在拥抱数据湖屋，其对Apache Iceberg的新支持是Snowflake本机表格式的替代方案。它正在增加交易，并寻求使开发人员成为其市场中的一等公民。随着Snowpark的新支持，Snowflake表明它认真地适应Python开发人员与Anaconda精选Python库组合的深度集成。
但在这篇文章中，我们想关注两个快速增长的云数据库提供商是否最终会相互碰撞的问题。我们将在下一篇文章中讨论Python和数据湖库。
雪花 vs. 蒙戈 DB
乍一看，这个问题是荒谬的。在数据库世界中，人们很难想象还有两个截然相反的对立面：基于SQL的分析平台与避开SQL的操作数据库。或者更重要的是，一个提供商将其产品定位为“数据云”，而另一个提供商是应用程序优先的，而不是数据开发人员优先的。
但在掩护下，两者都在慢慢进入对方的领地。诚然，它来自对立的起点和选区，但交汇点将是运营分析。
正如我们在关于MongoDB的评论中所阐述的那样，将运营数据和分析结合在一起是有令人信服的理由的。指导思想是，将分析折叠到事务处理中具有重要价值，从而产生“智能交易”。用例非常熟悉。客户进入电子商务网站，在下订单时，该网站会提供旨在向上销售或交叉销售客户的建议，或添加甜味剂以防止客户流失。
对于涉及物联网的应用的预防性维护，或由医疗设备读数驱动的治疗建议，也可以这样说。显然，Snowflake的目标不是不涉及分析的OLTP用例 - 但显然，随着事务和分析之间的分界线模糊，这并不排除许多用例。
对于Snowflake来说，通过两个公告来扩大其功能和可寻址的受众足迹，融合变得清晰起来。第一个是新的 Unistore 事务系统，它基于混合行/列存储，该存储独立于支持分析母船的云对象存储和缓存。Unistore将为Snowflake带来轻量级的交易处理。第二个公告是关于将应用程序开发人员吸引到Snowflake数据云，是新的本机应用程序框架，旨在为开发人员提供一种在新更名为Snowflake Marketplace上将其数据应用程序货币化的方法。
相比之下，MongoDB一直是关于开发人员的，鉴于首席技术官Mark Porter等发言人最近的主题演讲，它是关于清除开发人员使用数据不断开发新应用程序的减速带。然而，除了上周的开发人员啦啦队主题演讲之外，还有微妙的举措，使MongoDB对分析更加友好。在这些亮点中，仍然轻描淡写SQL的公司实际上已经编写了第一个严肃的SQL查询引擎。
让我们从紫光开始
那么，什么是紫光？它是一个混合行和事务数据存储，可将 Snowflake 的可寻址占用空间扩展到轻量级事务应用程序。到目前为止，Snowflake在描述其引擎的细节方面相当模糊，但他们将是第一个承认他们不会很快取代Oracle或SQL Server用于关键任务企业应用程序或Amazon Aurora或Google Cloud SQL等云事务巨头的人。
Unistore每秒可以处理多达数千个事务，这几乎不是网络规模。相反，他们的目标是维护机器学习 （ML） 模型的特征存储、跟踪应用程序的状态（如 ETL 操作）或执行清单检查等功能等用例。目前，Snowflake的Unistore抱负不大。当你问Snowflake他们的目标是什么时，他们故意将其描述为“新应用程序”而不是遗留问题。这听起来有点像MongoDB？
不是第一个采用混合
Snowflake和MongoDB并不是第一个尝试折叠分析和交易数据库的公司。就在今年，谷歌和甲骨文宣布了基于云的PostgreSQL和MySQL服务，将两者融合在一起，上周推出了NoSQL实时数据库Aerospike，集成了基于SQL的Starburst Trino联合查询引擎。在此之前，我们还看到IBM，Oracle和MariaDB提供了混合平台，其中基于行的事务存储与内存中列分析表并排配对。混合的想法实际上可以追溯到近十年前，当时IBM Db2 BLU出现。
理想情况下，所需的最终状态将是内联的实时“智能交易”，它会自动触发一个简单的分析步骤，以便在响应异常交易时做出快速决策。然而，现实情况是，虽然复制可能是实时的，但分析并没有与事务集成在一起，形成一种闭环过程。相反，指导思想是通过消除 ETL 和对单独数据仓库的需求来简化数据库堆栈。
而且，正如我们在上周对MongoDB所指出的那样，您对操作或事务数据库做的最后一件事就是通过复杂的分析来减慢它的速度。您可以在这些混合系统中进行分析，但如果没有显著的工作负载隔离，这些分析必须相对轻量级，不涉及数百或数千个表的复杂联接，也不需要密集计算。为此，您仍然需要专用的数据仓库、数据湖或数据湖仓，或像Oracle Exadata这样的高度工程化系统。
向数据应用程序云演进
好吧，这不是雪花的正式名称，但它也可能是。
凭借其原生应用程序框架，Snowflake正在简化开发人员将其应用程序引入其市场的途径。虽然Snowflake没有改变其Data Cloud品牌，但他们正在将市场的品牌从Snowflake Data Marketplace更改为简单的Snowflake Marketplace。该框架不仅提供 API，还提供打包运行时的功能，以便保护其代码不被复制，同时客户的数据仍然受到保护，因为它不必移出 Snowflake。
乍一看，Snowflake似乎正在寻求从将MongoDB放在地图上的人群中获得爱。但仔细观察是，Snowflake吸引的不是在文档数据库中使用变量模式的典型JavaScript开发人员，而是针对可能用各种语言编写代码的开发人员，但习惯于将其代码作为用户定义的函数，用户定义的表函数或关系数据库中的存储过程运行。在 Snowpark 工作的数据科学家和数据工程师也存在类似的问题，但有一个值得注意的例外：他们可以选择通过外部函数执行代码。当然，这引发了关于在 Snowflake 环境中运行所有内容还是引入外部服务器的性能更高的争论——我们将在另一篇文章中探讨。
虽然使用JSON的面向文档的开发人员可能会将SQL UDF视为外国领域，但Snowflake通过本机应用程序框架非常清楚地传达了一个信息：只要开发人员想在UDF中运行他们的代码，他们就会像数据人员一样欢迎从他们的工作中获利。
直截了当
虽然Snowflake的市值最近与其他科技行业一起下降，但Snowflake和MongoDB都被认为是超大规模数据库的领先云原生数据库替代品。两者都有成为AWS的真正友敌的区别。
乍一看，似乎恒星正在对齐，两者都将开始在各自的雷达屏幕上看到对方。两者都在踮起脚尖进入对方的领域。Snowflake增加了一个事务存储，并积极吸引开发人员，而MongoDB已经悄悄发布了它的第一个可信SQL引擎，不是为了让MongoDB成为一个关系数据库，而是为了支持分析查询;它伴随着其他功能，例如扩展的联合查询功能，以扩展Mongo的范围。
在短期内，两家公司方法的相似之处是肤浅的：Snowflake吸引了一种与MongoDB截然不同的开发人员。但是，从长远来看，我们预计两者都会相互碰撞。我们注意到，虽然数据库将继续差异化，但市场要求重叠。Snowflake从一开始就解决了这个问题，作为首批云数据仓库之一（这是在他们重新定位到数据云之前的日子里），以支持JSON作为一等公民。而且，尽管MongoDB公开声明，但它正在悄悄地拥抱SQL。共同点是，两者都在寻求从部门跳到企业的跨越，当他们这样做时，他们必须扩大对更多选民的吸引力。
今天，Databricks是Snowflake更明显的竞争对手。是的，存在来自超大规模企业的竞争，但Snowflake和Databricks都将自己定位为多云世界中的分析生态系统目的地。两者都朝着数据湖屋前进;Snowflake正在从习惯于使用SQL的数据分析师的选区接近它，而Databricks更传统地吸引Java，Scala和Python开发人员，Snowflake正在向Snowpark求爱。
椰有料原创，作者：小椰子啊，转载请注明出处：http://www.studioyz.com/4263.html
文章评论