对象存储上的数据库 - 新常态

当您考虑对象存储工作负载和存储类型时，数据库正日益成为核心工作负载。这些变化是由两种力量驱动的：高性能对象存储的可用性和数据（特别是其关联的元数据）的爆炸式增长。

由于这两种力量，几乎所有主要的数据库供应商现在都包含与 S3 兼容的端点。此外，对于许多组织和大多数工作负载而言，无论是在云端还是本地，这都成为默认架构。

让我们简要探讨一下这些概念。

性能

与数据库相关的存储性能需求在过去几年里发生了逆转。数据库以前需要高 IOPS。这是由于需要通过网络进行大量的小更改。这非常适合 SAN 和 NAS 架构，因此数据库成为它们的重中之重。问题是 IOPS 并不特别具有可扩展性——至少在经济上不是。

数据库不再以 4KB 块的形式通过网络更改数据。相反，它们以 MB 大小的范围将对象（特别是表段）流式传输到客户端内存并在本地更改它们。本地内存 IOPS 结合 100GBe 使其成为吞吐量问题，而不是 IOPS 问题。

对象存储是吞吐量驱动的，而不是 IOPS 或延迟驱动的。即使在当今高性能对象存储和 NVMe 驱动器时代，这一点也依然成立。新的数据库模型非常适合对象存储，因为范围本质上是不可变的。由于每次更改都会自动版本化，因此对象存储可以提供持续的数据保护，而无需快照。

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

这样做的原因很重要。MinIO 不使用元数据数据库，因为它使用确定性哈希来查找对象。其他对象存储实现 在存储这些表段作为小对象时很快就会不堪重负。

为了使对象存储能够托管数据库，它需要提供卓越的吞吐量以及可接受的延迟。它在这些指标上表现得越好，迁移到对象的负载百分比就越高。这应该是有道理的。如果对象存储可以提供硬件级别的吞吐量和可接受的延迟，它可以运行 80% 或更多数据库的需求。如果做不到，它只适用于 20-30% 的工作负载——实际上就是备份。

MinIO 满足了这些新的需求，因此成为这种日益流行的架构的领先对象存储。

如果您觉得这听起来很熟悉，那它确实如此。这是分解的叙述。数据库供应商实际上选择分解存储和计算——声称计算端属于自己，并将存储卸载到高性能对象存储。他们专注于分布式、高性能查询处理。通过这样做，他们专注于特性和功能，并将存储的繁重工作留给像 MinIO 这样的公司。结果是，由于对象存储的可扩展性特性，他们现在可以声称拥有越来越多的数据。

让我们暂时关注一下这一点。

可扩展性

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

另一方面，对象存储在 1PB 时才开始达到其最佳状态。从那里开始，天空才是极限。这使得对象存储成为数据库的理想补充，这些数据库雄心勃勃地想要满足覆盖组织大量数据的大型应用程序工作负载。

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

当支持 S3 Select 时，这一点更加有效。只有少数供应商支持此谓词下推功能，并且没有一个能够提供高性能。MinIO 可以做到——因此，只需从 PB 级别的数据中提取所需的数据即可。这就是 MinIO 在数据库供应商社区中如此受欢迎的原因。

Altinity/Clickhouse

一个很好的例子可以在我们与 Altinity 的合作中找到，该公司专门从事闪电般快速、功能丰富的 Clickhouse 数据仓库。Altinity 有一个关于集成这两者的极好的教程 在这里。然而，更有趣的是他们的工作 比较 MinIO 和 AWS 在 OnTime 和 NYC Taxi 数据集上的表现。

OnTime 数据集包含近两亿行航空航班数据。Altinity 选择此数据集进行性能基准测试，因为该数据集包含 109 列。

基准测试利用 S3 Select 来优化数据摄取，从而加快查询速度。

Altinity 还对 NYC Taxi 数据集进行了基准测试——也许是最广泛使用的基准测试数据集。该数据集包含 11 亿条记录，51 列，并且在未压缩的 CSV 格式下大小为 500 GB。同样，对于“对象存储”而言，这些速度简直令人惊叹。

这些速度将使 Clickhouse/MinIO 跻身 Mark Litwintschik 的快速数据库列表（以及公平的快速硬件）的前 15 名。

再次，我们鼓励您完整阅读这些帖子。

Snowflake

Snowflake 是 Amazon S3 最大的工作负载之一，并且仍然是增长最快的之一。它构建在对象存储之上——就像每个其他现代系统一样。他们当然可以选择构建在 EFS 或 EBS 之上，但他们没有这样做。这不仅仅是 经济因素。这是规模问题。

Microsoft SQL Server

SQL Server 是最早支持对象存储的数据库之一，而 MinIO 是其实施的典范。我们有很多关于它的内容，但您可以从 这里 开始。

InfluxDB

Influx 是另一个例子。这个出色的基于 Go 的时间序列数据库已将对象存储变成了 一等公民，并且继续 加倍押注。

其他示例

不要只听我们说。选择您最喜欢的数据库。比如 MongoDB。或者 MariaDB。或者 CockroachDB。或者 Teradata。或者 DuckDB。或者列表很长，而且很著名，谷歌可以快速帮您找到…

结论

如今，S3 API 是事实上的存储标准，将 POSIX 降级到“不可逆转的衰落”状态。因此，几乎每个数据库现在都支持 S3 API——但只有少数这些“与 S3 兼容的对象存储”可以提供性能和可扩展性的组合，更重要的是，提供支持现代企业所需的一系列用例所需的规模性能。

使用 MinIO，您可以获得这三者，这就是为什么我们是现代数据库和数据仓库的首选对象存储——无论是在本地还是 在公共云中，MinIO 都随处可见。

结果是存储和计算的有效分离，两者都拥有最佳功能。我们鼓励您亲自尝试一下。您可以从 这里 下载 MinIO 或在您最喜欢的数据库博客上找到教程。只需输入他们的名称和 MinIO——有人，某个地方可能已经完成了这项工作。