Комментарии 44
Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.


И что же использовать?

Есть SphinxSearch. Для совсем небольшего проекта может хватить PostgreSQL FTS. Есть ещё масса проектов, все названия не упомнить.

Elastic — в каком-то смысле «обёртка» над Lucene.
Graylog — в каком-то смысле «обёртка» над Elastic.

Elastic поверх Lucene добавляет отказоустойчивость, удобный API и другие плюшки.
А вот чего такого добавляет Graylog, что для поиска он становится удобней Elastic'a?
У Graylog есть фишки заточенные под сбор логов: доставка логов, алёрты из коробки и т.д., но в плане поиска есть ли у него какие преимущества?
Логи грейлог сам не доставляет, скорее грейлог это замена логстэшу и эластик кластер для грейлога создается отдельно (правда только версия эластика не выше шестерки). А так там тотже lucene query syntax для поиска.
Всё верно. Я это и имел в виду:
Для Graylog создаётся Elastic (вернее Graylog его создаёт и активно им управляет).
Плюс у Graylog своя обвязка вместо Kibana, Logstash и *beats.

Да, я вообще много раз сталкивался с тем, что ES использовали совсем не к месту, там, где вполне хватало встроенного в PostgreSQL FTS.


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


У меня отличные впечатления как от PostgreSQL FTS (но после определенного предела нагрузки он не тянет), так и от SphinxSearch (его используют такие монстры, как Craigslist и Avito). Но о них мало кто пишет, увы. Гораздо больше статей типа: «У меня сервис с 10 пользователями, и чтобы искать пользователя по имени или email, я внедрил кластер на 10 инстансах Elasticsearch, сейчас расскажу вам как». Overengineering хорошо продается работодателям, которые не в теме.

Да, Sphinx отлично себя зарекомендовал. На данный момент я пока не сталкивался с задачами по поиску, которые он бы с блеском не решал. Но в AWS есть managed elasticsearch и нет managed sphinx, и вообще product awareness у Sphinxsearch не очень. Даже на постсоветском пространстве далеко не каждый вспомнит про него, что уж говорить о Европе / США. А зря — это реально классная, полнофункциональная, производительная альтернатива ES.

У них большие проблемы с брендингом, маркетингом и позиционированнием. Например, открыл их сайт — там http (на дворе 2020 год если что и гугл, например не шттпс выдает ниже в выдаче, если вообще выдает). Сайт выглядит так как будто не менялся с 2001.

А как у PostgreSQL FTS c интерналицизацией? Поиск по записям на английском, немецом, франзуском, итальянском в частности, с учётом типовых замен букв с умляутами на латинские пары?

С поддержкой языков все в порядке, основные европейские языки, включая русский, поддерживаются.


Поиск одновременно на нескольких не использовал, но думаю, что можно реализовать...


Потом, я не говорю, что Postgres FTS может заменить ES во всех ситуациях. Я говорю, что множество раз видел ситуации, когда использовали ES там, где PostgreSQL хватает за глаза.

Просто интерсно есть ли смысл копать в этом направлении. С эластиком куча проблем, по сути только полтора человека из 15 с ним разбирается (и это нея :)), он у нас какой-то старой версии, а переезд на актуальную оценивается как сложный. А тут вот только-только переехали на Postgres с MySQL и может быть смысл поресичеть в этом направлении.

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


В highload лучше сразу SphinxSearch или ES или что-то еще использовать. Хотя до определенного предела его все же хватает, точно сказать, какая должна быть нагрузка, чтобы Postgres перестал справляться с FTS, не могу, давно это было.

У эластика есть собственные onsite курсы, которые за 2+2 дня позволят очень быстро втянуться в него. Либо же можно за 4+4 дня пройти тот же курс удаленно (вместо 8-часового треннинга в виртуальных классах используются 4-часовые). Если вам действительно нужно разбираться в решении, то пусть фирма выделит деньги на обучение сотрудников. Даже если вы после курсов поймете, что эластик не для вас, то это все равно будет лучше, чем копаться несколько месяцев и сделать те же выводы (только еще и с меньшей уверенностью).

Я никакие курсы не проходил. Все по обрывкам документации, StackOverflow и бесконечные попытки написать сложный запрос. Такая была жизнь фрилансера. На одном фрилансерском проекте попросили написать очень сложный ES запрос, а я о нем ничего не знал. Через два или три дня все-таки сумел его написать, хотя он был огромный и сложно понимаемый.


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


Прелесть ES в том, что с ней можно работать через браузер и командную строку (curl) — создавать индексы, наполнять их, писать запросы. Я этим постоянно пользуюсь при работе с ES. Например, два терминала рядом: в одном vim с текстом запроса, в другом — curl -XPOST -d @query.json http://localhost:9000


Но SphinxSearch в этом плане еще удобнее: он может работать по протоколу MySQL, и с ним можно взаимодействовать при помощи слегка нестандартных SQL запросов. В том числе, экспериментировать в командной строке используя стандартный клиет mysql.

