В Линаксе в 2012 году зафиксировали стандарты хранения данных у "новой" файловой системы BtrFS. Одной из возможностей ФС является сжатие данных "на лету" при чтении / записи. Так как в своем проекте я уткнулся в скорость I/O, то решил попробовать эту возможность. На SSD диске это будет иметь двойную выгоду: сэкономит место + ускорит чтение данных. Мои текстовые файлы представляют из себя csv- файлы, с данными разделенными ';', а бинарные- последовательно записанные структуры данных с полями числовых типов.

Нет сжатия:
Исходный размер текстовых файлов: 37,2 ГБ
Скорость чтения текстовых файлов: 136 сек
Исходный размер двоичных данных: 6,8 ГБ

Сжатие zlib:
Размер текстовых файлов: 8,8 ГБ
Скорость чтения текстовых файлов: 99 сек
Размер двоичных данных: 3,2 ГБ

Сжатие lzo:
Размер текстовых файлов: 14 ГБ
Скорость чтения текстовых файлов: 74 сек
Размер двоичных данных: 4 ГБ

Сейчас уже появился новый метод сжатия ZSTD с возможностью установки числового коэффициента сжатия. Я его пока не тестировал, но думаю, что с его помощью можно добиться еще большей скорости чтения данных. Но даже сейчас видно, что размер на диске сокращается примерно в 2,5 раза, а скорость чтения возрастает примерно в 2 раза.

Так что у кого будет подобный кейс, можете также попробовать возможности файловых систем из Линакса.

Забыл написать, что у меня 4-ех ядерный процессор i5-4690 (без гипертрейдинга), поэтому чтение данных с диска во всех трех экспериментах выполнялось 4- мя параллельными потоками (а главный 5-ый поток ждал их завершения). Другими словами, не было свободного ядра, которое могло использоваться для автоматического разжатия данных "на лету".

+ Текстовые файлы имеют большой размер (примерно по 300 Мбайт каждый), поэтому полученное ускорение нельзя отнести к более хорошей работе с файлами маленького размера. Ускорение получилось именно за счет сжатия файлов на диске.

maytonДля этого не обязательно форматировать устройство под btrfs. Библиотека zlib портирована на все языки и ты мог читать текстовые файлы не доставая их из архива.

Зачем делать то, что ОС делает за меня?

miksoftAlekseySQLСкорость чтения текстовых файлов: 74 сек
Размер двоичных данных: 4 ГБ54 МБ/с ? Вы уверены, что это SSD, а не HDD 20-летней давности?

Проверялась скорость чтения ТЕКСТОВЫХ данных, их размер значительно больше.

miksoftAlekseySQLпропущено...
Проверялась скорость чтения ТЕКСТОВЫХ данных, их размер значительно больше.Тогда что означают эти 4 ГБ ?

Размер бинарных данных приведен только для оценки степени их сжатия: не сжатые они занимают 6,8 ГБайт, а для разных способов сжатия- 3,2 и 4 Гбайт.

Кстати, если по чесноку, то у меня не чистое чтение тексовых файлов: прочитанные строки парсились, а значения преобразовывались в числовые форматы. Структуры с полученными числовыми данными складывались в мой массив. Так что есть небольшой оверхед при операциях чтения текстовых данных. Поэтому при 2,5- кратном уменьшении размера данных, получить 2-ух кратное увеличение скорости можно, если операция разархивирования практически не занимала процессорного времени. Т.е. можно попробовать еще поднять степерь сжатия, получив прирост производительности чтения.

Но это я уже буду тестить только на бинарных данных: мне важна скорость именно их чтения.

rdb_devЕсть еще более клёвая штука - ZFS
Для понимания:
Руководство по администрированию файловых систем ZFS Solaris

Да, выбирая из сжимающий ФС читал и про ZFS, но народ пишет, что для нее надо много оперативки. К тому же поддержка ZFS в Ubuntu появилась только в версии 16.04, т.е. решению всего два года, и у меня нет времени работать бета- тестером.

Siemargl "Линакс" клево звучит. Почти как "Тампакс".

Действительно, шутка затянулась. Теперь буду писать Linux.

Кстати, когда я приводил показатели сжатия lzo и zlib для бинарных файлов, то подразумевал те файлы, которые уже предварительно сжаты моим алгоритмом на повторяющиеся значения. Другими словами, использовалось двойное сжатие: сначала моим алгоритмом, а потом с помощью ФС. Сегодня поставил эксперимент по сжатию с помощью lzo структур, которые не проходили предварительной обработки моим алгоритмом сжатия и получил более хорошие показатели сжатия lzo:

Нет сжатия:
Исходный размер НЕсжатых двоичных данных: 16,3 ГБ
Исходный размер сжатых двоичных данных: 6,8 ГБ

Сжатие lzo:
Размер НЕсжатых двоичных данных: 6 ГБ
Размер НЕсжатых двоичных данных: 4 ГБ

Видно, что применение моего алгоритма сжатия пока оправдано: итоговый размер файлов становится меньше в полтора раза:
К = 6 / 4 = 1,5

Но если учесть дополнительное время необходимое на "разжатие" моим алгоритмом, то возможно все плюсы сойдут на нет. Другими словами, возможно применение возможностей ФС уберет из моего кода лишние алгоритмы без потери скорости чтения бинарных данных.

maytonДля этого не обязательно форматировать устройство под btrfs. Библиотека zlib портирована на все языки и ты мог читать текстовые файлы не доставая их из архива.

Я, кстати, обдумывал вопрос использовать zip- архивирование "на лету". Но, к сожалению, в Qt нет работы с zip- архивами, поэтому решение получается не кросплатформенное. При использовании btrfs оно конечно тоже не кроссплатформенное, но получается "на халяву", поэтому "карман не тянет".