我有以下问题。我需要每天录制150毫米的唱片10年。记录总数150mm36510=5475000000条记录。数据库记录具有唯一键{date，id}。我需要每天用这个数据库恢复40mm的记录。我将始终使用键{date，id}进行搜索。该进程可以批量运行。我考虑过使用一个键值数据库，比如hbase，按日期分割数据库(不确定hbase是否允许您选择如何对集群中的记录进行分区。）。或者干脆把hbase切分留给我。
我看到一个使用mysql分区的类似问题高效存储7.300.000.000行）我不知道mysql是否可以在多台机器上分区。或者我可以用一台机器来处理这个问题。
你相信这种架构会奏效吗？如果没有，还有什么办法解决这个问题？欢迎提供建议和提示！
1条答案
按热度按时间9ceoxa921#
这是一个相当大的数据量，有许多潜在的解决方案。hbase应该是比mysql更好的选择，因为mysql将为事务保证和其他您可能不关心的事情增加大量开销。您可以在许多服务器上使用mysql进行切分，但仍然存在不必要的额外开销。hbase支持可配置切分，所以如果按日期切分，它可以很好地工作。
如果您是一名java开发人员，还有另一种可能的选择可以自己完成。Map数据库(http://www.mapdb.org)是一个开源的java键值数据库，它有一些有趣的特性可以提供帮助。一个非常强大的特性是密钥压缩，这样密钥的日期部分可以存储一次，并且密钥的id部分可以是特定日期内的实际唯一标识符。这将大大减少数据的大小，因为在任何传统的数据库中，每一行的日期值都将为数据集复制150毫米次。日期值为8字节，这是每天浪费的相当大的一块空间，会减慢查询速度。
mapdb目前没有服务器实现，因此需要将其打包到一个进程中，并且可以在许多服务器上运行。这个解决方案显然比hbase需要做更多的工作，但是可以对其进行优化，使其性能非常好。
在mapdb周围还有许多其他的想法，这些想法将在将来变得更容易。
总之，hbase很可能是实现这一点的简单方法，它应该可以很好地用于卷和查询。如果您想尝试使用低级别的方法来提供更好的控制，可以考虑mapdb。像mysql这样的传统关系型dbms会增加很多您不需要的开销，并且需要分片设置，所以这不是一个很好的选择。