如何存储1500万个32字节记录以便进行顺序访问？

Question

我有1500万个32字节的记录，需要进行顺序访问和追加操作。键是Long类型，值是元组- (Date, Double, Double)。在这个宇宙中有什么可以做到这一点的吗？我愿意为这1500万条记录中的每一个创建15个单独的数据库（sql / nosql）或文件。我的电脑配置为i7核心，8GB RAM和2TB硬盘。

我尝试过PostgreSQL、MySQL、Kyoto Cabinet（通过细微调整）与Protostuff编码。

SQL数据库（带索引）执行最简单的查询都要花费很长时间。

Kyoto Cabinet的B-Tree可以处理1500万至1800万条记录，超过这个数量后，追加操作会变得非常缓慢。

我已经厌倦了这些问题，正在考虑回到awk + CSV，我记得它曾经可以处理这种类型的数据。

- Edwin Jose Palathinkal

---

不确定是否只是我误解了，但我不太明白如果你说你只进行顺序访问的话，为什么还需要一个键呢？ - Joachim Isaksson

一个数据库应该比awk处理CSV文件更好...你的模式有问题。 - Corbin

在这种情况下，long的大小是多少？是32位还是64位？ - Joachim Isaksson

@JoachimIsaksson 这些键是用来处理重复的值，以及区分它们不同的。我可以将键放在值的内部，但我只是想表明它存在。我认为在SQL数据库中拥有主键，在NoSQL数据库中拥有键是一种良好的实践。 - Edwin Jose Palathinkal

@louzer 如果不是在寻找矛盾，如果密钥是32位并且实际用于查找，那么一个128GB的平面文件就可以通过seek(key*32); read(32 bytes);来解决你的问题。 - Joachim Isaksson

Answer 1

如果您的场景意味着始终按顺序遍历所有记录，那么使用数据库可能会过度。如果您开始需要随机查找、替换/删除记录或检查新记录是否不是旧记录的重复，则数据库引擎将更有意义。

对于顺序访问，一对文本文件或手工制作的二进制文件将更容易处理。您听起来像是一名开发人员 - 我可能会选择自己的二进制格式，并通过内存映射文件来访问它，以提高顺序读取/追加速度。没有缓存，只有一个滑动窗口来读取数据。我曾经进行过这样的数据分析，我认为它的性能比任何数据库都要好，甚至在通常的硬件上也是如此。它也比awk CSV文件更快；但是，首先我不确定它是否值得开发二进制存储的努力。

一旦数据库变得有趣，你可以看看MongoDB和CouchDB。它们用于存储和提供非常大量的数据。（有一个赞扬的评价将它们之一与传统数据库进行了比较。）通常需要合理的硬件性能才能更好地执行数据库操作；也许你可以检查一下这两个数据库在处理你的数据时的表现如何。

--- Ferda

- Ferdinand Prantl

Answer 2

对于顺序读写，leveldb 可以很好地处理您的数据集。

- user1184187

Answer 3

Ferdinand Prantl的回答非常好。两点：

• 根据您的要求，我建议您创建一个非常紧凑的二进制格式。这很容易做到，因为您的记录是固定大小的。
• 如果您了解您的数据，您可能能够压缩它。例如，如果您的键是递增的日志值，则不需要完全存储它。相反，存储与前一个值的差异（几乎总是为一）。然后，使用标准的压缩算法/库来大幅节省数据大小。

- usr

Answer 4

我觉得那个表大约有48吉字节的数据。

当你涉及到大型数据库时，你必须以不同的方式来看待问题。对于普通的数据库（比如说，表少于几百万行），你可以做任何概念验证。即使你对SQL数据库、服务器调优和硬件调优一无所知，你得出的答案可能也是正确的。（尽管有时候你可能因为错误的原因而得出正确的答案。）

但对于大型数据库来说，情况通常并非如此。

不幸的是，你不能仅仅将15亿行数据直接扔给一个未经调优的PostgreSQL服务器，运行几个查询，然后说：“PostgreSQL处理不了这个。”大多数SQL数据库管理系统都有处理大量数据的方法，而大多数人对此并不了解。

以下是我在长期处理大量数据时需要考虑的一些事项。（对于短期或一次性处理，速度通常不值得过多关注。很多公司甚至不会为长期解决方案投资更多的内存或十几块高速硬盘，甚至连几个固态硬盘都不会。）

• 服务器CPU。
• 服务器内存。
• 服务器硬盘。
• RAID配置。（对你来说，RAID 3可能值得一看。）
• 操作系统的选择。（64位 vs 32位，BSD v. AT&T衍生版本）
• 数据库管理系统的选择。（Oracle通常比PostgreSQL性能更好，但它需要付费。）
• 数据库管理系统的调优。（共享缓冲区、排序内存、缓存大小等。）
• 索引和聚集的选择。（现在有很多不同种类的。）
• 规范化。（你会惊讶地发现，5NF经常比较低的NF表现更好。自然键也是如此。）
• 表空间。（也许将索引放在独立的SSD上。）
• 分区。

我确定还有其他的，但我还没喝咖啡。

但重点是，除非你考虑了所有这些优化的影响，否则无法确定例如PostgreSQL是否能处理一个48GB的表。对于大型数据库，你要依赖于小改进的累积效果。在你能够有力地得出某个特定的数据库管理系统无法处理一个48GB的表的结论之前，你必须进行大量的测试。

现在，你能否实施这些优化是一个不同的问题 - 大多数公司不会投资于新的64位服务器运行Oracle和十几个最新的“我是最快的硬盘”硬盘来解决你的问题。

但是，有人将为了最佳的硬件和软件、dba调优专业知识或程序员的时间和等待而付费。我见过像这样的问题花费数月的时间来解决。如果需要花费数月的时间，那么在硬件上投资可能是明智的选择。

- Mike Sherrill 'Cat Recall'