Из Википедия :
Инструменты, которые правильно читают ZIP-архивы, должны сканировать конец подписи записи центрального каталога, а затем, при необходимости, другие указанные записи центрального каталога. Они не должны сканировать записи в верхней части ZIP-файла, потому что ... только центральный каталог указывает, где начинается фрагмент файла и что он не был удален. Сканирование может привести к ложным срабатываниям, так как формат не запрещает другим данным находиться между порциями, а также файловым потокам данных, содержащим такие подписи.
Другими словами, если вы попытаетесь сделать это, не посмотрев сначала на конец zip-файла, вы можете случайно включить в себя удаленные файлы. Таким образом, вы не можете доверять потоковым распаковщикам. Однако, если zip-файл не был изменен с момента его создания, возможно, потоковые парсеры можно доверять. Если вы не хотите рисковать, не используйте потоковый анализатор. (Это означает, что вы были правы, сначала загрузив файл на диск.)
В некоторой степени это зависит от структуры zip-архива: если он состоит из множества файлов среднего размера, и если все они могут обрабатываться независимо, тогда вам не нужно иметь слишком много его в памяти в любой момент. один раз. С другой стороны, если вы попытаетесь обрабатывать много файлов параллельно, вы можете столкнуться с ограничением числа файловых дескрипторов, которые могут быть открыты. Но вы можете обойти это, используя что-то вроде queue .
Вы говорите, что должны отсортировать данные по идентификатору устройства и отметке времени. Это еще одна часть процесса, которую нельзя транслировать. Если вам нужно отсортировать большой список данных, я бы рекомендовал сначала сохранить его в базе данных; Таким образом, вы можете сделать его настолько большим, насколько позволит ваш диск, но и структурированным. У вас будет таблица, в которой столбцы - это столбцы TSV. Вы можете выполнять потоковую передачу из файла TSV в базу данных, а также индексировать базу данных по deviceId и timestamp. И под этим я подразумеваю один индекс, который использует оба столбца в указанном порядке.
Если вам нужна распределенная инфраструктура, возможно, вы могли бы хранить разные идентификаторы устройств на разных дисках с разными процессорами и т. Д. (Слово «sharding» - это слово, которое вы хотите Google). Но я не знаю, будет ли это быстрее. Это ускорит доступ к диску. Но это может создать узкое место в сетевых подключениях из-за задержки или пропускной способности, в зависимости от того, насколько взаимосвязаны различные идентификаторы устройств.
О, и если вы собираетесь запускать несколько экземпляров этого процесса параллельно, не забудьте создать отдельные базы данных или, по крайней мере, добавить еще один столбец в базу данных, чтобы различать отдельные экземпляры.