LINUX.ORG.RU

json tool

 


1

1

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

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

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

Не нужна.

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

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

crutch_master ★★★★★ ()

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

Посчитай, сколько времени эти 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 ()

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

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

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

hateyoufeel ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

Deleted ()

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

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

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

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

slovazap ★★★★★ ()

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

DonkeyHot ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

quester ()