Какую технологию выбрать для поиска Elastic или Postgres?

Question

[Дмитрий]

Ситуация такая , делаем ТГ бота задача которого подтягивать документ из google docs и делать нечеткий поиск по документу , мнения в команде разошлись, поэтому свое мнение нужно пояснить и аргументировать . Спасибо !

На данный момент , есть такие точки зрения :

1)прогер который делает это проект , раньше с elastic не сталкивался , сам проект сделан на СУБД postgres , так же одна из сторон привела , как аргумент данную статью в пользу создание поиска на основе Postgre

2)
" ....Для него все равно необходимо писать дополнительный код. Тк в SQAlchemy такого функционала просто нет. Придётся напрямую работать с бд. И по отзывам работает этот extension довольно ерундово - медленно, и результаты поиска часто не совпадают с тем, что требовалось...."

Кто прав и почему ?)

Comments

[Ernest Faizullin]

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

Answer 1

[abmanimenja]

Вы оба не правы

делать нечеткий поиск по документу

Какой-какой? Fuzzy?
Вы точно понимаете о чём речь?

Elastic хорош в Full-Text-Search, а не в Fuzzy Search.
PostgreSQL тоже для Fuzzy Search не предназначен.

прогер который делает это проект , раньше с elastic не сталкивался

Да и вы тоже не компетентны:

Путаете виды поиска Fuzzy и Full-Text

И не понимаете, что Elastic силен только за счет своего кластера. Он намного более хорошо живет в огромном многосерверном кластере, чем PostgreSQL. Вам же это различие даже в голову не пришло.

А если же вам кластер не нужен - то и Elastic не нужен. Ибо он тормозной сравнительно.
Для односерверных машин отличный выбор SphinxSearch или его форк Мантикора.

Sphinx работает существенно быстрее, чем Elastic и жрет ресурсов памяти существенно меньше. Но не способен работать в кластере.

Кто прав и почему ?)

Прав тот, кто выше по иерархии.
Если вы не технический директор, то оставьте выбор технологии, на которой будет работать программист, ему самому.

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

Просто пишите на том, что знаете.

Answer 2

[Алексей]

ElasticSearch вам нужен будет только если будете расти, как abmanimenja сказал смысла от 1-го инстанса нет. Эластик прекрасен в кластере минимум из 3-х серверов со своей прекрасной отказоустойчивостью и горизонтальным масштабированием. И не стоит забывать о месте на дисках, по умолчанию эластик жмет данные, чего не умеет PostgreSQL. Так же можно за данными обращаться к любой ноде или выделенной клиентской(им) при большом кластере. И шардирование конечно из коробки. Но есть и минусы, эластик не очень любит DELETE и UPDATE, если у вас таких операций предполагается много, это НЕ ваш ВЫБОР.

Answer 3

[Антон Кокарев]

Из озвученной задачи я бы делал бота средствами Google Apps Script. Из плюсов - бесплатный хостинг для бота, с отличным uptime и временем выполнения; все необходимые библиотеки уже подключены и можно подключать свои. По идее, в api к гугло-докам должен быть поиск как среди списка файлов, так и внутри файла.
Делал бота на основе гугл таблиц - работает как часы! Даже cron задачи реализовал на основе ежеминутного тригера.

Comments

[abmanimenja]

Из плюсов - бесплатный хостинг для бота

Так себе аргумент. Экономите там, где не нужно.
Разработка будет стоить столько, что и 1% от той суммы хватит, чтобы оплатить хостинг на пару лет.

P.S.:
Ваше предложение годится только для детских поделок, где внутри бота примитивные только алгоритмы.
А за функционирование полноценного поиска вы будете Google отстегивать не по детски.

[Антон Кокарев]

abmanimenja, нормальный хостинг стоит хороших денег. Google в этом плане даёт нормальный хостинг для своих скриптов, лучше чем какой-нибудь VPS за 150₽/мес.

