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

Question

我是天体物理学专业的研究生。我使用大部分由其他人开发的代码运行大型模拟十多年。有关这些代码的示例，您可以查看小工具http://www.mpa-garching.mpg.de/gadget/ 和 enzo http://code.google.com/p/enzo/。这绝对是最成熟的两个代码（它们使用不同的方法）。

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

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

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

如果有帮助，我们通常按列存储数据。也就是说，你有一个所有粒子 id 的块、所有粒子位置的块、粒子速度块等。它不是最漂亮的，但它是在某些体积中执行诸如粒子查找之类的最快的。

编辑：抱歉对这些问题含糊其辞。史蒂夫是对的，这可能只是数据结构而不是数据存储方法的问题。我现在必须跑步，但我会在今晚或明天提供更多细节。

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

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

Answer 1

• MongoDB：http://www.mongodb.org/
• 内特扎 产品： 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] 是对带有自定义标头块的未格式化二进制文件的巨大改进（仍然让我做噩梦），但我不禁认为可能有更好的方法来做到这一点。”

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

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

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

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

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

• OP 说（在 cmets 中）：“我不知道我们是否可以在 io 上受到打击。”

有 IO 要求吗？费用限制？这些是什么？

我们不能在这里无所事事。没有“银弹”存储解决方案。对于需求，我们在这里所要做的就是“大量数据”和“我不知道我是否喜欢缺乏结构，但我不愿意增加我的 IO 以适应任何额外的结构”......所以我不知道他在期待什么样的答案。除了缺乏结构外，他没有对他目前的解决方案提出任何抱怨 - 他已经说过他不愿意为此付出任何开销......所以......？