Доброго вечера есть таблица request_logs, в которой хранится великое множество записей

Question

Доброго вечера есть таблица request_logs, в которой хранится великое множество записей

о запросах на сторонние сервисы. в ней очень много записей

есть фильтрация на странице в админке по дате создания. если поставить большой интервал, запрос падает по тайм ауту

добавление индекса не помогает, так как планировщик запросов все равно юзает seq scan на больших объемах данных (на небольших - индекс все же юзается). если принудительно отключить seq scan, то планировщик начинает использовать индекс и запрос выполняется в 2 раза быстрее.

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

#programming #ruby #russian

0

17.07.2023

11 ответов

10 просмотров

Denis Gavrilin

Если большой запрос от сек скана не уйти. Решить можно пагинацией например

0

9 месяцев назад

Роман Хайдаров

Shrek44
Типа find_each что-то пробовали?

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

0

9 месяцев назад

Olexandr K.

Роман Хайдаров
Частичная подгрузка, проанализировать и выгружать ...

Нужен сфинкс или эластик или что-то типа такого

0

9 месяцев назад

Роман Хайдаров

Olexandr K.
Нужен сфинкс или эластик или что-то типа такого

Не работал с эластик. Если данных овер дох… не будет проблем с реинднксированием полей поиска?

0

9 месяцев назад

Shrek44

Роман Хайдаров
Частичная подгрузка, проанализировать и выгружать ...

Спасибо

0

9 месяцев назад

Роман Хайдаров

Shrek44
Спасибо

ещё радикальное решение есть, если постоянно приходиится обращаться к проблемной таблице "как заноза в" возможно стоит рассмотреть гаризонтальное или вертикальное разделение таблиц

0

9 месяцев назад

Cruel Mango

Вообще логи просто такие надо в кликхаузе хранить если по ним агреггация по гигантским объемам, по поводу перехода на seq scan возможно у него веса расставленны так, вернее если он выбирает секскан как я понимаю значит планировщик решил что он будет выгоднее, я видел в интернете решения, как например запускать VACUUM ANALYZE чтобы он пересчитывал веса, или изменить их в конфиге например вот чтото есть https://stackoverflow.com/questions/23143463/why-is-postgres-scanning-a-huge-table-instead-of-using-my-index

0

9 месяцев назад

Cruel Mango

1. Для таких логов удобнее пользоваться clickhouse, он как раз хорошо аггрегирует поколоночно и ищет записи в больших сегментах, но не выбирает, выбирает медленно по идее. 2. Планировщику можно изменить веса в конфиге как показано здесь https://stackoverflow.com/a/23144500 или попробовать заставить переанализировать таблицу VACUUM ANALYZE я бы попробовал, может в этом дело.

0

9 месяцев назад

Mobidi

Выше верно написали про clickhouse. В идеале переходить на энтерпрайз стандарт логирования. Коллектор + OLAP хранилище + графана. В любом из мейнстрим паттернов реализована разбиение и уплотнение временных чанков

0

9 месяцев назад

Вадим Кручинин

Партиционировать

0

9 месяцев назад

Shrek44 · Accepted Answer

Shrek44

Типа find_each что-то пробовали?

0

9 месяцев назад

169 похожих чатов

Доброго вечера есть таблица request_logs, в которой хранится великое множество записей

11 ответов

Похожие вопросы