在维基百科上，人们可以阅读以下关于 HDF5 的批评：
对 HDF5 的批评源于其单一的设计和冗长的规范。虽然是一个 150 页的开放标准，但 HDF5 只有一个 C 实现，这意味着所有绑定都共享其错误和性能问题。再加上缺乏日志，当前稳定版本中记录 的错误能够破坏整个 HDF5 数据库。尽管 1.10-alpha 添加了日志，但它与以前的版本向后不兼容。HDF5 也不能很好地支持 UTF-8，在大多数地方都需要 ASCII。此外，即使在最新的草案中，数组数据也永远无法删除。
我想知道这是否仅适用于 HDF5 的 C 实现，或者这是否是 HDF5 的一般缺陷？
我正在做科学实验，有时会产生千兆字节的数据，在所有情况下至少会产生数百兆字节的数据。显然，数据丢失，尤其是损坏对我来说是一个巨大的劣势。
我的脚本总是有一个Python API，因此我正在使用h5py（版本 2.5.0）。
那么，这种批评与我有关吗？我应该担心数据损坏吗？
预先声明：我帮助维护 h5py，所以我可能有偏见等。
自问题发布以来，维基百科页面发生了变化，这就是我所看到的：
批评
对 HDF5 的批评源于其单一的设计和冗长的规范。
- 虽然是一个 150 页的开放标准，但 HDF5 的唯一其他 C 实现只是一个 HDF5 阅读器。
- HDF5 不强制使用 UTF-8，因此客户端应用程序在大多数地方可能需要 ASCII。
- 如果不使用外部工具 (h5repack) 生成文件副本，则无法在文件中释放数据集数据。
我想说这几乎总结了 HDF5 的问题，它很复杂（但人们需要这种复杂性，请参阅虚拟数据集支持），它有很长的历史，因为它的重点是向后兼容，而且它的设计并不是为了允许文件的巨大变化。它在 Windows 上也不是最好的（由于它处理文件名的方式）。
我选择 HDF5 进行研究是因为可用的选项，它有不错的元数据支持（HDF5 至少允许 UTF-8，像 FITS 这样的格式甚至没有），支持多维数组（像协议缓冲区这样的格式没有真的支持），而且它支持的不仅仅是 64 位浮点数（这是非常罕见的）。
我无法评论已知的错误，但我看到了损坏（这发生在我写入文件并且 linux OOM'd 我的脚本时）。但是，只要您有适当的数据卫生实践（如hackernews 链接中所述），这不应该是一个问题，在您的情况下，这将不是连续写入同一个文件，而是为每次运行创建一个新文件. 您也不应该修改文件，任何数据缩减都应该生成新文件，并且您应该始终备份原始文件。
最后，值得指出的是 HDF5 的替代品，具体取决于您的具体要求：SQL 数据库可能更适合您的需求（sqlite 默认带有 Python，因此很容易试验），简单的 csv 也可以文件。我建议不要使用自定义/非便携式格式（例如 pickle 和类似格式），因为它们既不比 HDF5 更健壮，也比 csv 文件更复杂。