HDF5可能的数据损坏或丢失？

Question

在维基百科上，人们可以看到以下关于HDF5的批评：

Criticism of HDF5 follows from its monolithic design and lengthy specification. Though a 150-page open standard, there is only a single C implementation of HDF5, meaning all bindings share its bugs and performance issues. Compounded with the lack of journaling, documented bugs in the current stable release are capable of corrupting entire HDF5 databases. Although 1.10-alpha adds journaling, it is backwards-incompatible with previous versions. HDF5 also does not support UTF-8 well, necessitating ASCII in most places. Furthermore even in the latest draft, array data can never be deleted.

我想知道这是仅仅适用于HDF5的C实现，还是HDF5的一个普遍缺陷？在

我在做科学实验，有时会产生千兆字节的数据，而且在所有情况下至少有几百兆字节的数据。显然，数据丢失，尤其是损坏对我来说是一个巨大的不利因素。在

我的脚本总是有一个PythonAPI，因此我使用的是h5py（版本2.5.0）。在

那么，这种批评是否与我有关，我是否应该关注损坏的数据？在

Answer 1

预先声明：我帮助维持h5py，所以我可能有偏见等等

自从这个问题被发布后，维基百科页面发生了变化，我看到的是：

Criticism

Criticism of HDF5 follows from its monolithic design and lengthy specification.

• Though a 150-page open standard, the only other C implementation of HDF5 is just a HDF5 reader.
• HDF5 does not enforce the use of UTF-8, so client applications may be expecting ASCII in most places.
• Dataset data cannot be freed in a file without generating a file copy using an external tool (h5repack).

我想说的是HDF5的问题，它很复杂（但人们需要这种复杂性，请看虚拟数据集的支持），它有很长的历史，它的重点是向后兼容，它的设计并不是为了允许文件的大规模更改。它在Windows上也不是最好的（因为它处理文件名的方式）。在

我之所以选择HDF5作为我的研究，是因为它提供了不错的元数据支持（HDF5至少允许UTF-8，FITS这样的格式甚至不支持UTF-8），支持多维数组（协议缓冲区之类的格式实际上不支持），而且它支持的不仅仅是64位浮点（这是非常罕见的）。在

我不能对已知的bug发表评论，但我已经看到了损坏（当我在写一个文件时，linux对我的脚本进行了修改）。但是，只要您有适当的数据卫生实践（如hackernews链接中所述），这不应该是一个问题，在您的情况下，这将是不连续地写入同一个文件，而是为每次运行创建一个新文件。您也不应该修改文件，相反，任何数据缩减都应该生成新文件，并且您应该始终备份原始文件。在

最后，值得指出的是，HDF5还有其他选择，具体取决于您的需求：SQL数据库可能更适合您的需要（sqlite默认附带Python，因此很容易进行实验），简单的csv文件也可以。我建议不要使用自定义/非可移植格式（例如pickle和类似格式），因为它们既不比HDF5更健壮，也比csv文件复杂。在