Работа с огромной базой JSON (>50 ГБ)

50Гб не должно вызывать проблем после импорта в мускуль/постгресс/whatever.

Уточни формат данных и что значит «работать», иначе не понятно что тебе посоветовать.

Если это .json файлы в количестве 50 Гигов - то загружать есть смысл в Mongo/ArangoDB/CouchDB, а не в MySQL.

Есть ли какие-то альтернативы?

SQLite

Непонятно, в чём именно проблемы. 50 ГБ это не огромные размеры, это крошечные размеры.

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

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

Не факт. Скорее всего у него миллионы мелких JSON-ов, а не один огромный. Даже если так, для какого это языка нет потокового парсера? Даже если так, JSON это примитивный формат, парсер для которого пишется на коленке за час.

Я предполагаю как, эту базу переконвертировать в CSV и запихнуть в MySQL

Направление мысли здравое, но лучше таки не через CSV, он узким местом будет.

Был бы XML, я б тебе посоветовал написать SAX-парсер. Сейчас бегло погуглил — для JSON в подобных случаях люди тоже велосипедят аналог SAX.

Если это .json файлы в количестве 50 Гигов - то загружать есть смысл в Mongo/ArangoDB/CouchDB, а не в MySQL.

И зачем ты для этой задачи предлагаешь всякую NoSQLщину? 50 Гб — это семечки для нормальной реляционной СУБД, того же PostgreSQL, например (кстати, возможно, что и для MySQL тоже, просто не пробовал).

Для JSON, ага. Некоторых упоротых товарищей хлебом не корми, дай только херни сказануть.

А чего именно тебе нужно делать с бащой и как? Clickhouse может импортировать напрямую из json и для него такой объём данных — ничто, минимум пердолинга предстоит. Ну илм можешь взять питонический ijson, например, и написать скрипт в несколько строк, который в stdout будет плевать csv для импорта в любую другуб бд.

((re)open)ldap

ну если у сервака 512 гигов, то да

Да даже если 256 мегов, тоже нормально.

Выше правильно написали, что конвертировать в csv перед записью в СУБД не нужно.

Я бы советовал данные запихнуть в mysql, затем нормализовать базу данных.

база была скачана полностью, чтобы не тянуть данные через API.

но большой размер базы вызывает большие трудности в работе с ней. Есть ли какие-то альтернативы?

Тянуть данные через API ?

Я бы все-таки подумал бы либо об документоориентированной бд (монга) либо о встроенных механизмах хранения json в других базах, напр., в постгрессе.

Если это данные стороннего сервиса, без строгих гарантий на соблюдения формата + если стоит задача не единоразово проделать эту операцию, а постоянно обновлять базу, то будет постоянный геммор подгонять схему под изменения данных. Учитывая, что сторонние ребята хранят все в json, я думаю, они не будут особо париться с их содержимым.

Может так проще.

https://dev.mysql.com/doc/refman/8.0/en/json.html

не в MySQL.

И зачем ты для этой задачи предлагаешь всякую NoSQLщину?

Потому что json древовидный.

Ну илм можешь взять питонический ijson, например, и написать скрипт в несколько строк, который в stdout будет плевать csv для импорта в любую другуб бд.

Чувак, ты не в теме. Ты не разложишь древовидный json в плоский CSV (или любую другую таблицу)

Неа. Не проще. В MySQL и postgres есть только поля формата json. В итоге ты получишь примерно то же самое, что получил бы храня это в текстовом файле. Mongo - отличный выбор для этого. Это ее use case.

Чувак, ты не в теме

Я-то как раз в теме. А ты мало того, что выдумал кейс о котором нет речи в топике, так ещё глупость сморозил.

Ничто не мешает его разложить на несколько таблиц, если объекты имеют разную структуру, либо в одну, если структура вложенных объектов идентична родителю. Просто генеришь айдишники и добавляешь поля для внешних ключей / ссылок на другие записи той же таблицы.

Проблема возникает только если тебе нужно извлекать это из таблиц обратно в json. В зависимости от субд масштаб проблемы разный, но это всегда решаемо, хоть и не всегда адекватно. В самом худшем случае придётся собирать его вне таблицы, отправляя по запросу на каждый объект, а в лучшем, собрать можно прямо в хранимой процедуре.

Ничто не мешает его разложить на несколько таблиц, если объекты имеют разную структуру, либо в одну, если структура вложенных объектов идентична родителю. Просто генеришь айдишники и добавляешь поля для внешних ключей / ссылок на другие записи той же таблицы.

Разложить то можно, а вот что-то делать с этим проблематично.

Проблема возникает только если тебе нужно извлекать это из таблиц обратно в json.

Ты и сам это тут же подтверждаешь. Это будут просто как-то уложенные в таблицы данные.
Зачем копать яму молотком, когда существуют лопаты?

