dan*_*451 6 python hdf5 python-2.7 h5py hdf
在维基百科上,人们可以阅读以下关于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 这样的格式甚至没有），支持多维数组（像 Protocol Buffers 这样的格式没有真的支持），而且它支持的不仅仅是 64 位浮点数（这是非常罕见的）。
我无法评论已知的错误，但我看到了损坏（这发生在我写入文件并且 linux OOM 我的脚本时）。但是，只要您有适当的数据卫生习惯（如hackernews 链接中所述），这就不应该成为问题，在您的情况下，这不是连续写入同一个文件，而是每次运行创建一个新文件. 您也不应该修改文件，任何数据缩减都应该生成新文件，并且您应该始终备份原始文件。
最后，值得指出的是，有 HDF5 的替代方案，具体取决于您的需求：SQL 数据库可能更适合您的需求（默认情况下，sqlite 附带 Python，因此很容易进行试验），一个简单的 csv 也是如此文件。我建议不要使用自定义/非便携式格式（例如pickle 和类似格式），因为它们既不比 HDF5 更强大，也比 csv 文件更复杂。