Стоимость разработки а первую очередь зависит от необходимых знаний разработки. GAS использует Javascript, который явно более популярен чем озвучены Postgres и Elastic, а значит и дешевле/проще в разработке.

ПыСы: в ТЗ озвучены примитивные задачи, Вы предлагаете для их решения создать терминатора с искуственным интеллектом, встроенным атомный реактором и кофеваркой?

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

var doc = DocumentApp.openById('id документа');
var textToHighlight = 'текст для подсветки';
var highlightStyle = {};
highlightStyle[DocumentApp.Attribute.FOREGROUND_COLOR] = '#FF0000';
var paras = doc.getParagraphs();
var textLocation = {}; 
for (i=0; i<paras.length; ++i)
{
    textLocation = paras[i].findText(textToHighlight);
    if (textLocation != null && textLocation.getStartOffset() != -1)
    {
        textLocation.getElement().setAttributes(textLocation.getStartOffset(),textLocation.getEndOffsetInclusive(), highlightStyle);
    }
}

[abmanimenja]

Антон Кокарев,

нормальный хостинг стоит хороших денег. Google в этом плане даёт нормальный хостинг для своих скриптов, лучше чем какой-нибудь VPS за 150₽/мес.

Я не спорю, что у Google хорошие технологии.
Сам использую их Cloud Platform.
Но это не дешевые технологии, хотя и очень хорошие.

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

"Нормальный хостинг стоит хороших денег" и "VPS за 150 рублей в месяц" в соседних предложениях звучат странно, вам не кажется?

Там стоимость работы на порядки большие, чем хостинг суммы.

[abmanimenja]

Антон Кокарев,

Стоимость разработки а первую очередь зависит от необходимых знаний разработки. GAS использует Javascript, который явно более популярен чем озвучены Postgres и Elastic, а значит и дешевле/проще в разработке.

Это не так, если у вас уже есть конкретные разработчики, которые знакомы с конкретными технологиями - как у автора вопроса.

[abmanimenja]

Антон Кокарев,

в ТЗ озвучены примитивные задачи

Давайте я процитирую то самое место в вопросе:

и делать нечеткий поиск по документу

Искусственный интеллект тут не нужен.
Но с бесплатным хостингом Гугля вы тут далеко не уедете.

[abmanimenja]

Антон Кокарев,

findText()

Searches the contents of the element for the specified text pattern using regular expressions.

A subset of the JavaScript regular expression features are not fully supported, such as capture groups and mode modifiers.

The provided regular expression pattern is independently matched against each text block contained in the current element.

Думаете, что если умным словом назван поиск, то он автоматически любой функционал дает?

[Антон Кокарев]

abmanimenja, нужны регулярки? есть, работают бесплатно

console.log(/abc/.test("abcde")); // → true
console.log(/abc/.test("abxde")); // → false

[Антон Кокарев]

abmanimenja,

и делать нечеткий поиск по документу

от части согласен, упустил это важное уточнение при беглом чтении. Про нечеткий поиск в гугл скриптах ни чего не знаю. Даже если его там нет в строенных функциях, наверняка найдется либа от стороннего разраба. Но тут хз, вероятно Postgres и Elastic будут лучше. Надо смотреть.

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

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

[abmanimenja]

Антон Кокарев,

есть, работают бесплатно

Регулярки в БД (оба упомянутых и Elastic и PostgreSQL - это СУБД)? Такое вообще бывает?

Регулярки подразумевают линейное сканирование при поиске, а СУБД предлагают поиск индексированный, что является противоположенностью линейного.

Хочу такую СУБД, в которой можно искать регулярками Подскажите название.

[Антон Кокарев]

abmanimenja,

Хочу такую СУБД, в которой можно искать регулярками!!!

MySQL подойдет? https://kbss.ru/blog/bd_mysql/2.html

Answer 4

[asd111]

Sphinx или elastic. В постгрес есть тонкости при полнотекстовом поиске чтобы не тормозило.