Как правильно обработать большой JSON файл, расположенный на удаленном сервере?

Question

[Messi]

Здравствуйте! Подскажите, пожалуйста, как правильно с таким работать?

Если на удаленном сервере JSON файл(размером 15ГБ), нужно сделать консольную команду которая будет обрабатываться, то есть получить данные и сохранить в базу.

Понимаю что скачивать на сервер и тд идея плохая, соответственно прошу подсказки каким образом лучше это сделать?

UPD: файл сохранить на сервер можно.

Comments

[FanatPHP]

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

доступ к коду на "удаленном сервере" есть?

[Messi]

FanatPHP, прямая ссылка на файл.

[FanatPHP]

если только ссылка то только скачивать

[PrAw]

Messi, можно в процессе скачивания сразу парсить, так что экономим этап - "скачать файл целиком, только потом парсить".

[Андрей]

а эти 15 Гб - это реально один json-объект, или все таки много-много-много объектов?

[Messi]

Много-много-много объектов. Наверное описание плохое:)

[Златослав Десятников]

Messi, если структура объектов одинаковая, то можно в стриме сохранять объект, потом как он будет полностью «скачан», сохранять его в базу.

Answer 1

[PrAw]

JSON такого объема в принципе идея плохая. Встроенная функция json_decode умрёт, придётся писать какой-то парсер.
Потому что эти 15 гигабайт должны будут целиком загрузиться в оперативную память, потом перестраиваться в объект. Итоговое потребление оперативной памяти пророчествую, не меньше 30 гигабайт и то считаю себя наивным.
Ключевая проблема - файл нельзя читать порциями по заранее известному разделителю, получая валидные фрагменты JSON.
Возможно добрые люди уже сделали из этого файла пачку JSON - просто дописывая построчно отдельные объекты, но тут лучше показать фрагмент файла, чтобы предлагать методы оптимизации.

Посмотрите такой вариант для командной строки, запускайте на сервере который не жалко, возможно придётся потом его ронять в перезагрузку - https://stedolan.github.io/jq/

Более цивильный вариант - CSV, читать построчно, копить пакет запросов в БД, пачкой в несколько десятков запросов лить в базу.

UPD: гениальный вариант - а если залить это счастье напрямую в MongoDB, а потом по отдельным записям кромсать - получится?

Comments

[ThunderCat]

Ключевая проблема - файл нельзя читать порциями.

Э? Почему? Что-то новое, я пропустил момент когда фалы перестали читаться кусками?

[Messi]

окей, а если файл можно сохранить на сервер, то это упрощает задачу?

[PrAw]

ThunderCat, осознал, поправил
файл нельзя читать порциями по заранее известному разделителю, получая валидные фрагменты JSON.

[PrAw]

Messi, это облегчит перезапуски в процессе дебага

[ThunderCat]

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

[PrAw]

ThunderCat, я сильно подозреваю, что тут надо упомянуть программу, которая выплюнула такой толстый JSON, а потом искать решение вопроса с другой стороны

[ThunderCat]

PrAw, вполне возможно что это какой-то хитрожопый лог/парс, и теперь его надо сделать бигдатой, засунув в бд и натянув на какую-то нейронку.

[lukoie]

UPD: гениальный вариант - а если залить это счастье напрямую в MongoDB, а потом по отдельным записям кромсать - получится?

Неплохая идея. Осталость только замерять производительность. Возможно и правда даст хороший результат.

[Mikhail Osher]

Ключевая проблема - файл нельзя читать порциями по заранее известному разделителю, получая валидные фрагменты JSON

Можно, писали такое на проекте, где надо было парсить подобные файлы от сторонних сервисов.
Писал не я, но сам алгоритм незамысловатый. Заранее известно, что это стандартный валидный JSON, и дальше читаем небольшими блоками, каждый из которых парсится поочерёдно, а результат уже дальше стримится. Само собой, надо это всё как-то трэкать, запоминать последний "указатель", на случай, если оборвётся джоба.

[lubezniy]

Более цивильный тогда не csv, а xml: у него есть структура с возможностью вкладывать дочерние элементы, а также закрывающие тэги, и в php есть XMLReader, которым можно прочитать.

[PrAw]

