LINUX.ORG.RU

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


0

1

Понятно, что «прямой доступ» в общем понимании и компрессор — это оксюморон.

Что хочется: есть поток данных со структурной единицей порядка 30 кбайт. Этот поток данных формирует файл размером, скажем, 10 Тбайт, который нужно пожать и в случае необходимости быстро доступиться к 20 миллионному событию.

Как это видится: в любом случае компрессоры жмут поблочно. Хотелось бы организовать файл из набора таких блоков где в каждом блоке определённое число структурных единиц (скажем 100). Для быстрого доступа необходимо естественно иметь индексный файл со смещением для каждого из таких блоков. Есть ли готовые решения на базе стандартных алгоритмов типа gzip, bzip2, lzo, xz?

★★★★★

Насколько я знаю, zip позволяет читать из архива произвольный файл, а также умеет дописывать новый файл в архив. Вот и дописывай файлы с удобными именами.

const86 ★★★★★
()

то что ты описал - это вообще стандартный zip/rar
там есть прямой доступ и компрессия по файлам - и директория
мож и неочень «круто» зато стандартно и доступ будет откуда угодно

про 10тб вот правдо неуверен :)

или просто файловая структура на 20 миллионов файлов - каждый файл это события заgzipпованное
зато куда устойчивее

ae1234 ★★
()
Ответ на: комментарий от r2d2

20 Пбайт данных на дисках 240 Пбайт на лентах. Запаришься такую систему со сжатием поддерживать.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от ae1234

У меня один файл, который будет поступать потоком через TCP/IP соединение, например, и жать его нужно на лету.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от ae1234

или просто файловая структура на 20 миллионов файлов - каждый файл это события заgzipпованное

зато куда устойчивее

+ Лишний оверхед из 20 миллионов заголовков.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

заголовки - мелочь
они всеравно есть - в любом из случаев
и работа с файловой системой - стандартнее не придумаеш

можно обьеденить эти 2 метода
загонять в zip по 10-1000 событий - и обьединять их какимто признаком

тогда будет 100-10000 zip файлов


ну поступает событие по tcp - ты его пишеш в файл - а потом командуеш зипу добавить его в тот то архив

ae1234 ★★
()
Ответ на: комментарий от Evgueni

можно zip заменить tar-ом - и загонять в него gz-пованные события
только (имхо) слишком много файлов в один tar загонять не стоит - он потоковый

ae1234 ★★
()
Ответ на: комментарий от ae1234

ну поступает событие по tcp - ты его пишеш в файл - а потом командуеш зипу добавить его в тот то архив

События могут поступать с частотой 300 кГц. Слишком накладно каждое событие добавлять в конец.

В принципе действительно можно в tar завернуть кучу файлов заархивированных скажем с помощью LZMA, но в любом случае придётся делать свою библиотеку для работы с индексами в целях быстрого доступа.

Evgueni ★★★★★
() автор топика

То, что ты описал, напоминает структуру обычного zip-архива. Но формат zip тебе без модификаций скорее всего не подойдет: смещение файла в «индексе» (central directory) там 32-битное.

Deleted
()
Ответ на: комментарий от ae1234

он потоковый

В первом приближении tar просто склеивает файлы. Если иметь индекс при условии конечно, что доступна команда seek можно доступаться быстро.

Evgueni ★★★★★
() автор топика

