Справедливое замечание, поймали. Честно говоря, в тексте я действительно сослался на эту цифру без оговорок — и это моя недоработка.
Но раз уж вопрос поднят, давайте технически разберемся. Цифра "в 6 раз" появляется в одном из бенчмарков MongoDB, где сравнивали именно сценарий частых обновлений JSONB-полей в PostgreSQL и BSON-документов в MongoDB. Суть не в том, что MongoDB всегда в 6 раз компактнее, а в том, как сильно TOAST в PostgreSQL раздувает дисковое пространство при обновлениях (MVCC + перезапись всего TOAST-объекта + WAL). В сценарии "дописываем сообщение в диалог" это особенно заметно.
Но вы правы: без методологии — это просто цифра. Поэтому я напишу отдельную статью-разбор.
Так что спасибо за вопрос — он подсветил слабое место в тексте и дал повод для полезного материала. Подпишитесь, чтобы не пропустить 😉
Возможно ты прав. Ты нажал кнопку — и всё полетело. Поздравляю. Ты остался в саманте пользователя.
Я же хочу понять, как кнопка врёт. Как SseEmitter бодается с Nginx, почему EventSource не любит POST, и куда пропадает последний чанк, когда ты забыл очистить буфер.
Твоя кнопка — это магия для обывателя. Моя кодовая база — анатомия для хирурга.
Я не ищу лёгкого полёта. Я погружаюсь в проблему и решаю ее с использованием технологий. Потому что только через вникание и глубокое понимание познаётся истинное устройство этого мира.
Благодарю, путник. Ты верно подметил отсутствие глянца на корпусе этого цифрового мясного рулета. Ибо истинный дзен-программист знает: баг — это не ошибка, а карма, проявленная в коде. Если стриминг работает с первого раза, значит, Вселенная просто отвлеклась и не успела подсунуть тебе stacktrace. Мы же, люди из плоти и костей, населенные демонами HTTP-2 и гоблинами корпоративных прокси, не смеем лгать сообществу. Пусть баг живёт, пока пульс не остановит докер-контейнер
Можно, конечно, но, если параметров станет не 3, а например, как в серьезном интернет-магазине, под пол сотни штук, то может получиться огромный сложный запрос с кучей джойнов и операторов.
ИМХО: Проще будет найти и внести изменения в java код, чем в огромный sql-запрос.
Справедливое замечание, поймали. Честно говоря, в тексте я действительно сослался на эту цифру без оговорок — и это моя недоработка.
Но раз уж вопрос поднят, давайте технически разберемся. Цифра "в 6 раз" появляется в одном из бенчмарков MongoDB, где сравнивали именно сценарий частых обновлений JSONB-полей в PostgreSQL и BSON-документов в MongoDB. Суть не в том, что MongoDB всегда в 6 раз компактнее, а в том, как сильно TOAST в PostgreSQL раздувает дисковое пространство при обновлениях (MVCC + перезапись всего TOAST-объекта + WAL). В сценарии "дописываем сообщение в диалог" это особенно заметно.
Но вы правы: без методологии — это просто цифра. Поэтому я напишу отдельную статью-разбор.
Так что спасибо за вопрос — он подсветил слабое место в тексте и дал повод для полезного материала. Подпишитесь, чтобы не пропустить 😉
Возможно ты прав. Ты нажал кнопку — и всё полетело. Поздравляю. Ты остался в саманте пользователя.
Я же хочу понять, как кнопка врёт. Как
SseEmitterбодается с Nginx, почемуEventSourceне любит POST, и куда пропадает последний чанк, когда ты забыл очистить буфер.Твоя кнопка — это магия для обывателя. Моя кодовая база — анатомия для хирурга.
Я не ищу лёгкого полёта. Я погружаюсь в проблему и решаю ее с использованием технологий. Потому что только через вникание и глубокое понимание познаётся истинное устройство этого мира.
Благодарю, путник. Ты верно подметил отсутствие глянца на корпусе этого цифрового мясного рулета. Ибо истинный дзен-программист знает: баг — это не ошибка, а карма, проявленная в коде. Если стриминг работает с первого раза, значит, Вселенная просто отвлеклась и не успела подсунуть тебе stacktrace. Мы же, люди из плоти и костей, населенные демонами HTTP-2 и гоблинами корпоративных прокси, не смеем лгать сообществу. Пусть баг живёт, пока пульс не остановит докер-контейнер
В рамках статьи рассматривактся вопрос сборки селекта, а не архитектура БД.
Можно, конечно, но, если параметров станет не 3, а например, как в серьезном интернет-магазине, под пол сотни штук, то может получиться огромный сложный запрос с кучей джойнов и операторов.
ИМХО: Проще будет найти и внести изменения в java код, чем в огромный sql-запрос.