大数据的数据库选择[关闭]答案

【问题标题】：Database choices for big data [closed]大数据的数据库选择[关闭]
【发布时间】：2012-04-18 23:22:42
【问题描述】：

我有很多文本文件，它们的总大小约为 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....等等，但我对它们都不熟悉，不确定哪一个适合我的需求。所以，问题是 - 使用什么数据库？如果它们都不符合我的需求，我什至打算建立自己的，但这需要努力：/

谢谢。

【问题讨论】：

不要自己构建。不管你有多好，你确定你和那些一直只做这件事的人一样好吗？有支持、有用户、有测试？
当然，我不如那些人。我也不想重建轮子。但如果没有轮子适合我的需要，我必须建造一个。 :S
不，对于像数据库存储引擎这样重要的东西，你总是稍微调整你的需求，或者处理一些怪癖会更好。谷歌并没有为他们的数据创建自己的存储系统，他们对 MySQL 做了一些修补。不要错误地认为您的问题是独一无二的。
这不是一个真正的编程问题。尝试在dba.stackexchange.com 上提问
圆柱形，我不同意。 Oracle 等可能非常复杂，但不可变的键/值数据库则不然。你不必害怕它。 Google 确实为他们的数据创建了自己的存储系统（Bigtable，其中一些内容变成了开源的 LevelDB；Spanner；以及许多其他），您可以使用 LevelDB 的一小部分来解决这个问题。那部分非常简单。您没有理由不能很好地理解所涉及的代码和数据结构。

标签： mysql database nosql distributed bigdata

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

我建议你使用 SSDB(https://github.com/ideawu/ssdb)，一个适合存储数据集合的 leveldb 服务器。

您可以将数据存储在地图中：

ssdb->hset(key1, value1)
ssdb->hset(key1, value2)
...

list = ssdb->hscan(key1, 1000);
// now list = [value1, value2, ...]

SSDB速度快（速度是Redis的一半，每秒30000次插入），它是leveldb的网络封装，单线安装启动。其客户包括 PHP、C++、Python、Java、Lua、...

【讨论】：

【解决方案3】：

如果您有大笔资金，传统的答案是使用 Oracle，如果您没有，则使用 PostgreSQL。但是，我建议您也看看像 mongoDb 这样的解决方案，我发现它非常快，并且还可以适应架构不固定并且可以随数据发生变化的情况。

【讨论】：

真的吗？ “我的 RDBMS 比你的快”的答案？花更多的钱并不会神奇地让这件事变得更快。
我的预算非常有限。我知道 MongoDB 很快，但我不知道它在 300GB ~ 400GB 规模下的表现如何。我知道它支持自动分片，但是在 MongoDB 中插入 300GB 记录怎么样？
绝对没有必要在软件上花钱，尤其是那些复杂到能满足你没有的需求的软件（ACID、复杂的 SQL 查询）。但是，您可以购买一些东西来让它变得更快：足够的 SSD 和/或 RAM 以避免撞到磁盘。现在，critical.com 上的 512 GB SSD 售价 611.79 美元，比我认为的最基本的 Oracle 许可证要便宜得多……

【解决方案4】：

由于您已经熟悉 MySQL，我建议您在迁移到新系统之前尝试所有 MySQL 选项。许多大数据系统针对非常具体的问题进行了调整，但在 RDBMS 认为理所当然的领域表现不佳。此外，大多数应用程序需要常规 RDBMS 功能以及大数据功能。因此，迁移到新系统可能会产生新问题。

还要考虑您选择的系统周围可用的软件生态系统、社区支持和知识库。

回到解决方案，数据库中有多少行？这是一个重要的指标。我假设超过 1 亿。

试试Partitioning。它可以帮助很多。您的选择标准很简单，而且您不需要连接，这一事实只会让事情变得更好。

Postgres 有一种处理分区的好方法。它需要更多的代码来启动和运行，但提供了惊人的控制。与 MySQL 不同，Postgres 对分区数量没有硬性限制。 Postgres 中的分区是常规表。这让您可以更好地控制索引、搜索、备份、恢复、并行数据访问等。

【讨论】：

【解决方案5】：

看看HBase。您可以使用列针对一个键存储多个值。与 RDBMS 不同，您不需要在每一行中具有固定的列集，但可以在一行中具有任意数量的列。由于您通过键（HBase 用语中的行键）查询数据，因此您可以通过读取该行中所有列的值来检索给定键的所有值。

HBase 也有保留期的概念，因此您可以决定哪些列可以存活多长时间。因此，数据可以根据需要自行清理。人们使用了一些有趣的技术来利用保留期。

HBase 具有很强的可扩展性，并且支持非常快速的读取和写入。

【讨论】：

【解决方案6】：

InfoBright 或许是个不错的选择。

【讨论】：