Comments 44
Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.
И что же использовать?
Graylog — в каком-то смысле «обёртка» над Elastic.
Elastic поверх Lucene добавляет отказоустойчивость, удобный API и другие плюшки.
А вот чего такого добавляет Graylog, что для поиска он становится удобней Elastic'a?
У Graylog есть фишки заточенные под сбор логов: доставка логов, алёрты из коробки и т.д., но в плане поиска есть ли у него какие преимущества?
Да, Sphinx отлично себя зарекомендовал. На данный момент я пока не сталкивался с задачами по поиску, которые он бы с блеском не решал. Но в AWS есть managed elasticsearch и нет managed sphinx, и вообще product awareness у Sphinxsearch не очень. Даже на постсоветском пространстве далеко не каждый вспомнит про него, что уж говорить о Европе / США. А зря — это реально классная, полнофункциональная, производительная альтернатива ES.
А как у PostgreSQL FTS c интерналицизацией? Поиск по записям на английском, немецом, франзуском, итальянском в частности, с учётом типовых замен букв с умляутами на латинские пары?
Просто интерсно есть ли смысл копать в этом направлении. С эластиком куча проблем, по сути только полтора человека из 15 с ним разбирается (и это нея :)), он у нас какой-то старой версии, а переезд на актуальную оценивается как сложный. А тут вот только-только переехали на Postgres с MySQL и может быть смысл поресичеть в этом направлении.
У эластика есть собственные onsite курсы, которые за 2+2 дня позволят очень быстро втянуться в него. Либо же можно за 4+4 дня пройти тот же курс удаленно (вместо 8-часового треннинга в виртуальных классах используются 4-часовые). Если вам действительно нужно разбираться в решении, то пусть фирма выделит деньги на обучение сотрудников. Даже если вы после курсов поймете, что эластик не для вас, то это все равно будет лучше, чем копаться несколько месяцев и сделать те же выводы (только еще и с меньшей уверенностью).
Спасибо за наводку, недешево оно, конечно.
Проблема не в написании запросов, а в эффективном их написании, а также правильной конфигурации кластера и решении проблем с ним. Вся информация доступна и так, но курсы её дают в сухом остатке. Банально экономят время (а это обычно деньги). К тому же есть у эластика и система сертификации, которую можно, конечно, пройти и без курсов, но тогда с реально большим опытом. За два-три дня самостоятельно — это прям совсем нереально для большинства. Сам сертификат — это, конечно, просто медалька, но процесс сдачи вскрывает кучу пробелов у сдающих, которые думали, что и так все знают.
Да, интригу подняли, а на вопрос так и не ответили.
В мире ES в принципе есть для этого инструменты?
Или в подавляющем большинстве случаев (99.999%) elasticsearch используется для выгрузки данных из более привычных баз (postgres/mysql/mongodb) и если на датацентр, где располагается весь кластер, упадет метеорит и уничтожит все сервера вместе со всеми репликами, то всегда можно будет заново загрузить данные для поиска из оригинальных баз? Пусть это и может занять дни или недели, если базы громадные.
Да, ES предоставляет возможность бэкапов вот тут поподробнее
Когда пользователи начинают искать с летенси в 10мс у них глаза вылезают… Но опять же там есть свои нюансы.
Когда пользователи начинают искать с летенси в 10мс у них глаза вылезают…
Так эластик вполне быстро ищет. Нет?
Вы, возможно, используете неоптимальную схему хранения данных (маппинг). Плюс потери могут быть не из-за эластика, а из-за установления ssl соединения (если вы его не держите постоянно открытым). Ещё, вполне возможно, что вы используете не оптимальный запрос с аггрегацией. В общем, скорее всего что-то вы делаете не так.
И ещё, вот эту статью читали: https://www.elastic.co/blog/advanced-tuning-finding-and-fixing-slow-elasticsearch-queries?
Как бы мы не пытались оптимизировать структуры данных и алгоритмы поиска, когда речь заходит о действительно больших массивах данных и действительно большом количестве запросов, необходимо задуматься о возможности повлиять на производительность системы путем увеличения аппаратного ресурса.
Не могли бы привести числа
Master-ноды отвечают за важные, но довольно легкие общекластерные действия. Это означает, что они требуют большого ресурса и высокой стабильности от физической ноды.
Если не затруднит,- внесите ясность
p.s. Ваша статья изобилует оценочными. Хотелось бы больше конкретики.
Я не решусь придумывать расчетные формулы, возможно они существуют. Но могу сказать, что многие цифры, которые встречаются в текстах Elastic были получены эмпирически. Касательно количества запросов и объема данных, здесь я пытался сказать, что эти цифры будут влиять на производительность кластера. Важно учитывать третью переменную — требуемое время выполнения. Например для пользовательского поиска я бы выжимал максимум скорости обработки. Т.е. важно отталкиваться от требований бизнеса в первую очередь.
Касательно мастеров, важные и легкие действия это, например, отправка запросов на выделение шарда или его перемещение. Важные потому что от них зависит работоспособность кластера, а легкие потому что не требуют сложной обработки данных. В этом контексте слово "большой" не совсем уместно, я с вами согласен, правильней будет "достаточный", достаточность зависит от количества нод в кластере и количества шардов. Главное — избегать пиков нагрузки близких к максимуму для физической ноды. Надеюсь, я немного прояснил.
С чего начинается Elasticsearch