DP
Созданы недавно. Всё старше недели можно архивировать.
Сейчас они вообще не вытаскиваются, тупо мёртвый груз. Мне кажется, что можно иногда захотеть вытаскивать их по айди.
Есть, старые
Сейчас они вообще не вытаскиваются, тупо мёртвый груз. Мне кажется, что можно иногда захотеть вытаскивать их по айди.
Есть, старые
заявки ссылаются на город отправления и город назначения.Ага, понятно. Сначала я бы убедился, что индексы на таблицу, запросы и JOIN-ы написаны наиболее оптимальным способом (нужный порядок названий колонок во множественных индексах и SELECT-ах, нету “лишних” индексов и влоденных SELECT * WHERE ... IN SELECT … WHERE .. IN… и тп).
Если все ок, в таком случае, самое простое, что можно сделать на мой взгяд без внедрения timescaledb, таблиц, нарезающихся каждую неделю и переписываня весомой части кода в приложении чтобы с этим работать, это materialized view на таблицу заявок (orders?):
И повесить на нее индексы. Materialized view хорош тем, что он не вызывает select каждый раз, когда к нему обращаешся, и если у тебя запросов на запись много меньше, чем на чтение, то ты можешь обновлять materialized view хоть при каждом insert-e, (REFRESH MATERIALIZED VIEW CONCURRENTLY mymatview;)
Плюсы такого решения:
+ MATERIALIZED VIEW дает срез данных, нужный тебе чаще всего;
+ Инексы занимают мало места и быстры тк они используют только этот срез данныx;
+ Нет пролем с JOIN-ами, ключами и прочим: их можно сразу включить во VIEW, можно по желанию 🙂
+ Исходная таблица orders растет сколько влезет, раз в месяц можно в ней что-то найти, все отношения сохранены
Минусы:
- Нужно обновлять materialized view по изменению данных в исходной таблице через REFRESH;
- Не решает проблему с постоянно растущей исходной таблицей;
Подробнее
https://www.postgresql.org/docs/current/rules-materializedviews.html
https://postgrespro.ru/docs/postgrespro/12/rules-materializedviews
Что можно сделать еще:
- Отрезать данные каждые 6-12 месяцев в таблицу orders_archive_XXXX_XX_XX;
- Построить функциональные (https://www.postgresql.org/docs/current/indexes-expressional.html) или GiST индексы для range типов (у тебя это created_at, я так понимаю) (https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-INDEXING);
Если все ок, в таком случае, самое простое, что можно сделать на мой взгяд без внедрения timescaledb, таблиц, нарезающихся каждую неделю и переписываня весомой части кода в приложении чтобы с этим работать, это materialized view на таблицу заявок (orders?):
CREATE MATERIALIZED VIEW mymatview AS SELECT * FROM orders WHERE created_date > current_date - interval '7 days';
И повесить на нее индексы. Materialized view хорош тем, что он не вызывает select каждый раз, когда к нему обращаешся, и если у тебя запросов на запись много меньше, чем на чтение, то ты можешь обновлять materialized view хоть при каждом insert-e, (REFRESH MATERIALIZED VIEW CONCURRENTLY mymatview;)
Плюсы такого решения:
+ MATERIALIZED VIEW дает срез данных, нужный тебе чаще всего;
+ Инексы занимают мало места и быстры тк они используют только этот срез данныx;
+ Нет пролем с JOIN-ами, ключами и прочим: их можно сразу включить во VIEW, можно по желанию 🙂
+ Исходная таблица orders растет сколько влезет, раз в месяц можно в ней что-то найти, все отношения сохранены
Минусы:
- Нужно обновлять materialized view по изменению данных в исходной таблице через REFRESH;
- Не решает проблему с постоянно растущей исходной таблицей;
Подробнее
https://www.postgresql.org/docs/current/rules-materializedviews.html
https://postgrespro.ru/docs/postgrespro/12/rules-materializedviews
Что можно сделать еще:
- Отрезать данные каждые 6-12 месяцев в таблицу orders_archive_XXXX_XX_XX;
- Построить функциональные (https://www.postgresql.org/docs/current/indexes-expressional.html) или GiST индексы для range типов (у тебя это created_at, я так понимаю) (https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-INDEXING);
