分解、分析引擎和 Starburst Trino

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

该架构遵循分解存储和计算的模型。现代高速网络已经淘汰了许多已倒闭的 HDFS 供应商所拥护的旧方法——将数据带到计算中的方法。

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

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 获取文档信息。