Фрагментирование HDF5 без сжатия приводит к увеличению размера файла

У меня есть несжатый файл HDF5 размером 460 МБ. Я использую h5repack для сохранения файла со сжатыми фрагментами, например:

h5repack -v -l CHUNK=128x128x1 -f GZIP=1 file.h5 file_chunked.h5

Это прекрасно работает, и размер полученного файла составляет около 1/3 от исходного (170 МБ).

Однако, если я попытаюсь использовать разбиение на фрагменты без сжатия, как это

h5repack -v -l CHUNK=128x128x1 -f NONE file.h5 file_chunked.h5

или даже

h5repack -v -l CHUNK=128x128x1 file.h5 file_chunked.h5

то размер полученного файла значительно больше (в 10 раз) исходного (3,9 ГБ).

Размеры, типы данных и содержимое результирующих наборов данных кажутся одинаковыми. Когда я просматриваю файл в HDFView, я не вижу никакой разницы с исходным, за исключением того, что Chunking установлен на 128x128x1.

Я ожидаю, что фрагментированный, но несжатый файл будет примерно того же размера, что и оригинал.

Может кто-то объяснить это мне? Я, вероятно, упускаю здесь что-то фундаментальное.

Огромное спасибо!


compression hdf5 chunking
person Felizett    schedule 17.03.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Каждый фрагмент несет некоторые накладные расходы. Внутри они являются узлами B-дерева. Эти накладные расходы умножаются на количество фрагментов. Если у вас есть относительно небольшие куски, у вас их будет много. Без сжатия эти накладные расходы могут быть огромными.

На странице о вещах, которые могут повлиять на производительность, говорится:

Избегайте использования очень маленького размера фрагмента. При небольшом размере фрагмента может быть много накладных расходов, что может повлиять на производительность, а также сделать файл намного больше.

person Simon    schedule 18.03.2016
comment
Спасибо, Саймон, я читал эти инструкции раньше и был уверен, что выбрал разумный размер фрагмента для своих наборов данных. Они довольно велики по x и y (5000) и очень малы по z (15). Но теперь я узнал, что я перепутал порядок измерений. Он должен быть 1x128x128 (сначала z) вместо 128x128x1, что, очевидно, имеет огромное значение. - person Felizett; 18.03.2016
comment
Большой! Я был удивлен суммой накладных расходов. Это прекрасно объясняет! - person Simon; 18.03.2016