database - 大型天体物理学模拟数据的数据存储

Question

我是天体物理学的研究生。我使用主要由其他人在十年左右的时间里开发的代码运行大型模拟。有关这些代码的示例，您可以查看小工具 http://www.mpa-garching.mpg.de/gadget/和恩佐 http://code.google.com/p/enzo/ .这绝对是两个最成熟的代码(他们使用不同的方法)。

这些模拟的输出巨大。根据您的代码，您的数据会有所不同，但它始终是大数据。你通常需要数十亿个粒子和细胞来做任何现实的事情。最大的运行是每个快照数 TB 和每个模拟数百个快照。

目前看来读写这类数据最好的方式就是使用HDF5 http://www.hdfgroup.org/HDF5/ ，这基本上是一种使用二进制文件的有组织的方式。与具有自定义 header block 的未格式化二进制文件相比，这是一个巨大的改进(仍然让我做噩梦)，但我忍不住认为可能有更好的方法来做到这一点。

我认为纯粹的数据大小是这里的问题，但是是否存在某种可以有效处理 TB 二进制数据的数据存储，或者二进制文件目前是唯一的方法吗？

如果有帮助，我们通常按列存储数据。也就是说，您有一个包含所有粒子 ID 的 block 、包含所有粒子位置的 block 、包含粒子速度的 block 等。它不是最漂亮的，但它是执行某些体积中的粒子查找等操作时最快的。

编辑:很抱歉对这些问题含糊不清。史蒂夫是对的，这可能只是数据结构的问题，而不是数据存储方法的问题。我现在必须运行，但我会在今晚或明天晚些时候提供更多详细信息。

编辑 2: 因此，我对此研究得越多，就越意识到这可能不再是数据存储问题。未格式化二进制文件的主要问题是所有令人头疼的正确读取数据(正确获取 block 大小和顺序并确定)。 HDF5 几乎解决了这个问题，并且在改进文件系统限制之前不会有更快的选择(感谢 Matt Turk)。

新问题可能归结为数据结构。 HDF5 是我们所能达到的最高性能，即使它不是最好的查询接口(interface)。习惯于数据库，我认为能够查询诸如“随时给我速度超过 x 的所有粒子”之类的东西真的很有趣/功能强大。你现在可以做类似的事情，但你必须在较低的层次上工作。当然，考虑到数据有多大并且取决于您使用它做什么，为了性能起见在低级别工作可能是一件好事。

Answer 1

• MongoDB:http://www.mongodb.org/
• Netezza产品: http://www.netezza.com/data-warehouse-appliance-products/skimmer.aspx
• Hadoop:http://hadoop.apache.org/
• 维基百科的分布式文件列表系统: http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

---

编辑

我缺乏解释/等的理由:

• OP 说:“[HDF5] 使用自定义 header block 对未格式化的二进制文件进行了巨大改进(仍然让我做噩梦)，但我忍不住认为可能有更好的方法来做到这一点。”

“更好”是什么意思？结构更好？他似乎暗示“未格式化的二进制文件”是一个问题——所以也许这就是他所说的更好的意思。如果是这样，他将需要具有某种结构的东西——因此是第一对建议。

• OP 说:“我想绝对的数据大小是这里的问题，但是是否有某种数据存储可以有效地处理 TB 的二进制数据，或者二进制文件是目前唯一的方法吗？”

是的，有几个。结构化和“非结构化”——他想要结构化，还是他乐意以某种“未格式化的二进制格式”留下它们？我们仍然不知道 - 所以我建议检查一些分布式文件系统。

• OP 说:“如果有帮助，我们通常按列存储数据。也就是说，你有一个包含所有粒子 ID 的 block 、包含所有粒子位置的 block 、包含粒子速度的 block ，等等。它不是最漂亮的，但它是在某些体积中进行诸如粒子查找之类的事情是最快的。”

同样，OP 想要更好的结构，还是他不想？似乎他两者都想要——更好的结构和更快的……也许横向扩展会给他这个。这进一步强化了我列出的前几个选项。

• OP 说(在评论中):“我不知道我们是否可以在 io 上受到打击。”

有IO要求吗？成本限制？这些是什么？

我们不能不劳而获。没有“银弹”存储解决方案。我们在这里所要做的只是“大量数据”和“我不知道我是否喜欢缺乏结构，但我不愿意增加我的 IO 以适应任何额外的结构”……所以我不知道他期待什么样的答案。除了缺乏结构之外，他没有列出任何关于他当前拥有的解决方案的提示 - 他已经说过他不愿意支付任何管理费用来做任何事情......所以......？