大数据的数据库选择

Question

我有很多文本文件,它们的总大小约为300GB~400GB.它们都是这种格式

key1 value_a
key1 value_b
key1 value_c
key2 value_d
key3 value_e
....

每一行由一个键和一个值组成.我想创建一个数据库,可以让我查询一个键的所有值.例如,当我查询key1时,返回value_a,value_b和value_c.

首先,将所有这些文件插入数据库是一个大问题.我尝试使用LOAD DATA INFILE语法将几个GB大小的块插入到MySQL MyISAM表中.但似乎MySQL不能利用多核来插入数据.它和地狱一样慢.所以,我认为MySQL对于这么多的记录来说不是一个好的选择.

此外,我需要定期,每周甚至每天更新或重新创建数据库,因此,插入速度对我来说很重要.

单个节点不可能有效地进行计算和插入,为了提高效率,我认为最好平行地在不同节点中执行插入.

例如,

node1 -> compute and store 0-99999.txt
node2 -> compute and store 10000-199999.txt
node3 -> compute and store 20000-299999.txt
....

所以,这是第一个标准.

标准1.以分布式批处理方式快速插入速度.

然后,正如您在文本文件示例中所看到的,最好为不同的值提供多个相同的键.就像key1映射到示例中的value_a/value_b/value_c一样.

标准2.允许多个密钥

然后,我将需要查询数据库中的键.不需要关系或复杂的连接查询,我只需要简单的键/值查询.重要的部分是同一个值的多个键

标准3.简单快速的键值查询.

我知道有HBase/Cassandra/MongoDB/Redis ....等等,但我不熟悉所有这些,不确定哪一个符合我的需求.所以,问题是 - 使用什么数据库？如果它们都不符合我的需求,我甚至计划建立自己的需求,但需要付出努力:/

谢谢.

Answer 1

可能有很多系统可以满足您的需求。您的要求通过以下几种方式使事情变得轻松愉快：

• 因为您不需要任何跨键操作，所以您可以使用多个数据库，通过哈希或范围分片在它们之间划分键。这是解决您在 MySQL 中观察到的以及在许多其他数据库系统中可能观察到的并行性缺乏的简单方法。
• 因为您从不进行任何在线更新，所以您可以批量构建一个不可变的数据库，然后在一天/一周的剩余时间内查询它。我希望通过这种方式你能获得更好的表现。

我倾向于构建一组哈希分片的LevelDB表。也就是说，我不会使用leveldb::DB支持更复杂的数据结构（一堆表和日志）的实际数据，以便您可以进行在线更新；相反，我会直接使用leveldb::Tableandleveldb::TableBuilder对象（没有日志，给定键只有一个表）。这是一种非常有效的查询格式。如果您的输入文件已经像示例中那样进行排序，则表构建也将非常高效。您可以通过增加分片数量来实现您想要的任何并行性 - 如果您使用 16 核、16 磁盘的机器来构建数据库，则至少使用 16 个分片，所有分片都是并行生成的。如果您使用 16 台 16 核、16 磁盘的机器，则至少有 256 个分片。如果您的磁盘比核心少得多，就像现在许多人所做的那样，请尝试两者，但您可能会发现更少的分片更好地避免寻道。如果你小心的话，我认为你基本上可以在构建表时最大化磁盘吞吐量，这说明了很多，因为我预计由于键前缀压缩（以及可选的 Snappy），表会明显小于你的输入文件块压缩）。您将基本上避免查找，因为除了通常可以在 RAM 中缓冲的相对较小的索引之外，leveldb 表中的键的存储顺序与您从输入文件中读取它们的顺序相同，再次假设您的输入文件已经是已排序。如果不是，您可能需要足够的分片，以便可以在 RAM 中对分片进行排序，然后将其写出，也许可以更顺序地处理分片。