Какая библиотека архивации для Python даёт произвольный доступ к файлу в архиве?

У меня есть большие архивы, в них текстовые файлы весом в несколько гигабайт. Необходимо получать доступ к произвольной точке в этом файле. (.seek).
Сейчас я использую для этого библиотеку zipfile и она работает достаточно медлено - чем дальше к концу файла нужно перейти, тем больше времени требуется, вплоть до десятков секунд. Но библиотек много - zlib, gzip,lzma,shutil,bz2,tarfile и.т.п.
Вы не знаете, какая из них даёт доступ к любому месту файла в архиве за линейное время, как и аналогичная функция seek для текстовых файлов? Очень нужно и дробить файлы на тысячи кусков не хочется. Заранее спасибо.

0

Сообщение от Testfor работает достаточно медленно

Если нужна скорость, то вообще питон не лучший вариант для ваших целей

0

Testfor, tar, без сжатия, возможно, поможет. А так, любые архивы с компрессией придется расжимать, на что будет тратится время.

0

Сообщение от Testfor какая из них даёт доступ к любому месту файла в архиве за линейное время, как и аналогичная функция seek для текстовых файлов?

- думаю, что задача решения не имеет.

0

u235, rim41, Catstail,

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

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

0

Сообщение от Testfor Может знаете, какой из алгоритмов сжимает данные блоками?

- Вам придется реализовать это самостоятельно... И возникает вопрос: а что Вы хотите достичь? Хранить библиотеки в сжатом виде? Зачем?

2

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

Сообщение от Testfor сжимающий данные по блокам и индексирующий начало каждого блока

и как это будет работать по вашему? эти "куски" будут сжаты по разному, с разной степенью, ну найдем мы быстро нужный, но его же нужно тоже декомпрессить, а также декомпрессить и последующие если собираемся читать далее, причем на лету, что отнимет время. Кроме того это существенно ухудшит сжатие, ибо один условный кусок в файле не будет содержать столько повторяющихся (сжимаемых) последовательностей как файл целиком, какие то вообще не сожмутся, но были бы сильно сжаты при обычном подходе. Плюсом надо будет хранить мета-информацию о том на сколько блоков вы разбили исходный файл и мета-информацию для каждого куска (так как это по сути отдельные архивы).

2

Сообщение от Testfor По сути это и будет разбивание одного файла на множество маленьких и их независимое сжатие.

В пределе вы прийдете к множеству файлов по одному символу. Сжатие будет нулевое. Еще у разбития на блоки есть такой минус: возможен вариант, когда нужные данные будут начинаться в одном блоке, а заканчиваться в другом.

1

я подозреваю что мы имеем дело с XY проблемой, хотелось бы узнать Х, а не способы решить Y

2

Сообщение от Welemir1 я подозреваю что мы имеем дело с XY проблемой

- и мне так показалось

0

Catstail,
Уже реализовал. Просто разрезаю файл на файлы по 1000000 символов и сжимаю в один архив, открываю нужный файл и в нём ищу через seek. Время поиска - доли секунды. Но это костыли и если понадобится файл целиком - его придётся обратно собирать. Несколько файлов в одном архиве хранить - путаница. А при добавлении нового файлы недостаточно его заархивировать - ещё и разрезать нужно.
Мне решение этой задачи нужно что бы читать архивные данные с кое-каких приборов из файлов. База данных не вариант данные слишком разнообразные. Файлы без сжатия тоже - в архивах файлы весят около 400 GB, а без архивов - 10 терабайт (формат json).

Welemir1, А что тут сложного? Разархивация файла занимает даже меньше времени, чем его чтение с диска. Я специально это даже тестировал. Что бы прочитать файл в чистом виде нужно больше времени, чем что бы прочитать архив и разархивировать файл. И нет, сжатие будет не сильно хуже. Я сравнивал сжатие файла целиком и сжатие этого же файла, разрезаного на куски по мегабайту. Разница считаные проценты. А если использовать один и тот же словарь для сжатия, то разницы не будет вовсе. Мета информация об архиве - размер сейчас, где начало в памяти сейчас, где начало в памяти до сжатия. Вот и вся информация, которая требуется. Технически всё возможно, я уверен, должны были существовать люди, которые это уже реализовали.

0

Testfor, а если для хранения информации использовать БД?

1

Сообщение от Testfor Технически всё возможно, я уверен, должны были существовать люди, которые это уже реализовали.

- при условии, что это кому-то нужно...

0

u235, Ну я не собираюсь ударяться в крайности. С математической точки зрения поиск нужного блока занимает константное время. Поиск строки в нужном блоке логарифмическое время. Так что очевидно, что чем больше блоков - тем быстрее поиск, но меньше сжатие.

