对象存储数据库——新常态

当您考虑对象存储工作负载和存储类型时，您首先想到的并不是数据库。然而，这种情况正在迅速改变，仅由两种力量驱动：真实、高性能对象存储的可用性和数据的爆炸性增长，或许更具影响力的是与其相关的元数据。

由于这两种力量，几乎每个主要的数据库供应商现在都包含与 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 有一个很棒的教程，可以在此处集成两者。然而，更有趣的是他们在 OnTime 和 NYC Taxi 数据集上比较 MinIO 和 AWS的工作。

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

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

Altinity 还对纽约市出租车数据集进行了基准测试——这可能是使用最广泛的基准测试数据集。该数据集包含 11 亿条记录、51 列，在未压缩的 CSV 格式下大小为 500 GB。再次，“对象存储”的速度非常出色：

这些速度将使 Clickhouse/MinIO 进入Mark Litwintschik 的快速数据库列表（公平地说是快速硬件）的前 15 名。

再次 - 我们鼓励您完整地接受这些帖子。

雪花

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

其他例子

不要只相信我们的话。拿你最喜欢的数据库。像MongoDB。或MariaDB。或CockroachDB。或Teradata。名单很长而且很突出，谷歌可以让你快速到达那里......

结论

S3 API 是当今存储的事实标准，将 POSIX 降级为“不可逆转的衰退”状态。其结果是，几乎所有的数据库现在支持S3 API -但只有那些“S3兼容的对象存储”的极少数能够提供的性能和规模的结合，更重要的是，表现在规模，需要支持的用例的范围一个现代企业想要的。

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

结果是存储和计算的有效分离，并为这两个元素提供了最佳选择。我们鼓励您亲自尝试一下。您可以在此处下载 MinIO或在您最喜欢的数据库博客上查找教程。只需输入他们的名字和 MinIO - 某个地方的某个人可能已经完成了这项工作。