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