LINUX.ORG.RU

json tool

 


1

1

Предположим есть у меня файлик в котором json на 200 терабайт. Мне нужна консольная тулза которая смогла бы что то в него добавить, удалить, изменить и выбрать. Тупо в один поток консольная тулза. Может файлик не в json а в bson формате. Может рядом лежит файлик с индексом который построила эта тулза по тем полям что я сказал.

Знаете такую тулзу? Не предлагайте postgresql (он пока кстати такое и не пережует) и mongodb (сомневаюсь что и оно такое осилит). Нужен минимальный кирпичик на основе которого возможно можно построить свой бильярд с официантками.

★★

Предположим есть у меня файлик в котором json на 200 терабайт. Мне нужна консольная тулза которая смогла бы что то в него добавить, удалить, изменить и выбрать.

Не нужна.

Может рядом лежит файлик с индексом который построила эта тулза по тем полям что я сказал.

Это и есть pg/mongo. Если даже они такое не осилят, то куда там консольним великам.

crutch_master ★★★★★
()

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

dd

Deleted
()

Тупо в один поток консольная тулза.

Посчитай, сколько времени эти 200 терабайт будут просто читаться с диска. Это огромный размер. Надо всё структурировать и раскидывать по таблицам или как-то еще. Вариантов нет.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)

Ок, я объясню, почему не воспринимаю вопрос всерьез.

Когда возникает _необходимость_ работать в экстремальных (от слова экстремум) условиях, то чаще всего лучшим решением является хак и компромисс. Надо немного подумать.

Почему?

Если у тебя 100500 таких 200терабайтных json файлов, то тебе сабж не поможет, нужно писать супероптимальное решение на, опять же, хаках.

Если ты планируешь заложить в свою информационную систему работу с такими файлами - то ты что-то делаешь неправильно.

Если у тебя два (один) таких файла - то нужно понять точнее, что требуется. Вдруг тебе надо все запятые там посчитать? Или убрать все переносы строк? Подобранное частное решение решит твои проблемы.

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

Если там индекс то оно может очень быстро отрабатывать.

Индекс сперва надо сделать. Просто представь его размер. Есть мысль - для начала раскидать json по каталогам. Простые значения - в файл, объекты - в каталог. Но это смотря какая там структура.

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

Если он будет переваривать хотя бы 50мб/сек, то чтобы просто потестить один запрос уйдёт примерно 2 месяца. (20 сек/гб * 1000* 200 = 4М сек / 3600 = 1111.1(1) ч / 24 ~ 46 суток)

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от Deleted

Добавлю еще. Если у тебя такой файл один, то тебе его надо рассматривать не как «ААА!!11 большой json файл», а как однородный набор более элементарных элементов. Узлы дерева json? А может просто набор слов по определенному паттерну regex?

Даже работу с узлами можно построить совершенно по разному. Можно отсчитать скобочки и запятые, и воткнуть туда новый узел. Простым dd.

Deleted
()

Он у тебя точно 200 терабайт, а не гигабайт? Где ты его хранишь? У тебя там пара десятков дисков в RAID?

KivApple ★★★★★
()

Предположим есть у меня файлик в котором json на 200 терабайт

Предположим, у меня член 80см. Где мне найти женщин, которые не будут лопаться?

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

hateyoufeel ★★★★★
()

Ну ладно 200тб, ладно ещё выбрать, но изменить!? Ты даже для тролля слишком поехавший. Если осознаёшь, что менять возможно будет только только конкретные поля на значения такой же длины или короче (с паддингом в виде пробелов например), то ладно, но произвольные изменения тупо невозможны.

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

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

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

Простым dd.

Тут будут линейные тормоза. Это как std::vector против std::list

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

да с чего бы? может там json массив и мне нужно третий элемент из миллиарда выбрать. с чего бы 2 часа то?

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

У тебя он точно 200 ТЕРАбайт (200000 гигабайт)

Пускай будет 16 петабайт. Вообщем столько что пипец.

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

Он у тебя точно 200 терабайт, а не гигабайт? Где ты его хранишь? У тебя там пара десятков дисков в RAID?

