Есть приложение, построенное как database per client.
В каждой базе свой набор таблиц со своими полями, т.е. у разных клиентов разные структуры данных.
У одного клиента может быть 2-3 таблицы на 10-100 тысяч записей, у другого - 5-10 таблиц на 1-10 миллионов записей.
В каждой таблице - десятки, иногда сотни столбцов.
По каждому столбцу клиент может искать. Единовременно, обычно, клиент делает для себя настройку, по которой он видит 10-20 столбцов, но предугадать, что ему понадобится в дальнейшем, невозможно.
Очевидно, создать индекс на каждую колонку для ускорения поиска будет крайне накладно. При этом поиск для каждого типа данных, конечно, различается. Для int <, >, =, для строк contains, not contains, starts with, ends with и т.д.
Есть пара идей решения:
1. Можем собирать статистику, по каким колонкам клиент чаще ищет и на ее основе автоматически создавать или удалять индексы (create index concurrently, чтобы не блокировать ему работу), при этом обязательно учитывая характер запросов, чтобы правильные индексы проставить.
2. Каким-то образом все клиентские данные выгружать в elastic или аналогичную систему и поиск делать через нее. Этого хотелось бы избежать по понятным причинам в виде расходов на кластер, на разработку, на поддержку и доп. железо
Есть ли варианты, как такая проблема решается, когда схема данных не фиксированная и поиск может работать по любой существующей колонке? Хотя бы ключевые слова для гугла.
первое, что приходит в голову - подключить поисковик типа Sphinx или Elastic, и когда пользователь меняет набор колонок, обновлять конфиг поисковика и делать реиндекс. А искать уже через поисковик.
Jsty, с CH дело не имел, а только прочёл несколько статей. Стоит прочесть статью выше. По-моему, имеет смысл периодически выгружать данные из Postgresql для последующего анализа.
для строк contains, not contains, starts with, ends with и т.д.
Поиск по любым колонкам решается инвертированными индексами.
Если хочется именно в рамках PostgreSQL остаться, можно перейти на jsonb поля с GIN индексом.
Также в elasticsearch такие запросы хорошо работают, но его готовить уметь нужно.
