json tool

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

Не нужна.

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

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

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

dd

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

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

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

похоже на безумие, но потыкай https://stedolan.github.io/jq/

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

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

Почему?

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

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

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

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

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

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

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

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

Если даже там всё оптимизировать с индексами, ну выйдет 1 запрос за 2 часа, лол.

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

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

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

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

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

Иноды кончатся быстрее.

На cd-болванках

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

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

это если мы знаем структуру

Простым dd.

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

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

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

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

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

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

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

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

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

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

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

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

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

Пускай будет 16 петабайт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rm

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

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

;)

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

на практике, наверное, никто не будет делать такой большой файл ;)

вероятно)

Объём поля != объём данных.

естественно. я писал про объем поля

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

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

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

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