LINUX.ORG.RU

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

 , ,


0

2

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

Задача в принципе одна, нужно с ней работать офлайн, в принципе даже через Access или Excel можно...

Я предполагаю как, эту базу переконвертировать в CSV и запихнуть в MySQL и дальше уже работать там, но большой размер базы вызывает большие трудности в работе с ней.

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

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

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

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

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

Legioner ★★★★★ ()

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

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

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

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

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

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

hobbit ★★★★★ ()

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

WitcherGeralt ★★ ()

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

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

dicos ()

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

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

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

router ★★★★★ ()

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

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

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

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

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

adn ★★ ()
Последнее исправление: adn (всего исправлений: 1)
Ответ на: комментарий от comma

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А кто такой value

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

почему 0 в path'е

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

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

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

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

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

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от adn

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

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

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

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

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

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

А как в postgres'е для таких json'ов это делается? (Для обычных таблиц я знаю)

adn ★★ ()

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

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

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

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

adn ★★ ()
Последнее исправление: adn (всего исправлений: 1)
Ответ на: комментарий от SevikL

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

Octagon ()