Нужен компрессор делающий файлы с возможностью «прямого доступа»

В 2 раза.

Возможно, я совсем неверно оцениваю ситуацию и не умею считать деньги. С моей точки зрения, ради выигрыша в 2 раза не стоит мудрить с упаковкой вообще.

Или можно попробовать переформулировать проблему. Можно поменять ваши задачи местами? Сначала жать каждый замер, а потом думать в какое key-value положить. Или от такой перестановки степень сжатия сильно упадет?

Когда счёт идёт на 250 Пбайт, то в два раза — это дополнительные 250 Пбайт. Ограничение на самом деле чисто физическое: размеры помещения.

И все-таки, если жать каждый срез отдельно, это будет сильно хуже по суммарному размеру, чем затолкать их в 1 архив несколько тысяч?

В любом случае компрессоры (те же bzip2 и gzip) жмут блоками размером по 1 Мб, так что нужно просто модифицировать немного компрессоры, чтобы жали указанные объёмы в отдельный блок и сохраняли информацию о расположении этих блоков в файле.

любом случае компрессоры (те же bzip2 и gzip) жмут блоками размером по 1 Мб,

man bzip2 говорит, что можно настраивать от 100k до 900k

Заговариваюсь уже спросонья. Порядка 1 Мб. По умолчанию у bzip2 900k

dd+bzip2 не?

жать блоки и отправлять их на запись в файл. А привычитке просто с помощью dd нужный блок выгребать.

Не совсем понял последнего посыла. Вроде в моей убунточке файлы <100к вполне себе жмутся. Без всяких модификаций.

В любом случае надо написать библиотеку ч помощью которой этот файл пишется/читается.

900k — это максимальный размер блока. Увеличение блока ведёт к снижению скорости. Если объём данных меньше, то он естественно меньше.

Давайте побьем задачу на части.

Вы себя заранее загнали в рамки «нужны мегазипы, в распеределенной файловой системе». Тогда как реально вам может хватить распределенного key-value. Это заметно проще.

Я и побил на части:

а) Файлы заходов — традиционный способ организации сырых данных. Альтернативой такому подходу база данных — SciDB.

б) нужно как-то эти файлы заходов распихать по дисковому хранилищу отсюда один из вариантов организации: распределённая файловая система.

в) Размер файла критичен и в смысле итогового объёма и в смысле передачи данных — потому поток данных нужно жать. Хочется кроме собственно компрессии и аналог прямого доступа — то есть жать нужно структурные единицы.

Можно сделать таким образом: каждый блок отдельно зипуется гзипом (zlib), блоки последовательно укладываются в файл. Между блоками внутри файла пишутся размеры блоков (инт 64) и например 2-3 отступа для организации дерева блоков внутри файла, чтобы по индексу быстро попадать в нужный блок.

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

Да что сделать примерно понятно :) Интересно было бы наличие готового к употреблению решения, чтоб не делать.

всеже думаю zip был бы лучшим

по скорости - попробовал зазипить и gzip-мнуть рандомный файл
исходные файл 29097K из urandom-а
zip: 1.264сек - 29102K
gzip: 1.260сек - 29101K

более сжимаемый файлик
zip: 4.960сек 34250K
gzip: 4.588сек 34250K

а насчет того что суммы можно хранить отдельно - можно то можно - а зачем - когда они в архив и так встроены

наличие готового к употреблению решения, чтоб не делать

Это всегда хорошо, ничего не делать и чтоб было сделано. По мне это самое лучшее что можно сделать:)

Может гугловая leveldb или Kyoto cabinet подойдут под структуру хранения? Жать можно руками перед запихиванием в базу. Думаю на такой объем что-нибудь более скорострельное лучше будет типа snappy, LZO.

суть в том что у него и нету никакой структуры хранения зато есть куча ленточек - в которые нужно уложить гиганскую кучку 30кбайтных обьектов

кстати - если ты так опасаешся за обьем
то сделай не двойное резервирование - а полуторное
скажем машина с 3мя лентами
на первые 2 ленты пишуться блоки 1вый и второй блок - а на третью ленту пишеться xor сумма этих двух блоков
и в результате у тебя будет система их 3 лент - на двух данные - на 3тей средство для востановления потерь

все украдено до нас :)

http://www.hdfgroup.org/doc_resource/SZIP/

в тот же формат можно пихать и процентов 10 на коды восстановления, что бы порадовать научных археологов лет через 15 :)

http://www.hdfgroup.org/HDF5/Tutor/compress.html

о оно даже и так дефлате и чанки умеет

единственный минус, нашел вот такую дискуссию. (правда не очень уверен что так все просто)

There was some discussion whether HDF5 would also be suitable for data storage on tape. Data stored in HDF5 can be archived on tape, but partial read/write access requires that the HDF5 file is on disk.

Но по моему, если уж мотать ленту то полностью. Иначе по моему ей кирдык придет быстрее.

Эти же ребята пишут что куча форматов сейсмологов в 70е были ориентированы на ленточки и организованы так как указано в топике, наверное надо искать эти реализации

Забавно, можно организовать файловую на ленте

http://en.wikipedia.org/wiki/Linear_Tape_File_System

Спасибо. Это похоже на решение. Мне уже кивали в сторону HDF5, но я как-то не осознал его возможности.

В идеале ленты нужно проматывать исключительно только для того, чтобы рассчитать md5summ на предмет проверки консистентности. А в случае модификации в любом случае файлы нужно скидывать на диск.

С большим числом файлов таки морока

Почему? Я проводил тесты, 100 000 файлов в одной директории на ext3/ext4/reiserfs создавались за 5.0/7.0/3.8 сек. На обычном компьютере. Думаю, и с миллионами проблем не будет. ФС и есть бд.

Разговор шёл не про миллион, а как минимум про десятки миллиардов, а максимум про десятки тысяч миллиардов.

ae1234

из всего этого - имхо лучше и нету zip-а/rar-а - у них есть средства проверки архива на повреждения

ЕМНИП в tar тоже есть CRC32 для каждого файла. И в bzip2 для каждого блока.

и какой коммандой проверить tar файлик ?

компрессор делающий файлы с возможностью «прямого доступа»

xz же.

ae1234

и какой коммандой проверить tar файлик ?

tar --test очевидно. Вот только я попробовал - и что-то не работает :(

надо как-то star видимо юзать. http://freecode.com/projects/star

хотя и обычный gnu-tar должен понимать star архивы. Но делать видимо не обязан.

/* J@"org Schilling star header */

struct star_header
{                               /* byte offset */
  char name[100];               /*   0 */
  char mode[8];                 /* 100 */
  char uid[8];                  /* 108 */
  char gid[8];                  /* 116 */
  char size[12];                /* 124 */
  char mtime[12];               /* 136 */
  char chksum[8];               /* 148 */
  char typeflag;                /* 156 */
  char linkname[100];           /* 157 */
  char magic[6];                /* 257 */
  char version[2];              /* 263 */
  char uname[32];               /* 265 */
  char gname[32];               /* 297 */
  char devmajor[8];             /* 329 */
  char devminor[8];             /* 337 */
  char prefix[131];             /* 345 */
  char atime[12];               /* 476 */
  char ctime[12];               /* 488 */
                                /* 500 */
};

DonkeyHot

xz же.

xz он потоковый. С самого начала надо распаковывать. С середины не получится. И xz это не архиватор.

xz он потоковый. С самого начала надо распаковывать

см. xz/format.html

И xz это не архиватор

см subj.

Почитал xz/format.html. Выглядит действительно по теме, хотя в любом случае придётся дорабатывать.

А если просто сохранять в виде файлов в файловой системе со включеным сжатием вроде Reiser4 или btrfs?

а) слишком большие объёмы

б) слишком низкий коэффициент сжатия

в) На лентах reiser4 или btrfs не поставишь

а) слишком большие объёмы

То есть для tar-a не большие а для файловой системы большие? В чём заключаются ограничения?

б) слишком низкий коэффициент сжатия

Там же тот же самый алгоритм что и в zlib. Зачем ещё сильнее жать?

в) На лентах reiser4 или btrfs не поставишь

Я говорил только про хранилище на дисках. Хотя кто мешает потом бекапить данные с FS на ленты стандартными средствами.

P.S. Главная фишка такого решения - не нужно изобретать ни одного велосипеда который заглючит в самый неподходящий момент, а можно использовать более-менее проверенные решения с прогнозируемыми рисками.