存储和检索 547.500.000.000 条记录答案

【问题标题】：Storing and retrieving 547.500.000.000 of records存储和检索 547.500.000.000 条记录
【发布时间】：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，还有很多我不记得的其他实现） .

标签： mysql hbase sharding large-data bigdata

【解决方案1】：

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

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

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

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

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

【讨论】：