с того момента, как в постгрес завезли jsonb, нужность монги под большим сомнением, особенно после того, как утихли визги про noSQL и в свежие монги начали пихать ACID под своим, кислотным соусом.
постгрес развивается просто дичайшими темпами, но уже 3 года назад нагибал nosql в «её» use case

а вот что-то делать с этим проблематично

Зависит от задачи. Ты заведомо предположил такую, в которой от укладывания в таблицы одни проблемы, но найдётся и тысяча кейсов, где всё ровно наоборот. У ТС мб в json вообще что-то типа лога.

нужность монги под большим сомнением, особенно после того, как утихли визги про noSQL

Меня очень веселит, что спорят со мной люди, которые вообще не представляют что такое noSQL и зачем он нужен. И так же, похоже не знают как выглядит json. И я не знаю как postgres кого «натягивает», но хотел бы посмотреть на insert, который добавит hashtag в статью.

{ 'id' : '111',
  'post' : 
     { 'text': 'something',
       'hashtag': ['first' , 'second'] 
     }
}

у ментов на десктопе обычно Intel core E6200 с 2Гб памяти, кроме них больше никто в спи*енной базе ковыряться не будет
так что да, огромная база

Блин, json и придуман для того, чтобы передавать структуры. А для «плоских» данных он избыточный.

У ТС мб в json вообще что-то типа лога.

xтримиста ищут по айпи

2 ГБ памяти это более, чем достаточно.

у ментов на десктопе обычно Intel core E6200 с 2Гб памяти, кроме них больше никто в спи*енной базе ковыряться не будет

Менты записали бы эти json в Cronos - специально и для ментов, и для NoSQL замечательно подходит. Сетевая БД, с многомерными полями. По сути - родной дедушка Mongo etc.

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

Можно, но выйдет немного костыльно

В твоей бинарной вселенной бывает либо плоский, либо дерево с бесконечной вложенностью?

А для «плоских» данных он избыточный

Ты опять какую-то дичь выдумываешь. Напоминаю, что изначально JSON — Object в JS.

jsonb_insert(value, '{post,hashtag,0}', '"bla"')

Ключевое слово «объект». Не строка, не массив.

И строка выборки из реляционной бд прекрасно ложится на этот самый объект (которому ничто не мешает быть плоским), как большинство JSON API и работает.

А кто такой value, почему 0 в path'е и где указание таблицы?
Но давай усложним. Как ты будешь искать все записи где есть hashtag «postgres»?

Отстань. Я ничего не имею против реляционных баз данных. Но я против того, чтобы в них древовидные структуры складывать. Уж слишком неудобно и трудозатратно.

Отстаю, но апоминаю, что это ты ко мне со своими древовидными структурами пристал, а не я к тебе.

А кто такой value

jsonb-значение, куда ты хочешь вставить тег.

почему 0 в path'е

Позиция для вставки

и где указание таблицы?

update mytable set value = jsonb_insert(value, ...) where ... или как тебе угодно.

Но давай усложним. Как ты будешь искать все записи где есть hashtag «postgres»?

select ... from mytable where value->'post'->'hashtag' ? 'postgres'

А теперь покажи, как это делать в твоей любимой БД (монго?), тоже интересно. И насколько сложно создать индекс для «искать все записи где есть hashtag «postgres»» (в постгресе это тривиально).

У меня нет любимой db. Каждая db под свои задачи. Я не готов как ты решать все с помощью одного postgresql (не смотря на многолетнюю привязанность к нему).

И насколько сложно создать индекс для «искать все записи где есть hashtag «postgres»»

Вот как-то так.

db.collection.createIndex({post:1},{partialFilterExpression:{"post.hashtag":"postgres"}})

Смотря как хочешь работать, так-то скрипт писать не долго, один там файл или 50000. Конвертировать в CSV странно, зачем если можно сразу подключиться БД и лить сразу. У постгре вообще есть JSON поля, а так действительно, хоть в SQLite лей, 50Гб это не оче много.

Так у тебя много мелких файлов или один жирный?

Для поиска в .json часто берут ElasticSearch, вот тулза для импорта json в ElasticSearch

https://github.com/taskrabbit/elasticsearch-dump/blob/master/README.md

create index on test using gin ((value->'post'->'hashtag'))

мы же про partial index говорили, который индексирует то, что соответствует условию

создать индекс для «искать все записи где есть hashtag «postgres»»

Этот индекс поможет для всего, в том числе для postgres.

По-моему, конкретно mongo хороша тем, что из коробки умеет во вменяемое горизонтальное масштабирование + у неё есть так называемый aggregation framework, на котором даже сложные запросы не похожи на SQL-жесть.

Вообще, какой-нибудь пример записи было бы неплохо продемонстрировать. Может быть в SQLite все можно засунуть.