存储和检索 547.500.000.000 条记录

Posted 2023-03-11

【中文标题】存储和检索 547.500.000.000 条记录

【英文标题】：Storing and retrieving 547.500.000.000 of records

【发布时间】：2014-09-09 17:20:20

【问题描述】：

我有以下问题。我需要 10 年每天 150 条 MM 记录。总记录 150MM * 365 * 10 = 547.500.000.000 条记录。数据库记录有一个唯一的键 date, id。我需要使用这个数据库每天恢复 40MM 记录。我将始终使用键 date, id 进行搜索。该过程可以批量运行。我考虑过使用键值对数据库，例如 HBase，按日期对我的数据库进行分片。 （不确定 HBase 是否允许您选择如何对集群内的记录进行分区。）。或者干脆把 HBase 分片留给我。

我看到了一个使用 mysql 分区的类似问题。 (Efficiently storing 7.300.000.000 rows) 我不知道MYSQL是否可以在多台机器上进行分区。或者如果我可以只使用一台机器来处理这个问题。

您相信这种架构会奏效吗？ 如果没有，解决问题的另一种方法是什么？ 欢迎提出建议和提示！

【问题讨论】：

地球上什么要求你存储这么多数据？你是在记录 CERN 数据还是什么？

超过 4 TB 仅用于密钥。不错。现在我的问题是：如果数据是按日期排序的，你确定你需要一个数据库吗？固定布局存储可能会以某种方式拆分（每年？）？如果您真的不需要 SQL 功能

，搜索和加载/存储都可以更快

确实，您的数据是关系吗？如果不是，那么对于这种数据量，关系数据库管理系统（例如 MySQL）绝对不是完成任务的正确工具。

@PieterGeerkens：我每天有 150 条 MM 交易记录，这些记录由键 id, date 标识。该文件由大型机每天生成。我需要历史地存储这些文件，并给定一个键 id, date 从这个数据库中检索它。我不知道我怎样才能更清楚。

您可能会从 Google 和 Facebook 所做的事情中获得一些灵感。检查他们的 Bigtable 和 Haystack 实现。不要忘记这种数据库还有其他实现（Hadoop、Cassandra、DynamoDB，还有很多我不记得的其他实现） .

【参考方案1】：

这是一个相当大的数据量，有很多潜在的解决方案。 HBase 应该是比 MySQL 更好的选择，因为 MySQL 会为事务保证和其他您可能不关心的事情增加很多开销。您可以在许多服务器上使用 MySQL 进行分片，但仍然存在不必要的额外开销。 HBase 支持可配置的分片，所以如果你按日期分片，它可以很好地工作。

如果您是 Java 开发人员，还有另一种可能的选择自己动手做。 MapDB (http://www.mapdb.org) 是一个开源的 Java 键值数据库，它有一些有趣的特性可以提供帮助。一个非常强大的功能是密钥压缩，这样密钥的日期部分可以存储一次，密钥的 ID 部分可以是特定日期内的实际唯一标识符。这将大大减少数据的大小，就像在任何传统数据库中一样，每一行的 Date 值都会为您的数据集复制 150MM 次。日期值占 8 个字节，这相当于每天浪费大量空间，并且会减慢查询速度。

MapDB 目前没有服务器实现，因此您需要将其包装在一个进程中，并且您可以在许多服务器上运行它。此解决方案显然比 HBase 工作量更大，但可以对其进行优化以实现非常好的性能。

围绕 MapDB 正在研究许多其他想法，这些想法将在未来提供，以使此类事情变得更容易。

总而言之，HBase 可能是执行此操作的简单方法，它应该可以很好地用于您的卷和查询。如果您想尝试让您更好地控制的低级方法，您可以考虑使用 MapDB。像 MySQL 这样的传统关系 DBMS 会增加很多您不需要的开销，并且需要设置分片，所以这不是一个很好的选择。