Подтвердить что ты не робот

Любая причина не использует PostgreSQL встроенный полнотекстовый поиск на Heroku?

Я собираюсь развернуть приложение Rails на Heroku, которое требует полнотекстового поиска. До сих пор я запускал его на VPS, используя MySQL с Sphinx.

Однако, если я хочу использовать Sphinx или Solr на Heroku, мне нужно будет заплатить за дополнение.

Я замечаю, что PostgreSQL (БД, используемая на Heroku) имеет встроенную функцию полнотекстового поиска.

Есть ли причина, по которой я не мог использовать полнотекстовый поиск Postgres? Это медленнее, чем Sphinx, или есть некоторые другие основные ограничения?

4b9b3361

ОТВЕТЫ

Ответ 1

Изменить, 2016 - Почему не оба?

Если вы заинтересованы в Postgres vs. Lucene, почему бы и нет? Проверьте расширение ZomboDB для Postgres, которое интегрирует Elasticsearch в качестве первоклассного типа индекса. Еще довольно ранний проект, но для меня это выглядит очень многообещающе.

(Технически недоступно на Heroku, но все равно стоит посмотреть.)

Раскрытие информации: Я являюсь соучредителем Websolr и Bonsai Дополнения к Heroku, поэтому моя перспектива немного смещена к Lucene.

В полнотекстовом поиске Postgres я прочитал, что он довольно прост для простых случаев использования, но существует ряд причин, по которым Lucene (и, следовательно, Solr и ElasticSearch) превосходит как по производительности, так и по функциональности.

Для начала jpountz дает поистине превосходный технический ответ на вопрос, Почему Solr намного быстрее, чем Postgres? Это стоит нескольких прочитанных, чтобы действительно переварить.

Я также прокомментировал недавний эпизод RailsCast сравнивающий относительные преимущества и недостатки полнотекстового поиска Postgres против Solr. Позвольте мне напомнить, что здесь:

Прагматические преимущества для Postgres

  • Повторно используйте существующую службу, которую вы уже используете, вместо настройки и обслуживания (или оплаты) чего-то еще.
  • Далеко превосходит фантастически медленный SQL LIKE.
  • Меньше хлопот, сохраняя данные в синхронизации, так как все они находятся в одной и той же базе данных - нет интеграции на уровне приложения с каким-то внешним API служб данных.

Преимущества для Solr (или ElasticSearch)

Сверху моей головы, в определенном порядке...

  • Масштабируйте свою индексацию и поисковую нагрузку отдельно от обычной загрузки базы данных.
  • Более гибкий анализ терминов для таких вещей, как нормализация нормализации, лингвистическая генерация, N-граммы, удаление разметки... Другие интересные функции, такие как проверка орфографии, "богатый контент" (например, PDF и Word)...
  • Solr/Lucene может делать все, что угодно, полнотекстовый поиск TODO-списка Postgres.
  • Значительно лучшее и быстрое ранжирование релевантности терминов, эффективно настраиваемое во время поиска.
  • Вероятно, более быстрая производительность поиска для общих терминов или сложных запросов.
  • Вероятно, более эффективная производительность индексирования, чем Postgres.
  • Лучшая переносимость изменений в вашей модели данных путем развязывания индексирования из вашего основного хранилища данных

Очевидно, я считаю, что лучший вариант здесь - специализированная поисковая система, основанная на Lucene. В принципе, вы можете думать о Lucene как фактическом хранилище с открытым исходным кодом опыта поиска.

Но если ваш единственный вариант - это оператор LIKE, то полнотекстовый поиск Postgres - это определенная победа.

Ответ 2

Так как я просто попытался сравнить результаты поиска (1.9) с postgres FTS, я решил, что должен поделиться своими результатами, поскольку они несколько более тесны, чем цитируют @gustavodiazjaimes.

Моя главная забота о postgres заключалась в том, что у нее не было фасеток, но это тривиально, чтобы построить себя, вот мой пример (в django):

results = YourModel.objects.filter(vector_search=query)
facets = (results
    .values('book')
    .annotate(total=Count('book'))
    .order_by('book'))

Я использую postgres 9.6 и elastic-search 1.9 (через стог сена на django). Здесь сравнение между elasticsearch и postgres по 16 различным типам запросов.

    es_times  pg_times  es_times_faceted  pg_times_faceted
0   0.065972  0.000543          0.015538          0.037876
1   0.000292  0.000233          0.005865          0.007130
2   0.000257  0.000229          0.005203          0.002168
3   0.000247  0.000161          0.003052          0.001299
4   0.000276  0.000150          0.002647          0.001167
5   0.000245  0.000151          0.005098          0.001512
6   0.000251  0.000155          0.005317          0.002550
7   0.000331  0.000163          0.005635          0.002202
8   0.000268  0.000168          0.006469          0.002408
9   0.000290  0.000236          0.006167          0.002398
10  0.000364  0.000224          0.005755          0.001846
11  0.000264  0.000182          0.005153          0.001667
12  0.000287  0.000153          0.010218          0.001769
13  0.000264  0.000231          0.005309          0.001586
14  0.000257  0.000195          0.004813          0.001562
15  0.000248  0.000174          0.032146          0.002246
                  count      mean       std       min       25%       50%       75%       max
es_times           16.0  0.004382  0.016424  0.000245  0.000255  0.000266  0.000291  0.065972
pg_times           16.0  0.000209  0.000095  0.000150  0.000160  0.000178  0.000229  0.000543
es_times_faceted   16.0  0.007774  0.007150  0.002647  0.005139  0.005476  0.006242  0.032146
pg_times_faceted   16.0  0.004462  0.009015  0.001167  0.001580  0.002007  0.002400  0.037876

Чтобы получить postgres для этих скоростей для фасетных поисков, мне пришлось использовать индекс GIN в поле с SearchVectorField, который является специфичным для Django, но я уверен, что другие фреймворки имеют похожий векторный тип.

Еще одно соображение заключается в том, что pg 9.6 теперь поддерживает фразу-сопоставление, которое огромно.

Мой урон заключается в том, что postgres для большинства случаев будет предпочтительным, поскольку он предлагает:

  • более простой стек
  • не требуется поиск зависимостей backend api wrapper с (мышление-сфинкс, django-sphinx, haystack и т.д.). Это может быть перетаскивание, поскольку они могут не поддерживать функции, которые выполняет ваш back-end (например, факел/агрегаты haystack).
  • имеет аналогичную производительность и функции (для моих нужд)

Ответ 3

Я нашел это удивительное сравнение и хочу поделиться им:

Полнотекстовый поиск в PostgreSQL

Время создания индекса LIKE-предикат - нет
PostgreSQL/GIN - 40 мин
Поиск сфинкса - 6 мин
Apache Lucene - 9 мин
Инвертированный индекс - высокий

Хранение индекса LIKE предикат - нет
PostgreSQL/GIN - 532 МБ
Поиск сфинксов - 533 МБ
Apache Lucene - 1071 МБ
Инвертированный индекс - 101 МБ

Скорость запроса LIKE предикат - более 90 секунд

PostgreSQL/GIN - 20 мс
Поиск сфинксов - 8 мс
Apache Lucene - 80 мс
Инвертированный индекс - 40 мс

Ответ 4

Полнотекстовый поиск Postgres обладает потрясающими возможностями в области создания, ранжирования/повышения, обработки синонимов, нечетких поисков среди других, но без поддержки грантового поиска.

Итак, если Postgres уже находится в вашем стеке, и вам не нужна грань, лучше попробуйте воспользоваться огромным преимуществом легкости хранения индексов при синхронизации и сохранении гладкого стека, прежде чем искать решения на основе Lucene - на если все ваше приложение не основано на поиске.

Ответ 5

Функция Postgresql FTS является зрелой и довольно быстрой при поиске. Это стоит того, чтобы убедиться.