Elasticsearch поверх Postgres?

Question

[Sugarray]

В моем новом проекте имеется бд, которая получает данные из другого сервиса. Появилась задача реализовать полноценный поиск по всем атрибутам с множеством критериев, выбол пал на Elasticsearch. Изменять способ поступления данных (сразу в еластик) не представляется возможным. Для индексации таблиц я использую https://github.com/jprante/elasticsearch-jdbc , но к сожалению там не реализована вложенность при обращении к нескольким таблицам (значения старых массивов дублируются https://github.com/jprante/elasticsearch-jdbc/issu...). Пока на уме только одно решение - проиндексировать все нужные таблицы, и в несколько запросов собирать результат воедино. Может кто-то сталкивался или придумает еще что-то? Заранее спасибо!

Comments

[Sugarray]

Вспомнил о вопросе, небольшой апдейт :) Решение таки нашли - просто запилили свою реализацию при помощи psycopg2 , в разы производительнее "официального" решения.

Answer 1

[napolskih]

Думаю, что лучше избежать доп. инструмента, если возможно. Если возможно, то лучше воспользоваться полнотекстовым поиском ПГ. Эти возможности у него сейчас достаточно широки. Сами используем связку сфинкс + пг, и из-за этого имеем много проблем. Но у нас большая и сложная система, с серьезным поиском и она длительнао время развивалась.

Comments

[Sugarray]

Полнотекстовый поиск ПГ не устроил, доп инструмент уже определен (к счастью или к сожалению)

[napolskih]

чем не устроил?

[Sugarray]

napolskih: Нам нужен был нечеткий поиск, результаты не удовлетворили заказчика, и кто-то на митинге заикнулся про ES :). Собственно с тех пор я переписываю всю систему. Кстати, адекватного решения так и не нашел, пришлось индексить все таблицы.

[Николай Матюшенков]

napolskih Расскажите пожалуйста чуть подробнее, как была реализована связка pg+sphinx и какие проблемы пришлось решать? Сейчас для проекта аналогичное решение выглядит соблазнительно (расширение для pgsql), но на грабли наступать не хочется.

[napolskih]

у нас большие приложения на рельсах, с долгой историей, большой посещаемостью и множеством данных и функциональности.
pulscen.u
blizko.ru

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

у нас использует ридл + тинкинг сфинкс + своя прослойка, своя реализация репликации + юзали дистрибьютед индексы + рт индексы. пулинг конекточ написан.

сфинкс вообще устраивает, расстраивает только медленное развитие, нет роадмапа, нет поддержки нормальной (даже деньги им предлагали). понимаем что бесконечно добавлять атрибуты в сфинкс не можем.

в самом большом индексе (товары) у нас 50 лямов записей, очень сложный индекс, десятки полей всех типов, сложные запросы. чтение запись, в сфинксе рт индексы, данные всегда актуальные, пишутся туда же постоянно. запросов в сфинкс, если верить нашей статистике, 300 в сек.

много лет назад прообовали солр, все переписали, не взлетело. щас это уже малореально и не будем делать (много кода)

[Антон Тихомиров]

napolskih, а на сфинкс по какой причине переходили, скорость поиска? Тогда если не удовлетворил сфинкс, то какое решение бы выбрали бы сейчас, если поиск нужно выполнять по БД, в которой миллионы записей?

[napolskih]

Тогда альтернатив сфинксу особо не было, кроме может быть солра, который не подошел.

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

Если нет, то manticoresearch. Это наследник сфинкс который активно развивается.

Точно не сфинкс тк он практически мертв и не нужен.

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