Комментарии 10
Странная статья, и явно писанная или причесанная чатом гопоты. Начать с того, что БД без индексов это и не БД вовсе, а сборище таблиц непойми зачем. Пихать данные в джейсон, а потом индексировать его по полям .. до этого мог додуматься только чат-гопоты, прошу прощения за резкость. Нонсенс.
Хотите без джойн на постгрес? Можно применить массивы. Пример:
ОСМ картография, стандартные таблички nodes, ways уж извините, структуру перечислять не буду, она у ОСМ в открытом доступе. И табличка связи way_nodes из трех полей: way_id, node_id и sequence -- порядок узлов линии. Многие ко многим. В случае поиска линий (ways) по нужным узлам имеем 2 джойна: nodes + way_nodes + ways, впрочем как и при обратном поиске нужных узлов по линиям.
Как можно обойтись без джойн? А просто. Добавляем в nodes поле in_ways bigint[] а в ways поле has_nodes bigint[] -- массивы в какие линии входит узел (как ни странно но это от 1 до 4 линий в среднем) и какие узлы содержатся в линии (тут может быть и до 100 и больше, но редко). Всё. В запросе поиска по узлам смотрим нужные узлы и в какие линии они входят, разворачивая массив, равно как и наоборот. Если нужны описания искомого, то имеем 1 джойн по первичному ключу, который "ничего не стоит" практически вместо двух и индексированного поиска.
Массивы в постгрес - это мощный инструмент, но про него в статье ни слова, однако. )
Регистры в 1С.
А что скажете про замену небольших редко изменяемых справочных таблиц «enum’ами» в Postgres?
Если не нужно жёстких гарантий чтобы при сбое ничего не потерялось, а нода только одна и хочется джоины и транзакции, то
возьми in-memory SQLite (крэйт rusqlite). Там будут нормальные джоины и индексы из коробки. Будет очень быстро, часто быстрее чем хешмапы. Для персистентности можно настроить периодический синк в Postgres. Если задача аналитическая (OLAP), бери polars (датафреймы).
А где наиболее эффективные методы, основанные на денормализации и предрасчёте? А если говорить о конкретно поставленной в тексте задаче - так ещё и на секционировании/партиционировании?
Я понимаю что автор пытается продвигать свой телеграм-канал, но я не думаю что читатели Хабра оценят этот опус. Хотите продвигаться - напишите что-либо ценное, интересное и народ пойдет к вам.
В кэш можно загонять не только маленькие таблицы. На очень нагруженном проекте мы исключали все join связки. Все таблицы сателлиты были подняты в память. Выгружаем основную таблицу с ид ключами, а далее добавляем ей описания и расширения из таблиц сателлитов.
Обновление:
Каждая таблица завернуть в сервис. Сервис слушает события обновления своих данных и тут как пожелаете перечитать либо сбросить до следующего запроса инициализации.
На одном проекте был поднят в память весь КЛАДР. Тут сервис был со своим API. Пользователи 1м+ спокойно без тормозов его трогали.
В упор не вижу бенефитов от включения total в idx_orders_cover

Ох уж эти join-ы: 4 способа ускорить ваши запросы в 10 раз