отвлечённо: есть форматы передачи, есть форматы и методы хранения/доступа. Если надо постоянно работать с полученными данными и делать какие-то выборки, получать ту или аналитику, то делается СУБД. А не какие то решения на базе «алгоритмов типа gzip, bzip2, lzo, xz» :) Кстати, на больших объёмах,в базе «структурная еденица порядка 30К» может занимать в разы меньше места, чем она-же пожатая например bzip`ом :)

конечно если надо только в случае внеочередного лунного затмения «доступиться к 20 миллионному событию» - то да, тогда тупо жать поток в файлы и строить самопальный внешний индекс.

MKuznetsov ★★★★★
()
Ответ на: комментарий от Evgueni

300кгц * 30кбайт = 9.216.000.000 байт в секунду 10гигабайт в секунду ? :) ssd диск записывает ну 250мегобайт в секунду ssd массив в виде платы - ну 1-2 гигабайта в секунду :)

задача весьма такая - непростая может точнее условия ?

ae1234 ★★
()
Ответ на: комментарий от Evgueni

да склеивает - но он делает это последовательно когда как в zip-ах (наверно) иль на файловой системе - это все в блоках и захещированно вусмерть

ae1234 ★★
()
Ответ на: комментарий от Deleted

формат zip тебе без модификаций скорее всего не подойдет: смещение файла в «индексе» (central directory) там 32-битное

ZIP64. Но я бы не стал так заморачиваться. Я бы сначала обдумал простые сжатые файлы по одной порции данных в каждом. Другой вариант: что-нибудь вроде berkeley db, если нужен какой-нибудь поиск сложнее, чем просто по порядковому номеру.

const86 ★★★★★
()
Ответ на: комментарий от MKuznetsov

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

ae1234 ★★
()
Ответ на: комментарий от ae1234

Диск очевидно будет не один. Запись будет параллелиться. 10 Гигабайт — это пиковая нагрузка.

Условия: в пике J/psi при ожидаемой светимости на Супер с-тау фабрике 10^35 см^{-2}сек^{-1} в случае энергетического разброса в центре масс 2.1 МэВ поток полезных событий будет составлять 250 кГц. Размер события примерно 30 кбайт. Их нужно сохранить все. Как-то так.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от ae1234

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

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

и чем же всеже ненравиться просто файловая система ?
даже миллионы файлов - будут просто храниться
копироваться с места на место такую кучу файлов - долго достаточно - это да

зато - обработка потом этих данных - очень простая - раздать эту базу машинам которые будут обрабатывать - тоже просто
включит веб сервер на директорию базы + включенный индекс и все
доступ через веб до файлов

ae1234 ★★
()
Ответ на: комментарий от Evgueni

а какой обьем записи ? нельзя ли просто завести в озу весь обьем - и после записывать ? сервера с 128-256 гиг памяти щас нередкость а это 10-20 секунд записи на фулл скорости

ae1234 ★★
()
Ответ на: комментарий от ae1234

В смысле объём записи? Физическая программа рассчитана на 10 лет. При максимальной нагрузке что-то около 3ёх месяцев.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от ae1234

С большим числом файлов таки морока. Для них нужно будет что-то вроде развесистой БД создавать.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

а какой вопрос такие и ответы

тоесть - будут поступать данные с пиковой скоростью в 10гигабайт в секунду - будут поступать по tcp и их нужно записывать

и общий обем хранилища должен быть примерно на 3 месяца записи пиковой скорости ?

(афигеть)

общий обьем 77 петабайт ? я правильно понимаю задачу ?

ae1234 ★★
()
Ответ на: комментарий от ae1234

Дисковое хранилище 4+12 Пбайт, ленточное 80+160 Пбайт. Это не так уж то и много. Такие объёмы достижимы уже с современной комплектацией.

Сами данные жмутся как минимум в двойку (bzip2).

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

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

изначально что имеем
1) единица информации 30 кбайт - сжимаемый в 15-20
2) таких блоков окончательно будет 2592000000000 = 2.6*10^12 блоков

и что хотим
1) записывать эксперимент на фулл скорости
2) хранить это все и не терять
3) както получаться доступ к этому - для обработки

ae1234 ★★
()
Ответ на: комментарий от ae1234

В идеальном случае сырые данные обрабатываются ровно один раз, а потом закапываются в ленточном хранилище.

Обработка будет выглядеть скорее так:

а) файл появляется на дисковом хранилище

б) процесс отвечающий за реконструкцию хватает его и начинает читать, распихивая скажем по 100 тысяч событий на счётный компьютер.

в) После того, как всё посчиталось, файл сырых данных перемещается в ленточное хранилище.

Для самого анализа объём данных гораздо меньше — примерно 1/50 от объёма сырых данных включая моделирование и калибровочную информацию. Но об этом отдельный разговор.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

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

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

а какой обьем «этапа эксперимента»
если в теченни 10 лет - обьем фулл скорости 3 месяца - то это примерно 30 минут в день - так ?
это примерно 22терабайт

ae1234 ★★
()
Ответ на: комментарий от Evgueni

я правильно понимаю - что скажем - раз в день - в течении 30 минут идет эксперемент - данные поступают на скорости 10гигобайт в секунду дальше - они в течении дня обрабатываються - и сырые данные скидываються в двойном экземпляре на ленту ?

ae1234 ★★
()
Ответ на: комментарий от ae1234

Основное время (97%) загрузка будет составлять не более 20-30 кГц. На полной загрузке только 3% С объёмами с учётом компрессии всё влезает в то помещение которое в случае появления финансирования будет модифицированно под хранилище.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от ae1234

Да. Проект предполагает, что при максимальной нагрузке всё должно обрабатываться фактически в реальном времени, включая моделирование.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

не совсем правдо всеравно ясны условия

в первой сообщение вы написали про файл скажем 10 терабайт - который состоит из закомпрессированных блоков по 30 кбайт то есть вы хотите на ленту скидывать такими обьемами ? и хотите решить - в каком виде лучше обьеденить записи в файл ? а изначально записи у вас поступают и храняться просто файлами на дисковом пространстве ?

ae1234 ★★
()
Ответ на: комментарий от ae1234

Размер файла скорее всего будет определяться размером ленты. То есть один файл — одна лента.

Традиционно файл захода — это набор данных набранных за промежуток времени типа несколько часов. Предполагается, что состояние детектора и ускорителя фатально не изменилось за это время. 10 Тбайт — это 2-4 часа набора вне пиков J/psi и psi(2S)

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

тут небольшая нестыковка - если компрессить на лету при записи на ленту то обьем будет может колебаться

а как у вас лента записывает ? раньше они вообще работали через tar - как запись так и чтение
а щас как ?

и еще вы упоминали про блоки «выкинуть повреждённый блок и заменить его блоком из второй копии»
это у вас лента так записывает - блоками ? и блоки можно добавлять удалять перезаписывать ?

ae1234 ★★
()
Ответ на: комментарий от ae1234

Идея такая: скармливаем библиотеке скажем по 1000 событий за раз до тех пора размер итогового файла не превысит какой-то предел. Как привысит — начинаем писать новый файл.

Как вариант: параллельно на разных процессорах компрессируем по тысячи событий за раз, а потом всё собираем в один большой файл до тех пор пока он ещё влезает на ленту. Параллельно индексируем этот файл. Индекс можно забросить в БД.

Ленты регулярно нужно проверять прочитывая что на них записано. Естественно перед записью необходимо посчитать что-нибудь вроде md5summ. Если контрольная сумма не совпадает, то должна запускать процедура восстановления, то есть файл копируется на диск, ищется копия, которая тоже вычитывается и затем они сравниваются. Если с копией всё O'k, то можно просто перезаписать попроченный файл на ленте, но что делать если в обоих копиях есть проблемы? В этом случае придётся сравнивать всё поблочно.

Шаткое какое-то основание. Надо будет ещё подумать.

Вот ещё зачем может потребоваться прямой доступ: не все события равны. Раз, скажем в 100 тысяч событий можно запускать процедуру калибровки детектора и писать отклик. Программа монитор может не интересоваться событиями обычными, но интересоваться только калибровочными.

Evgueni ★★★★★
() автор топика

HDF, ROOT. Я сделал свое на SQLite, просто список блобов. Про 10 терабайт не скажу, но пару десятков гигов работает. Терабайт не опечатка?

ebantrop
()
Ответ на: комментарий от ae1234

С тем роботом, который сейчас доступен, прокатывает стандартная связка mt+tar, ну и команда поставь такую-то кассету. Ничего больше и не надо.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

ну так смотри - выходит у тебя кассета - это один гигантский tar файл

и тебе нужно
1) записывать события
2) проверять неповредилась ли касета
3) считывать данные и обрабатывать их


1 - записывать события по отдельности наверно нестоит - значит обьединяем в блок и этот блок записываем в tar на ленте
2 - проверка это чтение всех записанных файлов-блоков с ленты - и проверка
и тут вопрос - если лента повредиться в начале - смогут ли быть считаные все данные за повреждением ? запись в таре то линейная - и если повредиться - врятли востановить
3 - чтоб считать - это надо прощерстить ленту таром на поиск нужного файла - считаь файл - потом из файла достать нужные события

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

получаеться схема - когда куча лент - каждая лента это tar файл c zip архивами - в архивах события
ну и названия файлов - ключи для доступа

ae1234 ★★
()
Ответ на: комментарий от ae1234

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

По всякому бывает. Именно поэтому необходимо как минимум две копии сырых данных.

3 - чтоб считать - это надо прощерстить ленту таром на поиск нужного файла - считаь файл - потом из файла достать нужные события

Ленту можно перемотать на нужное место с помощью mt. Естественно информацию о нужных местах нужно сохранять в БД.

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

rar не годится, так как это закрытый формат со всеми вытекающими. Средства проверки архива на повреждения есть у всех архиваторов. Проблема же zip в его низкой степени сжатия и в тормознутости для такой низкой степени сжатия.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Evgueni

зато рар умеет сжимать в несколько ядер

ну - чтоб не городить лишении сущности - собирайте события в tar
но у тара нету проверки целостности

ae1234 ★★
()
Ответ на: комментарий от ae1234

Зато формат закрытый, потоковой компрессии нет, да и степень, как и скорость давно не топовая, а всеми любимые GUI-интерфейс ну совсем не нужен. Надеяться на закрытые компоненты — это гарантировано разложить грабли. Примеров подобных фэйлов в экспериментальной науке масса.

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

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от ae1234

но у тара нету проверки целостности

md5summ — самая быстрая проверка целостности.

Evgueni ★★★★★
() автор топика
Ответ на: комментарий от Vit

Это не то. Там просто добавление функции компрессии к MySQL. На таких объёмах MySQL болеть начинает вплоть до смерти.

Evgueni ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.