我们正在评估用于存储在分析 C/C++ 代码期间收集的数据的技术。在 C++ 的情况下，数据量可能相对较大，每个 TU 约 20Mb。
看完下面的SO answer这让我想到了HDF5可能是适合我们使用的技术。我想知道这里的人是否可以帮助我回答我的一些初步问题:
表现。数据的一般用法是写入一次并读取“多次”，类似于编译器生成的“.o”文件的生命周期。 HDF5 与使用 SQLite DB 之类的东西相比如何？这甚至是一个合理的比较吗？
随着时间的推移，我们将添加我们正在存储的信息，但不一定要重新分发一组全新的“阅读器”以支持新格式。阅读用户指南后，我了解到 HDF5 类似于 XML 或 DB，因为信息与标签/列相关联，因此为读取旧结构而构建的工具只会忽略它不关心的字段？我对此的理解正确吗？
我们希望写出的大量信息将是树型结构:作用域层次结构、类型层次结构等。理想情况下，我们会将作用域建模为具有父项、子项等。是否有可能一个 HDF5 对象“指向”另一个？如果没有，是否有使用 HDF5 解决此问题的标准技术？或者，正如数据库中所要求的那样，我们是否需要一个唯一键，以便在搜索数据时通过适当的查找将一个对象“链接”到另一个对象？
非常感谢!
最佳答案
How does HDF5 compare against using something like an SQLite DB? Is that even a reasonable comparison to make?
有点像，但不是真的。它们都是结构化文件。 SQLite 具有支持使用 SQL 进行数据库查询的功能。 HDF5 具有支持大型科学数据集的功能。
它们都是高性能的。
Over time we will add to the information that we are storing, but will not necessarily want to re-distribute a completely new set of "readers" to support a new format.
如果您以结构化形式存储数据，那么这些结构的数据类型也会存储在 HDF5 文件中。我对它的工作原理有点生疏(例如，如果它包含固有的向后兼容性)，但我知道如果你正确地设计你的“阅读器”，它应该能够处理将来改变的类型。
Is it possible to have one HDF5 object "point" to another?
当然!你会想要使用 attributes .每个对象都有一个或多个字符串描述到达该对象的路径。 HDF5 groups类似于文件夹/目录，除了文件夹/目录是分层的=描述每个位置的唯一路径(至少在没有硬链接(hard link)的文件系统中)，而组形成一个可以包含循环的有向图。我不确定您是否可以将指向对象的“指针”直接存储为属性，但您始终可以将绝对/相对路径存储为字符串属性。 (或作为字符串的任何其他地方；如果需要，您可以拥有大量的查找表。)
关于database - 评估 HDF5 : What limitations/features does HDF5 provide for modelling data?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/547195/