Положим на ceph храню

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

произвольные изменения тупо невозможны

Да с чего бы? Думайте в терминах std::list а не std::vector

quester ★★
() автор топика

Если JSON на 200 терабайт, то поможет только утилита rm.

Miguel ★★★★★
()
Ответ на: комментарий от pru-mike

Никто в здравом уме не будет хранить Nгб+ в json

Есть задачи когда нужны денормализованные объекты и они могут пухнуть

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

Мб я тупой, но я не понимаю как ты собрался в json, записанном в фс, что-то линкать. Можно разве что выкусывать какие-то объекты и перемещать в конец. Но, это в любом случае будет неэффективно, а в зависимости от структуры может понадобиться перемещать терабайты.

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

Ну и да, если у тебя 16 петабайт json, то тут у всех член 2 метра в диаметре.

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

Никто в здравом уме не будет хранить Nгб+ в json

Есть задачи когда нужны денормализованные объекты и они могут пухнуть

  • не совать пальцы в розетку
  • не есть с ножа
  • не хранить > мегабайта в json

Если данные настолько пушистые, что «не ложатся» даже в mongo, то смотрите на triple-store (RDF) или графовые/мультимодельные БД (ArangoDB, OrientDB и т.п.).

Deleted
()

Python с подгрузкой по заданному размеру буфера.

anonymous
()
Ответ на: комментарий от quester

Даже если не знаете, ничего не мешает его так раскидать, кроме ограничение инод.

crutch_master ★★★★★
()

Не предлагайте postgresql (он пока кстати такое и не пережует) и mongodb (сомневаюсь что и оно такое осилит)

Какие-то детсадовские представления о СУБД. Почему ты вообще думаешь что им есть какое-то дело до объёма твоих данных?

Знаете такую тулзу?

Сомневаюсь что есть готовое. Возьми yajl да напиши потоковый обработчик как тебе надо, это 2-3 страницы кода. Но если есть хотя бы зачатки мыслей о необходимости каких-то индексов, то даже не начинай, тебе однозначно нужна СУБД.

slovazap ★★★★★
()

Есть такая тулза. dd называется. Нужно знать адрес начала/конца интересующего блока(ты индекс обещал). Главное не перепутать seek= с skip=ом.

DonkeyHot ★★★★★
()

Ответа на «нулевой вопрос» (нах...зачем?) я точно не получу тут.

Но все же, 200Tb одним файлом это явно не просто на fs лежит.

Где это лежит? Если это HDFS или что-то подобное, то ответ будет одним, если это ceph то совсем другой, если это мега-raid то третий.

Опять же, как ты используешь этот файл? Он просто лежит? в него пишут? Если пишут то чем.

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

я не понимаю как ты собрался в json, записанном в фс, что-то линкать

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

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

Тогда тебе надо какую-то распределённую бд, а не консольный велосипед.

это размышления о элементе распределенной бд

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

Какие-то детсадовские представления о СУБД. Почему ты вообще думаешь что им есть какое-то дело до объёма твоих данных?

Потому что знаю. В posgresql 11 никакое поле строки не может быть больше 1 гигабайта по объему.

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

положим на ceph лежит. в него пишут. добавляют/изменяют/удаляют/читают его части. как я уже писал выше это теоретические размышления

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

В теории ты можешь и через jq это разобрать.

Но интересна же не теория, а суровая практика где есть реальная жизнь с ограничениями.

;)

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

теория часто продолжается практикой) это я переосмысливаю свои и чужие существующие решения

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

А я про объём данных. С вас объяснение зачем вы мне на это ответили про объём поля про который речи не шло вообще.

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

тема про хранение json. json в postgres храниться в поле строки. поле строки не может быть больше 1 гигабайта.

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

А кто предлагает запихивать весь json в одну строку, уж не вы ли? Расскажите как вы пришли к такой идее. У нас же речь шла о записи данных в набор строк таблицы, построении над этим индексов и быстрой работе уже с этим.

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

Я. Предложите заодно как вы будете объединять два json из двух строк в один при выборке и как вы будете распределять входящий json на два (или X) при обновлении.

quester ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.