Как организовать фильтрацию в БД по сложным фильтрам?

Question

[Artem Zv]

Раньше писал простые фильтры по одному-двум полям, но сейчас у меня стоит задача реализовать фильтрацию по множеству полей в базе `postgreSQL`.
На клиенте имеется форма с полями фильтров.... Что-то по типу того, что в яндекс-маркете.
Не могу представить как смоделировать всю логику, как задать индексы и т.д.
Вот предположим у меня есть следующие поля: age, first_name, sex, country, city, last_seen_at и прочие.
Разве правильным решением будет задать состовной индекс для всех этих полей? Ведь индекс будет очень жирным в таком случае. Более того, поле `last_seen_at` часто будет обновляться и как это может отразиться на производительности, если в БД будет 100 миллионов пользователей?
Мне кажется, что я что-то упускаю и такие вещи вообще решаются другим(и) инструментами или при помощи вспомогательных таблиц...
В общем, хотелось бы перенять опыт тех, кто с этим сталкивался и балогополучно решал таких задачки. Куда мне копать? Что изучать?

Answer 1

[Everything_is_bad]

Нет тут серебряной пули, включай логирование медленных запрос, анализируй его, по результатам создавай нужные индексы. Еще можно создать тестовый стенд и прогонять по нему самые распространенные запросы с нужным тебе rps, с посредствующим анализов лога медленных запрос и оптимизаций

Comments

[Artem Zv]

То есть ты хочешь сказать, что в том же самом яндекс-маркете по такому принципу сделано? Ты тысяча полей и куча разных индексов? И как быть с полем last_seen_at? Оно ведь часто обновляться будет, а это перестраиванние индекса(ов)

[Everything_is_bad]

Artem Zv, я ничего не сказал про яндекс-маркет, я ничего не сказал про "тысячу полей" и "куча разных индексов", я всего лишь сказал, что нет универсального решение, есть решение конкретной задачи, и оно всегда разное.

[Everything_is_bad]

Artem Zv,

И как быть с полем last_seen_at? Оно ведь часто обновляться будет, а это перестраиванние индекса(ов)

еще раз, надо реально смотреть какие запросы к тебе прилетают, какие из них проблемные, сколько их, и вот только на основе этих данных что предпринимать, может просто добавить индекс, может денормализовать базу, может прикрутить внешний кеш, вариантов куча.

[Artem Zv]

Everything_is_bad, Я больше хочу найти ответ не для решения проблемы, а для правильного моделирования таблицы или таблиц. Меня больше волнует как такое организовываю опытные разработчика с самого начала. Понятное дело, что в будущем могут повылазить проблемы и их нужно будет решать, но как построить систему изначально?! Вот именно это меня волнует больше. Просто мне кажется, что есть какой-то иной подход, а не просто создания индексов и композитных индексов, даже если эти индексы не наобум. Поэтому я здесь и справшиваю.

[Everything_is_bad]

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

Answer 2

[Сергей Соловьев]

В таких ситуациях надо делать так:

- Реализуем систему генерации нужного запроса с фильтрами
- На БД делаем возможность отслеживать запросы (время выполнения, частота использования и т.д.)
- Запускаем пользователей
- Собираем статистику по запросам
- Выявляем какие фильтры используются чаще всего
- Делаем индексы для этих выражений

Замечания:
- В postgres отслеживать запросы можно расширением pg_stat_statement. А вообще рекомендую главу 3 Мониторинг PostgreSQL
- Я сказал "индексы для выражений", т.к. скорее всего у тебя будут не простые поля, а именно выражения - Postgres позволяет по ним делать индекс
- Сколько времени собирать статистику - решай сам. например, как только все запросы начнут деградировать (не рекомендую до такого доводить)

Comments

[Artem Zv]

Выходит, что те запросы, которые будут использоваться редко могут, вполне себе, положить БД!? Ведь они не исключаются из фильтрации.

[Сергей Соловьев]

Artem Zv, на сколько критична проблема?
если приложение использует 1.5 человека, то одной бд хватит.

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

Чтобы дать решение, надо знать контекст, а так я дал общее решение