Обновить

Комментарии 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 джойн по первичному ключу, который "ничего не стоит" практически вместо двух и индексированного поиска.

Массивы в постгрес - это мощный инструмент, но про него в статье ни слова, однако. )

Спасибо за развернутый ответ :) Не ставил себе цель описать все варианты оптимизации

Пихать данные в джейсон, а потом индексировать его по полям .. до этого мог додуматься только чат-гопоты, прошу прощения за резкость. Нонсенс.

Гораздо раньше ИИ. См Oracle xml query

В MSSQL тоже есть.

Регистры в 1С.

А что скажете про замену небольших редко изменяемых справочных таблиц «enum’ами» в Postgres?

Если не нужно жёстких гарантий чтобы при сбое ничего не потерялось, а нода только одна и хочется джоины и транзакции, то

возьми in-memory SQLite (крэйт rusqlite). Там будут нормальные джоины и индексы из коробки. Будет очень быстро, часто быстрее чем хешмапы. Для персистентности можно настроить периодический синк в Postgres. Если задача аналитическая (OLAP), бери polars (датафреймы).

А где наиболее эффективные методы, основанные на денормализации и предрасчёте? А если говорить о конкретно поставленной в тексте задаче - так ещё и на секционировании/партиционировании?

Я понимаю что автор пытается продвигать свой телеграм-канал, но я не думаю что читатели Хабра оценят этот опус. Хотите продвигаться - напишите что-либо ценное, интересное и народ пойдет к вам.

В кэш можно загонять не только маленькие таблицы. На очень нагруженном проекте мы исключали все join связки. Все таблицы сателлиты были подняты в память. Выгружаем основную таблицу с ид ключами, а далее добавляем ей описания и расширения из таблиц сателлитов.

Обновление:

Каждая таблица завернуть в сервис. Сервис слушает события обновления своих данных и тут как пожелаете перечитать либо сбросить до следующего запроса инициализации.

На одном проекте был поднят в память весь КЛАДР. Тут сервис был со своим API. Пользователи 1м+ спокойно без тормозов его трогали.

В упор не вижу бенефитов от включения total в idx_orders_cover

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации