Каков наилучший способ реализовать эффективный поиск с потенциально более 100 столбцами в таблице PostgreSQL БД?

Question

Следующая картинка похожа на то, что я пытаюсь выполнить sh.

1. Несколько объектов высокого уровня (таблицы), например: Как на изображении: Companies, People et c.
2. Потенциально сотни различных критериев фильтрации (каждый из которых является столбцом в таблице)
3. Примером запроса может быть: «Дайте мне все fintech стартапов, основанных на Сан-Франциско , что началось менее года go и привлекло более 1 миллион долларов финансирование "(жирные слова являются примерами значений фильтра)

Другим примером запроса для другого домена может быть: «Показать мне все веганский ресторанов в Лондоне , где рейтинг> 4,5 и ресторан возраст> 5 лет и среднемесячные клиенты> 5000 .

Что мне нужно знать, так это Какой самый лучший, самый эффективный способ реализовать это, чтобы получить тип Google-esque и получить мгновенный результаты опыта? У меня будут миллионы строк в каждой таблице, с почти сотней столбцов в каждой таблице (всего несколько десятков гигабайт необработанных данных, исключая индексы), которые могут играть роль полнотекстового поиска или действовать как фильтры / сортировка критерии.

Я использую PostgreSQL и изучил postgres возможности полнотекстового поиска, а также рассматриваю ElasticSearch. Является ли postgres собственный поиск + индексированные столбцы лучшим способом сделать это? Комбинация postgres +asticsearch? Что-то еще вообще?

Answer 1

Postgres - это реляционная база данных, которая хороша для нормализации данных и запросов, включающих несколько таблиц, но не очень хороша для поиска и фильтрации данных. Несмотря на то, чтоasticsearch очень хорош для поиска и фильтрации .

Elasticsearch даже предоставляет из кэша фильтра коробки , что означает, что если вы фильтруете данные на основе некоторых столбцов и снова некоторые другие пользователи используют те же критерии фильтрации, затем elasti c не будет снова фильтровать данные и выдает результат из своего кэша фильтра, как объяснено в справочной ссылке.

Я вижу, как MongoDB, так и Elasti c вариант использования в вашем приложении, Elasticsearch не является базой данных, и они также не нацелены на замену реляционных баз данных, и вы должны всегда использовать базы данных, если вы не можете позволить себе потерю данных, см. эту ссылку для обсуждения Elasticsearch для получения дополнительной информации .

Суть в том, что вы должны включать только релевантные атрибуты, которые будут использоваться для поиска и фильтрации в вашем поисковом индексе в этом случае, но вы также должны хранить свои данные в Postgres, если вы храните транзакционные данные и не можете себе позволить Утрата

https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html - отличная статья об устойчивости Elasticsearch и, исходя из ваших вариантов использования, можете ли вы использовать ее в качестве основного хранилища или нет.