Comments 22
Для обычных джейсонов ходящих через обычную апишку обычной десериализации Джексоном хватает с запасом. У вас же на балансире есть лимит на максимальный размер запроса и он разумный? Срочно ставьте, если нет.
Для гигабайтных файлов джейсон это не лучший выбор. Csv, например, лучше со всех сторон. Но бывает всякое. Там лучше использовать просто другие приемы. Не мучайте Джексон и используйте более подходящие решения.
Это ты энтерпрайзным цмскам расскажи ;) Которыми крупняк типа интела пользуется, умник :) Америку открыл :)
Ну и возьмите более подходящее для вашей задачи решение. Задача нестандартная и решение нестандартное. Это нормально.
Заодно и производительности тут вероятно стоит задуматься и потестировать разное. Тормозить на гигабайтных файликах просто.
Есть у меня подозрение, что я лучше понимаю о чем говорю ;) Забил.
Ну, а если серьезно - вот прилетает гигабайтный Джейсон, какое решение нестандартное решение? Понятно, что правильно уболтать поставщика данных, но пусть это невозможно, как быть? Какое нестандартное решение посоветуете?
Вводные: он прилетает не случайно в случайную апишку, а в специально предназначенное для этого место. Обычные апишки защищаем от такого заранее.
Принципы выбора: Нужен стриминг и быстрая обработка. Удобством жертвуем. Идеальным соблюдением стандартов тоже жертвуем, таких мест немного именно для них проверяем что ок. Таких методов все еще немного, писать сеньорами можно и на тестах не экономить.
Я бы взял https://jsoniter.com Там много всяких проблем, но для задачи парсить гигабайтные джесоны фиксированного формата он отлично подойдет.
В статье про гигабайтные джейсоны нигде не сказано. Синьеров хак не требует. И устроен совсем просто. Смешно то, что ты сам предположил и сам себе ответил :)
Так то самое быстрое и экономное это написать грамматику, она простая и сгенерить парсер, да и все. Но это другие предположения и условия, а в статье просто описан хак, без условий. Но нельзя было пройти мимо, надо было самовыразится :) :) :) Причем упорно развивать идею :)
Я как обычно про продакшен. Где 100500 апишек. Пишут разные люди и по разному. Максимальный разумный размер входного джейсона килобайты максимум. Ну пусть даже мегабайт.
В таких условиях хаков не должно быть вообще. Надёжность важнее всего. Скорость не принципиальна в разумных пределах (стандартный Джексон дает разумную скорость), программирование нужно максимально декларативное чтобы ошибаться негде вообще было, потоковая обработка не нужна ибо килобайты на входе. И зачем?
А особые случаи это всегда особые случаи. Их пишем отдельно по другому. Там допустимо всякое. Можно упороться и в оптимизацию и в особый код. И вероятно это даже принесет пользу. Гигабайт переварить побыстрее часто есть смысл
Ну, а если серьезно - вот прилетает гигабайтный Джейсон
Без ТЗ - результат ХЗ. Сделать то с ним что нужно? Без абстрактного "распарсить". Какие данные в нём? Какие из них нам нужны?
чёт слишком агрессивная реакция на комментарий к статье
Что с оформлением? Почти весь пост до ката. Код не отформатирован. Плюс хамская реакция на комментарий выше. Факир был пьян?
Перечитал статью два раза. Но все равно не понял смысл хака. Какая задача здесь решается?
Правильно ли я понимаю, что NestedModelConsumer внутри себя делает что то с NestedModel, а потом забывает про неё (за счёт чего и экономим память)?
А если мне понадобится дальше в коде работать с массивом NestedModel, то решение уже не подходит?
Я так понял что автор хотел обработать определённые значения вложенных объектов за линейное время и костанту по памяти. Но код плохо оформлен и приведена только его часть, а пояснение не блещет деталями, так что сложно сказать сработает ли такой подход. Особенно для не столь тривиальных JSON-ов.
видимо, коллбэком из десереализатора получать это чудо!
Какой-то кошмар
Выглядит как борьба с непонятным смыслом и целями.
JSON это не про компактное представление (это, обычно, не важно).
В любом случае крайне важно рухнуть с ошибкой сериализации если json не корректный/мы не умеем его десереализовать.
В статье происходит какой-то кошмар, бизнес-логика вшита в десереализатор.
Если у вас огромные массивы - есть json-stream, если огромный объект - json не очень подходит. В случае если апи не наше и делать нечего - можно строить костыли, но явно не вшивая бизнес-логику в десереализаторы. Что увидит сторонний человек, получивший ваш проект?! То, что у него null приходит как объект!!!
Если так уж надо - получайте input stream в роуте/контроллере да обрабатывайте в сервисах. Но скорее всего не надо
Jackson ObjectMapper Streaming API без возни