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

Question

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

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

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

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

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

#programming #ruby #russian

0

17.07.2023

11 ответов

45 просмотров

Denis Gavrilin

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

0

17.07.2023

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

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

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

0

18.07.2023

Olexandr K.

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

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

0

18.07.2023

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

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

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

0

18.07.2023

Shrek44

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

Спасибо

0

18.07.2023

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

Shrek44
Спасибо

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

0

18.07.2023

Cruel Mango

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

0

18.07.2023

Cruel Mango

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

0

18.07.2023

Mobidi

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

0

18.07.2023

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

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

0

18.07.2023

Shrek44 · Accepted Answer

Shrek44

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

0

17.07.2023

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

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

11 ответов

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