mysql - 存储和检索 547.500.000.000 条记录

Question

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

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

您认为这种架构可行吗？如果没有，解决问题的另一种方法是什么？欢迎提出建议和提示!

Answer 1

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

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

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

围绕 MapDB 正在研究许多其他想法，这些想法将在未来可用以简化此类操作。

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