我们正在评估我们将用于存储我们在分析C / C ++代码期间收集的数据的技术。在C ++的情况下，数据量可能相对较大，每TU约20Mb。
在阅读以下SO answer之后，我认为HDF5可能是我们使用的合适技术。我想知道这里的人是否可以帮我回答一些我提出的初步问题：
性能。数据的一般用法是一次写入并读“几次”，类似于编译器生成的'.o'文件的生命周期。 HDF5如何与使用像SQLite DB这样的东西进行比较？这甚至是一个合理的比较吗？
随着时间的推移，我们将添加我们正在存储的信息，但不一定要重新分发一组全新的“读者”以支持新格式。在阅读用户指南后，我了解到HDF5与XML或DB类似，因为信息与标签/列相关联，因此构建用于读取旧结构的工具只会忽略它不关心的字段？我对此的理解是否正确？
我们希望写出的一大部分信息将是树型结构：范围层次结构，类型层次结构等。理想情况下，我们会将范围建模为父母，孩子等。是否可以拥有一个HDF5对象“指向”另一个？如果没有，是否有使用HDF5解决此问题的标准技术？或者，根据数据库的要求，我们是否需要一个唯一的密钥，在搜索数据时，通过适当的查找将一个对象“链接”到另一个对象？
非常感谢！
答案 0 :(得分：23)
HDF5如何与使用像SQLite DB这样的东西进行比较？ 这甚至是一个合理的比较吗？
类似但不是真的。它们都是结构化文件。 SQLite具有使用SQL支持数据库查询的功能。 HDF5具有支持大型科学数据集的功能。
它们都意味着高性能。
随着时间的推移，我们将添加我们正在存储的信息，但不一定要重新分发一组全新的“读者”以支持新格式。
如果以结构化形式存储数据，这些结构的数据类型也存储在HDF5文件中。关于它是如何工作的我有点生疏（例如，如果它包含先天的向后兼容性），但我知道如果你正确地设计你的“阅读器”它应该能够处理将来改变的类型。
是否有可能让一个HDF5对象“指向”另一个？
绝对！您需要使用attributes。每个对象都有一个或多个字符串，用于描述到达该对象的路径。 HDF5 groups类似于文件夹/目录，除了文件夹/目录是分层的=唯一路径描述每个位置（在文件系统中至少没有硬链接），而组形成有向图，可以包括循环。我不确定您是否可以直接将对象的“指针”存储为属性，但您始终可以将绝对/相对路径存储为字符串属性。 （或者作为字符串的任何其他地方;如果你愿意的话，你可以拥有丰富的查找表。）
答案 1 :(得分：9)
我们在项目中生成HDF5数据，但我通常不会直接处理它。我可以抓住前两个问题：
我们使用一次写入，多次读取模型，格式似乎很好地处理了这个问题。我知道一个用于写入 Oracle 数据库和HDF5的项目。最终他们删除了Oracle输出，因为性能受到影响，没有人使用它。显然，SQLite不是Oracle，但HDF5格式更适合这项任务。基于这一个数据点，可以更好地调整RDBMS以进行多次插入和更新。
我们添加新数据类型时，客户使用的阅读器非常强大。预计会有一些变化，但我们不必担心在添加更多数据字段时会破坏它们。我们的DBA最近编写了一个Python程序来读取HDF5数据并填充KMZ文件以便在Google Earth中进行可视化。由于这是他用来学习Python的项目，我认为建立读者并不难。
关于第三个问题，我会向Jason S's superior knowledge屈服。
我认为HDF5是一个完全合理的选择，特别是如果你已经对它感兴趣或计划为科学界生产一些东西。