擦除码计算器 
参考硬件 面向对象存储世界的数据库
长期以来，数据库一直是基于SAN的块存储和基于NAS的文件存储的核心工作负载。现代对象存储的兴起打破了这一看似静态的领域，预计未来几年整个OLAP数据库领域将转向以对象存储为首要位置，仅为SAN/NAS供应商留下少量日益利基的工作负载（在OLAP领域，OLTP的情况有所不同）。
原因很简单——数据库访问的数据规模过大，无法完全放入内存，而且数据库供应商本身也不太愿意成为存储供应商。数据库行业的激烈竞争集中在高速和高级查询、聚合以及MapReduce功能上。支持存储规模的自然合作伙伴是云原生数据存储提供商（MinIO、AWS S3、Azure Blob、GCP）。
在这种模式下，组织将来自各种来源的大量数据存储在对象存储中，然后通过他们首选的数据库和查询访问这些数据。通过使用这种架构，这些组织选择了一种简化且真正现代的数据管理方法。他们可以在数据所在的位置查询、连接和分析数据，而无需舍弃有价值的数据，或构建复杂、昂贵且往往脆弱的数据管道将其移动到其中央数据库。
数据库通常通过外部表与对象存储交互作为主要存储。外部表是数据库对象，允许用户访问和查询驻留在数据库外部的数据。用户可以通过外部表定义来定义外部数据结构和位置，然后执行SQL查询，就像数据在数据库中一样，使外部数据看起来并像常规数据库表一样运行。
此策略与存储和计算解耦的整体数据架构设计相一致，组织可以独立地分配和扩展这些资源，从而优化两者的性能。不幸的是，最有价值的数据通常是您选择舍弃的数据。解耦释放了数据库的存储压力，使组织能够收集和存储所有宝贵的数据，而不是被迫根据任意阈值进行选择，以保持查询性能。
这种现象正在两端发生。数据库不仅在自主做出这一转变，企业也正在通过积极推动和/或选择能够直接从对象存储读取而无需导入数据的供应商来加速这一转变。这是有道理的，因为这些相同的企业正在使用现代对象存储和现代开放表格式（如Iceberg）构建数据湖。
对象存储作为主要存储的证据
我们从对象存储作为主要存储运动的早期阶段就开始关注它，并且有伤痕可以证明这一点。曾经被认为是异端的做法现在被认为是公认的事实（随时可以询问Field Day系列的Stephen Foskett）。尽管如此，对于那些不太熟悉的人，以下是现代对象存储是主要存储的原因：
- 云原生对象存储专为可扩展性而设计，使其成为管理大量工作负载的数据库组织的完美选择。软件定义的MinIO使用服务器池快速轻松地扩展。
- 成本效益是转向面向未来的对象存储的另一个因素。组织不再花费时间和金钱来移动数据，而是通过访问数据所在的位置来节省时间和金钱。
- 控制，以及安全性的含义，是决定将对象存储作为主要存储的核心因素。使用此架构，您的数据永远不会在您的安全协议之外移动或复制。您可以获得完整数据集成的所有可扩展性优势，而不会出现数据移动时可能出现的任何安全陷阱。MinIO符合静态加密的行业标准，并支持连接到本地和云KMS提供商，如Hashicorp Vault或Amazon Web Services KMS。
- 可移植性对于那些希望在云提供商和本地解决方案之间寻找最佳交易的数据架构师至关重要。在这里，支持对象存储的不同原因开始交织在一起，因为这种雇佣兵的方法可以节省成本。MinIO可以部署在公共云、私有云、裸机基础设施、编排环境以及边缘。所有通往对象存储的大门都是敞开的，它不关心您的数据存储在哪里。
- 数据可访问性至关重要，无需数据迁移的额外步骤即可访问您的数据，这令人难以置信地增强了能力。最简单的设计通常是最强大的。
- 性能可能是运行数据密集型工作负载的任何存储系统中最重要的组成部分。作为应用程序堆栈的基础，对象存储性能可以决定应用程序采用的成功或失败。MinIO是最快的对象存储。
领先的对象存储优化数据库概述
每个运动都是从一些大胆的参与者采取行动开始的。在技术领域，他们通常是后来者。在数据库领域——情况正好相反。是该领域的巨头转向了对象存储。部分原因是这些巨头以最大的大型企业为目标，而这些企业反过来又面临着数据量方面的挑战，这要求他们采用现代对象存储。部分原因是大型数据库厂商更关注世界发展的方向——而不是它曾经的样子。无论如何，这里是对支持对象存储作为一等公民的领先数据库的调查。
Snowflake是外部表运动的先驱，于2021年推出了此功能。此集成不仅简化了数据流并加速了数据可用性，还提供了成本节约和无需数据移动即可分析实时数据的功能。Snowflake支持外部表的自动和手动分区。需要注意的是，这对Snowflake来说是一个简单的举动——他们自成立以来一直在转售S3存储。他们比任何人都更了解对象存储的强大功能和规模。
Microsoft SQL Server 2022在2022年发布中为市场带来了两个有价值的、以MinIO为中心的特性：云备份的S3 API支持以及扩展的外部表，用于灵活的数据查询而无需移动。此集成允许无缝访问各种数据源，减少数据复制工作，并增强灾难恢复。此外，SQL Server 2022的安全性和合规性功能与MinIO的分层功能相结合，使高效处理关系数据和非关系数据变得更加容易。
使用SQL Server 2022在MinIO上存储和查询数据的演示
Teradata通过原生对象存储（NOS）与对象存储交互。NOS对对象存储的支持于2021年宣布。NOS利用SQL与存储在S3存储桶中的数据交互，使他们的Vantage NewSQL引擎能够直接从MinIO读取数据。当前支持包括JSON、CSV和Parquet等关键格式，并计划在未来纳入AVRO、ORC和TXT。
Oracle于2019年首先为自治数据库推出了DBMS_CLOUD包，然后在2022年为本地安装推出了最新版本。DBMS_CLOUD提供对与S3兼容的对象存储中的数据进行操作的支持。DBMS_CLOUD可用于复制数据，也可用于创建和管理外部表。请注意，测试是在AWS S3上进行的。
DuckDB是一个免费的开源SQL OLAP数据库。DuckDB作为一个内存进程运行，不会持久化任何数据。为了持久化数据，您必须在服务运行时提供路径或附加数据库文件。这种超轻量级设计使DuckDB高度优化了对象存储，因为它始终提供对S3 API的支持。DuckDB为此超级简单直观的支持调用扩展：httpfs。httpfs扩展支持读取/写入/通配文件。
Apache Druid 是一个高性能数据库，从一开始就兼容 S3。Druid 与对象存储的交互方式非常独特。用户可以从 MinIO 中导入数据，并在使用数据时使用本地文件系统。用户不积极使用的数据集可以推送到 MinIO 的深度存储中，以提高存储效率。
如何使用 MinIO 运行 Apache Druid 和 Apache Superset
Vertica 从 2022 年开始支持直接从对象存储查询数据，而不是将数据加载到 Vertica 中。这些外部表可以配置为查询各种数据格式，包括 Parquet、ORC、纯文本和分隔符文件格式。Vertica 中的外部表已针对 S3 进行了测试。
PostgreSQL 的外部数据概念允许用户在 PostgreSQL 内部使用查询访问 PostgreSQL 外部的数据。可以通过称为外部数据包装器 (FDW) 的常用库访问此数据。虽然 FDW 没有得到 PostgreSQL 的官方支持，但它们已经存在很长时间了，最早在 2013 年引入。正如预期的那样，FDW 的用例远远超出了对象存储，但有一些包装器支持 PostgreSQL 的 S3 兼容存储访问。值得注意的是，2022 年开发了一个用于 s3 兼容存储中 Parquet 文件的 FDW。此 FDW 支持 MinIO 访问，而不是 Amazon S3。PostgreSQL 还可以用作发布 MinIO 存储桶通知的端点。
GitHub ParquetS3 外部数据包装器用于 PostgresSQL
Greenplum 是一个基于 PostgreSQL 构建的开源数据仓库项目。2019 年，Greenplum 开始支持通过外部表与 MinIO 交互。这个过程非常简单，包括授予权限、定义路径和设置外部表。关于教程的简短性，也有一些话要说。
YugaByteDB 是分布式 PostgreSQL 实现，并从 2021 年开始包含 PostgreSQL 外部数据包装器扩展。YugaByteDB 使用 FDW API 作为常规代码路径中的封装层。备份和恢复也是 MinIO 和 Yugabtye 的有效用例。
MySQL 外部表受 MySQL Server 支持，但可以使用 HeatWave 找到对对象存储更强大的支持。稍微扩展数据库和 MySQL 类别的定义（而不是 Oracle），HeatWave 是 Oracle 于 2020 年推出的完全托管的 MySQL 服务。HeatWave 支持从对象存储手动创建外部表，或通过首选的自动化方法：HeatWave Lakehouse 自动并行加载过程。MySQL Server 还可以用作发布 MinIO 存储桶通知的端点。
ClickHouse 于 2020 年引入了使用 S3 API 的 S3 兼容对象存储支持。除了基本导入功能外，ClickHouse 还支持将对象存储用于其 MergeTree 表引擎。MergeTree 允许逐部分将数据插入表中，这可能会更高效。不利的一面是，这种类型的集成意味着在 ClickHouse 内部完全复制对象存储中的数据。
虽然此列表是一个良好的开端，但如果您知道我们错过了某个数据库或正在开发中的数据库，请告诉我们，我们将继续更新此调查。
限制
以对象存储为中心的策略有一些限制。例如，外部表通常是只读的 - 您无法对它们执行任何数据操作语言 (DML) 操作，例如 INSERT、UPDATES 或 DELETES。通常无法将数据库中的更改推送到对象存储中。但是，这种设计实际上可以为性能和数据质量带来好处。它可以防止给数据基础设施带来相同数据的多个副本的负担，并确保更改仅限于视图，避免对真实数据源的混淆。
此外，使用对象存储的表将比存储或缓存本地存储在数据库中的表的查询性能慢。查询延迟的程度是许多因素的函数 - 也就是说，MinIO 的性能非常出色，在某些基准测试中表现出优于其他对象存储提供商的优势。例如，在一个基准测试中，该测试涉及将包含近 2 亿行（142 GB）的数据集加载到数据库中，MinIO 存储桶显示出比竞争对手快近 40% 的性能提升。鉴于初始查询的持续时间取决于数据传输大小，将 MinIO 的性能与数据库本机缓存层相结合将使后续查询更快。我们的专家可以帮助您设计一个最大限度地提高基础设施性能的解决方案，同时为未来的修改提供建议，以便发挥更大的作用。
可以针对通过对象存储创建的表采用其他策略来提高查询性能，包括创建物化视图。有关这些策略的更多信息，最好在数据库本身的文档中查找。
对象存储与数据库的其他用例
显然，对象存储与数据库的其他用例包括备份和恢复。这个传统的用例可以从现代对象存储方法中获益匪浅。例如，MinIO Jumbo 提供了一种有效的解决方案来加速备份和恢复过程。通过利用并行处理的强大功能，Jumbo 优化了备份写入对象存储的速度。它利用所有可用带宽来快速将备份文件传输到 MinIO。考虑到 MinIO 以成为最快的对象存储解决方案之一而闻名，并且 Jumbo 充分利用了您的网络容量，因此限制备份速度的唯一因素是数据库的性能。将存储留给存储专家，并让数据库供应商对其自身的性能负责。MinIO Jumbo 的一些强大的用例包括Cassandra 和 MongoDB。
对象存储的另一个用例是作为更改数据捕获 (CDC) 的接收器。例如，CockroachDB 支持在对象存储中存储发出的更改提要消息。在这种用例中，我们开始模糊数据库和数据湖仓之间的界限，从这里开始，用例列表可以继续下去。
结论
数据库在企业中不会消失 - 事实上，它变得越来越重要。话虽如此，现代对象存储通过为这些数据库提供它们无法本地容纳的规模，有效地增强了这些数据库的价值。
不过，不要听我们说。通过查看上面的链接并立即下载 MinIO 来亲身体验。如果您对将 MinIO 用于您的特定数据库有任何疑问，请随时联系我们 hello@min.io 或加入我们支持的 Slack 社区以获取帮助和讨论。