数据解耦、分析引擎和 Starburst Trino

随着今天宣布 Starburst 支持 MinIO，重新审视正在成为分析工作负载标准的架构趋势变得很有意义。正如我们很快将看到的那样，Starburst 提供了一个完美的例子。

该架构遵循将存储和计算分离的模型。现代的高速网络已经淘汰了众多已消亡的 HDFS 供应商所推崇的旧方法——将数据传送到计算环境。

Starburst 的 Trino（以前称为 PrestoSQL）是一个 SQL 查询引擎——而不是一个 SQL 数据库。Starburst 摒弃了 SQL 数据库的存储组件，专注于一项——超快的 SQL 查询。Trino 只是一个查询引擎，不存储数据。相反，Trino 与各种数据库交互或直接在对象存储上运行。Trino 解析和分析您传入的 SQL 查询，创建和优化包含数据源的查询执行计划，然后调度能够智能地查询其连接到的底层数据库的 worker 节点。

Trino 的特别之处在于它针对数据层进行优化——无论是具有特殊索引和特定格式的数据库，还是对象存储。在 Trino 的大多数优化中，目标是将查询推送到下游，只获取与来自另一个数据库或对象存储的另一个数据集进行联接、执行一些进一步的 Trino 特定处理或简单地返回查询的正确结果集所需的最小数据量。

在 Starburst 的情况下，以及在许多其他数据库应用程序的情况下，性能必须在每个组件上都可用——计算/分析层、网络以及显而易见的数据层。

性能

与分析工作负载相关的存储性能需求在过去几年中发生了逆转。曾经的 IOPS 问题变成了吞吐量问题。这导致了对象存储的兴起。对象存储是以吞吐量驱动的，而不是以 IOPS 或延迟驱动的。

在 Starburst 的情况下——他们要求其数据存储的性能——数据存储越来越以对象存储为导向。Starburst 直接查询数据所在的存储位置。这可以是关系型数据库（MySQL）中的“维度”类型数据，以及/或者与 S3 中的原始数据联接的数据。数据库和原始数据都可以利用对象存储。这为他们节省了时间和金钱，因为他们不必将数据迁移到其他产品（例如 Amazon Redshift）中。

在 MinIO 的情况下，我们不仅是世界上吞吐量最快的对象存储，而且 MinIO 在小对象性能方面也表现出色，其中表段的范围从 256K 到 2MB。

这是有重要原因的。MinIO 由于其确定性散列来查找对象，因此不使用元数据数据库。当您将这些表段存储为小对象时，其他对象存储实现很快就会不堪重负。这使得原本就快速的 Trino 查询速度更快。

可扩展性

大多数文件和块系统并非为可扩展性而设计。因此，当您超过 100TB 时，就会开始出现权衡。当您达到 1PB 时——您处于这些系统的稀有空气中。

另一方面，对象存储在 1PB 时才开始进入其最佳状态。从那里开始，就没有上限了。这使得对象存储成为像 Starburst 这样的分析引擎的理想补充，它雄心勃勃地要针对覆盖组织数据的大部分组件的巨大应用程序工作负载进行交付。

鉴于快速对象存储的吞吐量能力，该模型很简单。一小部分数据保存在“内存中”以进行超快处理，而绝大多数数据都位于一个非常非常温暖的层级中——可以使用定义了现代应用程序生态系统的标准 S3 调用访问。

关键点

在我们之前与 Starburst 的合作中可以找到一个很好的例子。我们的基准测试仍然是 Presto 性能的标准，而且今天可能会更快。

结论

S3 API 是当今事实上的存储标准。POSIX 正在衰落——没有理由相信它会恢复。

因此，分析领域的领导者（如 Starburst）将支持 MinIO 列为优先事项——尤其是在我们提供的多云能力的情况下。MinIO 在 AWS、GCP、Azure、OpenShift、Tanzu、裸机、边缘等环境中运行的能力是独一无二的。接口的一致性和性能的深度使其成为任何大型架构的关键部分。
结果是存储和计算的有效分离，这两个元素都是各自领域中的佼佼者。我们鼓励您亲自尝试一下。您可以在此处下载 MinIO，并从 Starburst 获取文档信息。