lubezniy, да по большому счету оба формата можно читать поточно, но придётся прикладывать дополнительные усилия к написанию парсера,
lloyd.github.io/yajl вот уже готовый SAX парсер для JSON, но его еще и прикрутить надо

[lubezniy]

PrAw, В XML просто закрывающие тэги упрощают последовательный парсинг: сразу понятно, конец какого элемента достигнут, в отличие от } в JSON.

Answer 2

[ThunderCat]

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

Comments

[Messi]

Да, оказалось что можно сохранить на сервер.

[Messi]

А, напишите, пожалуйста, подробноее как можно открывать json "кусками"?

[ThunderCat]

Messi, основной проблемой может стать структура json, вам надо знать как расположены и что представляют из себя строки. Если строки примерно одинаковы, или хотя бы укладываются в какой-то паттерн, то проблем быть особо не должно.
https://www.php.net/manual/ru/function.stream-get-... - читаете файл построчно, находите начало и конец цельного куска данных, парсите. Запоминаете докуда дошли, оттуда начинаете следующий кусок. Собсно если структура не сильно разношерстная все можно сделать за час-два, а то и быстрее.

[Messi]

Как оказалось, утечки памяти были при использовании

$documentManager->getDocumentCollection('CollectionName')->batchInsert($data);

, а это от The Doctrine MongoDB.

Так же, для импорта использовал json stream, он выполняет задачу, но очень долго и я последовал вашему алгоритму, читать кусками с поиском начала и конца - это гениально:)
Работает ну очень быстро. Спасибо!

Answer 3

[Stalker_RED]

https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql...

Answer 4

[Евгений Матвеев]

можно на удалённом серваке выбрать нужные данные из файла, сделать компрессию .gz и передать на ваш сервак, где данные разархивировать , а потом уже в базу

Answer 5

[Игорь]

Интересно, за каким это **** 15 GB в JSON.
Стандартными средствами не прочитать.

Как минимум нужно разбить данные, по 1 MB, можно чуть больше.

json_decode и file_get_contents не осилят эту задачу.
Я уверен, что у вас недостаточно памяти, для решения этой задачи.
Даже если на сервере 30 GB, всё ровно не хватит, так как в "оперативке" данных будет гораздо больше.

Нужно писать парсер, локально парсить и больше так не делать!

Побайтное чтение файла.
3 строчки кода на delphi.

На данный момент, в одном проекте я работаю с файлом 1,5 GB
И поверьте, что бы подсчитать количество строк в нём, требуется 2 часа как минимум,
Учитывая характеристики ПК, где выполняется эта программа.
Но я себя хорошо чувствую с побайтовым чтеним.
Да хоть 100 GB, если файловая система позволяет.

Comments

[Messi]

Даже если скачать его на сервер и там обрабатывать - тоже будут проблемы?

[Игорь]

Messi, Здесь не зависит, где этот файл будет.
Всё зависит от инструментария.

В вашем случае, у вас не получится это сделать.
Инструменты для php, я уверен есть, осталось их найти.

[Messi]

Игорь, Спасибо

[hOtRush]

я бы посмотрел на стрим-парсер жсона на делфи в три строчки

[FanatPHP]

Игорь, зависит.
Если не скачать, то вообще ничего не получишь.

[Игорь]

hOtRush, Для разовой задачи, на раз, два

Вот с помощью этого
docwiki.embarcadero.com/Libraries/Rio/en/System.Re...

Но даже в delphi "не загрузить файл 15 GB"

Messi, мы можем получить доступ к файлу?
Ну или хотя бы мне.

[Игорь]

FanatPHP, Я имею в виду, что сам парсер где будет работать, на домашней машине или на сервере.

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

Для спасения данных (деление на файлы в этой же структуре)
Ненужно некуда грузить эти данные, а локально, на домашнем ПК
Поделить файл, а уже потом грузить на сервер, по 5 MB

Answer 6

[hOtRush]

https://github.com/skolodyazhnyy/json-stream

Comments

[Messi]

Утечки памяти тут:)

[hOtRush]

Messi, одну я находил и фиксил https://github.com/skolodyazhnyy/json-stream/issues/12 , больше за пять лет в продакшене не видел. Создай тикет если нашел