Проблема не в написании запросов, а в эффективном их написании, а также правильной конфигурации кластера и решении проблем с ним. Вся информация доступна и так, но курсы её дают в сухом остатке. Банально экономят время (а это обычно деньги). К тому же есть у эластика и система сертификации, которую можно, конечно, пройти и без курсов, но тогда с реально большим опытом. За два-три дня самостоятельно — это прям совсем нереально для большинства. Сам сертификат — это, конечно, просто медалька, но процесс сдачи вскрывает кучу пробелов у сдающих, которые думали, что и так все знают.

На самом деле, для полнотекстового поиска можно использовать сам Lucene, например, и не заморачиваться с распределенностью

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


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

А что насчет бэкапов?
В мире ES в принципе есть для этого инструменты?
Или в подавляющем большинстве случаев (99.999%) elasticsearch используется для выгрузки данных из более привычных баз (postgres/mysql/mongodb) и если на датацентр, где располагается весь кластер, упадет метеорит и уничтожит все сервера вместе со всеми репликами, то всегда можно будет заново загрузить данные для поиска из оригинальных баз? Пусть это и может занять дни или недели, если базы громадные.
Если FS умеет, то можно делать снэпшоты на её уровне и просто копировать. Второй вариант — встроенное средство snapshot/restore, которое пишет пожатые копии индекса в папку, поддерживает инкрементальные обновления. Третий вариант — дампить сами объекты штуками вроде elasticdump, они в формате json. Последний вариант самый медленный.
А в реальных системах часто ли делают бэкапы? Везде где приходилось сталкиваться с elastic, его использовали для загрузки данных из других баз с целью как раз искать по этим данным. Насчет бэкапирования не в курсе, делали ли.
У нас в компании elastic — основная база данных, а не второстепенная. Объемы данных исчисляются в терабайтах. И да, бэкапы делаем, что-то пару раз в сутки, что-то вообще каждые полчаса-час.
ES Native если не ошибаюсь давно deprecated и с версии на версию выпилят совсем.
И кстати разделение нод по ролям совсем не обязательно. Вполне можно использовать псевдоодноранговый кластер без выделенных координаторов.

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

Мы перепробовали все и Azure Search и Elastic и в итоге остановились на algolia.com
Когда пользователи начинают искать с летенси в 10мс у них глаза вылезают… Но опять же там есть свои нюансы.
Ну как пример нельзя искать внутри *text*. Там есть методы чтобы это обойти но из коробки не получится. Ну и цена. В остальном — лучшее что с нами случилось в плане поиска. НО, самое приятное это из коробки генерация токена с зашитыми параметрами поиска. То есть можно очень легко сгенерить токен для юзера в котором например будет зашита роль или tenantId. И дальше каждый раз когда юзер будет что-то искать результаты уже будут отфильтрованы по этим параметрам.
Когда пользователи начинают искать с летенси в 10мс у них глаза вылезают…


Так эластик вполне быстро ищет. Нет?
ну не получалось меньше 300мс выдать что-то. минимальный индекс 60к 100к документов.
Интересно. Ну мы сами эластик не юзаем, только lucene. Он ищет в пределах 1-10 мс. Правда документов пока пару тысяч.

Вы, возможно, используете неоптимальную схему хранения данных (маппинг). Плюс потери могут быть не из-за эластика, а из-за установления ssl соединения (если вы его не держите постоянно открытым). Ещё, вполне возможно, что вы используете не оптимальный запрос с аггрегацией. В общем, скорее всего что-то вы делаете не так.

В этом и вся соль — слишком много «чего-то» не так может быть. У нас нет времени копаться.
Как бы мы не пытались оптимизировать структуры данных и алгоритмы поиска, когда речь заходит о действительно больших массивах данных и действительно большом количестве запросов, необходимо задуматься о возможности повлиять на производительность системы путем увеличения аппаратного ресурса.

Не могли бы привести числа

Master-ноды отвечают за важные, но довольно легкие общекластерные действия. Это означает, что они требуют большого ресурса и высокой стабильности от физической ноды.

Если не затруднит,- внесите ясность

p.s. Ваша статья изобилует оценочными. Хотелось бы больше конкретики.

Я не решусь придумывать расчетные формулы, возможно они существуют. Но могу сказать, что многие цифры, которые встречаются в текстах Elastic были получены эмпирически. Касательно количества запросов и объема данных, здесь я пытался сказать, что эти цифры будут влиять на производительность кластера. Важно учитывать третью переменную — требуемое время выполнения. Например для пользовательского поиска я бы выжимал максимум скорости обработки. Т.е. важно отталкиваться от требований бизнеса в первую очередь.
Касательно мастеров, важные и легкие действия это, например, отправка запросов на выделение шарда или его перемещение. Важные потому что от них зависит работоспособность кластера, а легкие потому что не требуют сложной обработки данных. В этом контексте слово "большой" не совсем уместно, я с вами согласен, правильней будет "достаточный", достаточность зависит от количества нод в кластере и количества шардов. Главное — избегать пиков нагрузки близких к максимуму для физической ноды. Надеюсь, я немного прояснил.

Классная вещь, спасибо за статью! Но транзакций нету. А как же версия документов? Optimistic concurrency control? По моему один из главных аспектов ElasticSearch…

Спасибо. Транзакции в ES — интересная тема для отдельной публикации, хочу написать об этом тоже. А касательно остального, старался выразить все максимально кратко концентрируясь на
распределенности.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.