pro.jvm

22 February 2026 13:46

субд в кубере - это у тех, кто не шарит

pro.jvm

22 February 2026 13:46

Дим, твоя мета устарела лет на 5

pro.jvm

22 February 2026 13:45

главное, что ты после компоуза увидел кубер - уже достойно уважения

pro.jvm

22 February 2026 13:44

Не видел таких, везде в кубе было за последнее время

pro.jvm

22 February 2026 13:31

видимо аргумент то что это пет проект, но имхо без сносок про временость/нестабильность/бессмысленность решения такие советы давать это вред

pro.jvm

22 February 2026 13:29

плюс такая субд не масштабируется по волшебной кнопке увеличения числа реплик в сете

pro.jvm

22 February 2026 13:28

не надо стэйтфул сервисы пихать в куб

pro.jvm

22 February 2026 13:13

Ну вот как раз physical volume mount (и еще host network) убирает все потенциальные тормоза контейнеризации

pro.jvm

22 February 2026 12:47

Контейнер это просто группа процессов с некоторой доп. изоляцией. Т.е. это уже bare metal (не виртуалка). В этом контексте постгрю гонять в контейнерах совершенно нормально (только папочку с его файлами монтировать на внешний том).

pro.jvm

20 February 2026 00:57

Я просто, к чему. Если ты говоришь, что все таблицы связаны между собой 1:м по id например, зачем там куча экзистов и прочих сложностей, даже в ордер бай экзист.
Свяжи всё максимально просто, приджоини всё между собой и фильтрами играйся в where.
Такой запрос и тебе понятнее читать будет и оптимизировать легче

pro.jvm

20 February 2026 00:51

Хотя, подожди мб, тебе что-то утром подскажут завтра на свежую голову)

pro.jvm

20 February 2026 00:48

Ну, тут запрос уже тяжёлый. Ты индексами его не спасёшь, думаю)

pro.jvm

20 February 2026 00:46

Офсет в любом случае вроде всё зафетчит и тебе выдаст 20

pro.jvm

20 February 2026 00:43

ресурсы offset 1000 и уже пробежаться надо по индексу и промотать 1к entry

pro.jvm

20 February 2026 00:41

Ну тут точно над запросом надо работать, прям упрощать. С телефона такое не посмотреть

pro.jvm

22 February 2026 13:46

я уверен, что большинство деплойментов субд - это либо bare metal/vm, либо покупные managed

pro.jvm

22 February 2026 13:45

Я не говорю что их совсем нет

pro.jvm

22 February 2026 13:44

ну раз ты не видел, значит все

pro.jvm

22 February 2026 13:42

контекстно СУБД postgres можно еще отметить, что могут быть проблемы у тех, кто использует HP, и неосторожно настроены лимиты памяти. OOM Killer прибъет контейнер, хотя PG в чистом виде бы не умер.
И такие проблемы вряд ли хочется брать на экспертизу, когда их можно просто избежать.
Но в конце концов опыт решает

pro.jvm

22 February 2026 13:30

поэтому тут аргумент разве что все в 1 месте
но с точки зрения обслуживания даже в кубе такие сервисы разный ЖЦ имеют

pro.jvm

22 February 2026 13:29

Можно изучить cnpg, но вряд-ли для всех подойдёт

pro.jvm

22 February 2026 13:28

как раз-таки промышленные кластеры пг чаще всего вне куба

pro.jvm

22 February 2026 12:52

Есть противники, которые аргументируют тем что там виртуальные сисколы и медленные драйверы фс. Но оно не критично перед удобством в т.ч масштабирования

pro.jvm

22 February 2026 12:39

Интересно посмотреть что они скажут против опыта инженеров, держащих хайлоад кластеры пг в кубе

pro.jvm

20 February 2026 00:51

Чем больше фильтров, тем меньше выборка
Такой запрос весьма шустрый, менее секунды отдает ответ уже на фронты:)

pro.jvm

20 February 2026 00:49

ДБА давно бы с паяльником прибежали в каком-нибудь банке, если бы увидели такое))

pro.jvm

20 February 2026 00:46

Страшно)
Пол системы живет на этом контроллере, но запрашивают максимум 1-10 сущьностей, и часто имея при себе идишник

А на фронте идет именно поиск (точнее не с фронта запрос, а от бфф)
Написать еще один метод для бфф? Дак плохо, в двух местах поддерживать придется изменения

pro.jvm

20 February 2026 00:43

Более 100 с фронта не запросить

pro.jvm

20 February 2026 00:41

Наверное он про пагинацию через офсет) если очень большие данные, кейсет шустрее страницы листает

pro.jvm

20 February 2026 00:39

так limit offset банально могут кушать