Поэтому я просто протестировал разбиения на файлы по 10kk, 1kk, 100k, 10k символов и некоторые промежуточные, посчитал время доступа к нужной строке в среднем с учётом ситуации, когда она оказывается в нескольких файлах. Оптимальным соотношением мне показались блоки в 1kk символов. Естественно хорошо бы иметь библиотеку, написанную профессионалами, которая берёт всё это на себя.

0

Сообщение от Testfor а без архивов - 10 терабайт (формат json).

- возможно, имеет смысл продумать свою структуру для этих архивов. Типа деревьев поиска или тому подобного. Ведь поиск в json-файлах Вы осуществляете не по произвольному контексту, а по конкретным наборам... Короче, оказаться от плоских файлов. Или загнать все в БД.

0

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

Добавлено через 12 минут
Catstail, Red white socks, Welemir1, u235,
Проблема X - есть терабайты файлов неправильного формата, строки в которых упорядочены по дате, которая в них содержится в формате json. По этой же дате я ищу файлах строки из нужного временного диапазона. Использую алгоритм больше-меньше. Вариант добавить в базу данных сложно реализуем.
Во-первых тогда нужно парсить исходные данные и приводить их к формату SQL. И будет очень сложно сделать так, что бы не возникло никаких ошибок, особенно учитывая, что в самих данных тоже встречаются куски SQL кода, а данные очень разнообразные.
Во-вторых доступ к данным есть у широкого круга лиц. А я знаю SQL недостаточно хорошо, что бы защититься от инъекции.
В-третьих данные часто требуются в исходном виде в виде файлов и придётся хранить две копии - в базе SQL и в исходном формате. Данные большие, место не бесплатное.
В-четвёртых данные поступают в формате json. И выводить их тоже нужно в формате json. Так что если парсить и структурировать данные - дополнительная нагрузка и двойная работа. И не факт, что не возникнет ошибок, так как, например, кавычки где-то используются одинарные, а где-то двойные.

Добавлено через 5 минут
И последний момент. Да, я собираюсь перевести все данные в базу данных в дальнейшем. Но это займёт несколько недель минимум. А поиск в архивах можно запустить уже завтра и он будет работать в это время.

0

Но вы же все равно каким-то образом парсите файл? То, что это данные с приборов, а значит каким то образом унифицированы - прямая причина использования БД. Даже без грамотной архитектуры, получив самые базовые знания, вы удивитесь, насколько быстрой может стать работа. И насколько меньше места занимают они по сравнению с текстовой простыней. А уж с грамотной...
У меня ощущение, что я рассказываю достоинства таблицы умножения. Сорри.

0

Testfor, прочитал проблему Х, не просто. Если есть время почитай например про МонгоДБ, это NoSQL БД, то ест не надо знать сиквель, прям вот живой жсон туда суешь и все. И достаешь тоже жсон и ищет она сама, просто задашь ей что индексировать по полю дата. Инъекции ей нипочем, она не знает сиквеля, жсоны для нее родные, причем хранит она их в своем сжатом формате (BSON) то есть места будут занимать меньше.
Это не гарантия, я же не вижу всей проблемы, но потенциально это снимает целый ряд проблем описаных выше(в теории вообще все проблемы).

0

Red white socks, Welemir1,
Данные не только с приборов, но и с сайтов, с API и.т.п. Короче компания по маркетингу, агрегации данных, информированию, актуализации и всё в этом духе. Зарплат для найма профессиональных програмистов у них нет, поэтому самый квалифицированный работник - студент с третьего курса бакалавриата, который вам сейчас пишет. И паршу данные не я. Их парсит программа, написанная тем, кто работал тут до меня. Принимает json, выдаёт работникам читабельный формат данных. Трогать её нельзя, если развалится, починить некому. В SQL у меня данные поверхностные мягко говоря. Пару дней назад я тут спрашивал, почему команда SOURSE не работает что бы было понятно... Я понимаю, что всю эту систему нужно переделывать и как раз изучаю сейчас базы данных, но работы не на одну неделю, поэтому ищу как запустить прямо сейчас. Пока работает на данных возрастом недели две, так что слоган про актуальность начинает эту актуальность терять.

0

Если посмотреть в корень проблемы (как раз Х ), то наверняка с приборов можно забирать данные более кошерным способом. Какой-нибудь OPC-сервер + скада, которая прекрасно работает с общепризнанной БД, типа мускуля или постгреса. И выборка тебе, и визуализация, и все остальное...

Добавлено через 44 секунды
Упс. Пока писал пост, этого не видел. Пардон

0