纠删码计算器
参考硬件
以对象存储为中心的世界的数据库
长期以来，数据库一直是基于 SAN 的块存储和基于 NAS 的文件存储的主要工作负载。 现代对象存储的兴起扰乱了这个看似静态的领域，预计整个 OLAP 数据库领域将在未来几年内转向对象存储优先的定位，只为 SAN/NAS 留下少数日益利基的工作负载 供应商（在 OLAP 领域，OLTP 是一个不同的故事）。
原因很简单——数据库访问的数据规模太大，无法容纳在内存中，而数据库供应商本身对成为存储供应商并不是特别感兴趣。 数据库行业的激烈竞争集中在高速和先进的查询、聚合和地图缩减功能上。 支持存储规模的天然合作伙伴关系在于云原生数据存储提供商（MinIO、AWS S3、Azure Blob、GCP）。
在此模型中，组织将来自各种来源的大量数据存储在对象存储中，然后通过其首选数据库进行查询来访问这些数据。 通过使用这种架构，这些组织选择了一种简化且真正现代的数据管理方法。 他们随时随地查询、连接和分析数据，而不是留下有价值的数据或构建复杂、昂贵且通常脆弱的数据管道以将其移动到中央数据库。
数据库通常通过外部表与作为主存储的对象存储进行交互。 外部表是允许用户访问和查询数据库外部数据的数据库对象。 用户可以通过外部表定义来定义外部数据的结构和位置，然后像数据在数据库中一样执行SQL查询，使外部数据的外观和行为就像常规数据库表一样。
该策略与分解存储和计算的整体数据架构设计相一致，组织可以独立分配和扩展这些资源，从而优化两者的性能。 不幸的是，最有价值的数据往往是您选择留下的数据。 分解释放了数据库的存储压力，使组织能够收集和存储所有宝贵的数据，而不是被迫根据任意阈值进行挑选以保持查询性能。
这种现象在两端都有发生。 数据库不仅自愿采取这一举措，企业也通过积极推动和/或选择能够直接从对象存储读取而无需摄取的供应商来加速转型。 这是有道理的，因为这些企业正在使用现代对象存储和现代开放表格式（如 Iceberg）来构建数据湖。
对象存储作为主存储的证据
我们从早期开始就将对象存储作为主要存储运动进行了介绍，并有伤痕来证明这一点。 曾经被认为是亵渎的东西现在被认为是公认的事实（请随意询问伟大的野外日系列的斯蒂芬·福斯克特）。 尽管如此，对于那些不太熟悉的人来说，这里是现代对象存储成为主存储的原因：
- 云原生对象存储专为可扩展性而设计，使其成为拥有管理大量工作负载的数据库的组织的完美选择。 软件定义的 MinIO 使用服务器池快速轻松地扩展。
- 成本效益是决定转向面向未来的对象存储的另一个因素。 组织无需花费时间和金钱来处理数据，而是通过访问数据（无论数据位于何处）来节省时间和金钱。
- 控制，以及安全性的潜台词，是转向对象存储作为主存储的决定的核心。 通过这种架构，您的数据永远不会在安全协议之外移动或复制。 您可以获得完整数据集成的所有可扩展性优势，并且不会出现开始移动数据时可能出现的安全陷阱。 MinIO 符合静态加密的行业标准，并支持连接到本地和云 KMS 提供商，例如 Hashicorp Vault 或 Amazon Web Services KMS。
- 对于有兴趣在云提供商和本地解决方案之间进行选择以获得最佳交易的数据架构师来说，可移植性至关重要。 在这里，支持对象存储的不同原因开始交织在一起，因为这种唯利是图的方法可以产生节省成本的效果。 MinIO 可以部署在公共云、私有云、裸机基础设施、编排环境和边缘。 所有的大门都向对象存储敞开，它并不关心你的数据存放在哪里。
- 数据可访问性至关重要，无需数据迁移中涉及的额外步骤即可轻松访问数据，这一点非常重要。 最简单的设计通常是最坚固的。
- 对于任何运行数据密集型工作负载的存储系统来说，性能可能是最重要的组成部分。 作为应用程序堆栈的基础，对象存储性能可以决定应用程序采用的成功或失败。 MinIO 是最快的对象存储 可用的。
领先的对象存储优化数据库调查
根据易用性（Y 轴）和优化级别（X 轴）比较数据库的图表，突出显示它们在对象存储上的定位。
每一个动作都始于某个大胆的玩家的行动。 在技术领域，他们通常是新贵。 在数据库领域，情况恰恰相反。 该领域的庞然大物已经转向对象存储。 部分原因是这些庞然大物的目标是最大的大型企业，而他们又面临着海量数据的挑战，要求他们采用现代对象存储。 部分原因是庞大的数据库玩家更关注世界的发展方向，而不是关注世界的过去。 不管怎样——这里是对支持对象存储作为一等公民的领先数据库的调查。
Snowflake 是外部表运动的先驱，于 2021 年推出了该功能。这种集成不仅简化了数据流并加速了数据可用性，而且还节省了成本，并且能够在不移动数据的情况下分析实时数据。 Snowflake 支持外部表的自动和手动分区。 应该指出的是，这对于 Snowflake 来说是一个简单的举动 - 他们自成立以来一直在转售 S3 存储。 他们比任何人都更欣赏对象存储的强大功能和规模。
Microsoft SQL Server 2022 brought two valuable, MinIO-centric features to the market with the 2022 release: S3 API support for cloud backup and expanded external tables for flexible data querying without movement. This integration allows seamless access to diverse data sources, reduces data replication efforts, and enhances disaster recovery. Plus, SQL Server 2022's security and compliance features pair well with MinIO's tiering capabilities, making it easier to process both relational and non-relational data efficiently.
演示使用 SQL Server 2022 在 MinIO 上存储和查询数据
Teradata 通过本机对象存储 (NOS) 与对象存储进行交互。 NOS 于 2021 年宣布支持对象存储。NOS 利用 SQL 与 S3 存储桶中存储的数据进行交互，使其 Vantage NewSQL 引擎能够直接从 MinIO 读取数据。 当前支持包括 JSON、CSV 和 Parquet 等关键格式，并计划将来合并 AVRO、ORC 和 TXT。
Teradata Vantage 与本机对象存储如何降低成本
Oracle 首先在 2019 年为自治数据库引入了 DBMS_CLOUD 包，最近又在 2022 年为本地安装引入了 DBMS_CLOUD 包。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’s 外部数据的概念允许用户通过 PostgreSQL 内部的查询来访问 PostgreSQL 外部的数据。 这些数据可以通过深受喜爱的称为外部数据包装器 (FDW) 的库来访问。 虽然 FDW 并未得到 PostgreSQL 的正式支持，但它们已经存在很长时间了，并于 2013 年首次推出。正如预期的那样，FDW 的用例远远超出了对象存储，但有一些包装器支持与 S3 兼容的存储访问 PostgreSQL。 值得注意的是，2022 年，为 s3 兼容存储中的 Parquet 文件开发了 FDW。 此 FDW 支持 MinIO 访问而不是 Amazon S3。 PostgreSQL 还可以用作发布 MinIO 存储桶通知的端点。
PostgresQL 的 GitHub Parquet S3 外部数据包装器
Greenplum 是一个基于 PostgreSQL 的开源数据仓库项目。 2019 年 Greenplum 开始支持通过外部表与 MinIO 交互。 该过程非常简单，包括授予权限、定义路径和设置外部表。 关于本教程的简短程度，有一些话要说。
YugaByteDB 是分布式 PostgreSQL 实现，自 2021 年以来已包含 PostgreSQL 外部数据包装器扩展。YugaByteDB 使用 FDW API 作为常规代码路径中的封装层。 备份和恢复也是一个有效的 MinIO 和 Yugabtye 用例。
MySQL MySQL Server 支持外部表，但 HeatWave 可以提供对对象存储更强大的支持。 HeatWave 稍微扩展了数据库的定义和 MySQL 的类别，而不是 Oracle，HeatWave 是 Oracle 于 2020 年推出的完全托管的 MySQL 服务。HeatWave 支持手动或通过首选自动化方法从对象存储创建外部表：HeatWave Lakehouse Auto Parallel Load 程序。 MySQL Server 还可以用作发布 MinIO 存储桶通知的端点。
ClickHouse2020 年，使用 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支持存储发出的changefeed消息在对象存储中。 通过这个用例，我们开始模糊数据库和数据湖屋之间的界限，从这里用例列表可以继续下去。
结论
数据库在企业中并没有消失——事实上它变得越来越重要。 话虽如此，现代对象存储通过赋予这些数据库本身无法容纳的规模，有效地增强了这些数据库的价值。
不过，请不要相信我们的话。 请立即查看上面的链接并下载 MinIO 亲自查看。 如果您对将 MinIO 用于特定数据库有任何疑问，请随时通过 sales@minio.org.cn与我们联系或加入我们的支持性 Slack 社区以获取帮助和讨论。