我有以下问题。我需要每天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是否可以在多台机器上进行分区。或者，如果我只能使用一台机器来处理这个问题。
你相信这个架构会起作用吗？ 如果没有，那么解决问题的另一种方法是什么？ 欢迎提出建议和提示！
答案 0 :(得分：2)
这是一个相当大量的数据，并且有许多潜在的解决方案。 HBase应该是比MySQL更好的选择，因为MySQL会为事务保证和其他你可能不关心的事情增加很多开销。您可以在许多服务器上使用MySQL进行分片，但仍然存在额外的开销，这是不必要的。 HBase支持可配置的分片，因此如果你按日期分片，它可以很好地工作。
如果您是Java开发人员，还有另一种可能的选择。 MapDB（http://www.mapdb.org）是一个开源的Java键值数据库，它有一些有用的功能可以提供帮助。一个非常强大的功能是密钥压缩，这样密钥的日期部分可以存储一次，密钥的ID部分可以是特定日期内的实际唯一标识符。这将大大减少数据的大小，因为在任何传统数据库中，每行都会为您的数据集复制150MM次的Date值。日期值为8个字节，这是每天浪费的一大块空间，可能会减慢查询速度。
MapDB目前没有服务器实现，因此您需要将其包装在一个进程中，并且可以在许多服务器上运行它。这个解决方案显然比HBase更有效，但它可以进行优化以便很好地运行。
围绕MapDB还有许多其他想法可以在将来使用，以便更容易做到这一点。
总之，HBase可能是执行此操作的简单方法，它应该适用于您的卷和查询。如果您想尝试一种可以提供更好控制的低级方法，可以考虑使用MapDB。像MySQL这样的传统关系型DBMS会增加你不需要的大量开销，并且需要进行分片设置，所以这不是很合适。