Рубрика «elasticsearch» - 10

image

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

В версии GitLab 9.1 появились канареечные развертывания. Они позволяют вам развертывать новый код на небольшой части вашей инфраструктуры. Если обнаружатся проблемы, они успеют затронуть лишь малую часть пользователей, и вы сможете легко откатиться к предыдущей версии. Это быстрая обратная связь от боевого окружения.

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

Читать полностью »

Пользователи ищут товары в интернет-магазине, ищут стати, поиск это неотъемлемый компонент сайта. Быстрый и гибкий поиск сложно реализовать средствами реляционных баз данных. Для таких задач используют поисковые движки, один из которых Elasticsearch. Elasticsearch хорошо документирован и доступен из коробки на AWS.

Для работы с elasticsearch используется библиотека elasticsearch-py или elasticsearch-dsl-py. elasticsearch-dsl-py это надстройка над elasticsearch-py, она проста в использовании и поддерживает elasticsearch версии 5.x. На базе этой библиотеки была создана библиотека django-rest-elasticsearch, которая основана на идеологии существующего поиска в Django REST Framework. Ниже я детально распишу как реализовать поиск в Django REST Framework с помощью elasticsearch используя данную библиотеку.

Читать полностью »

Как Discord индексирует миллиарды сообщений - 1

Миллионы пользователей ежемесячно отправляют миллиарды сообщений в Discord. Поиск в этих сообщениях стал одной из самых востребованных функций, какие мы сделали. Да будет поиск!

Требования

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

Читать полностью »

Поиск по большим документам в ElasticSearch - 1

Продолжаем цикл статей о том, как мы постигали ES в процессе создания Ambar. Первая статья цикла была о Хайлайтинге больших текстовых полей в ElasticSearch.

В этой статье мы расскажем о том как заставить ES работать быстро с документами более 100 Мб. Поиск в таких документах при подходе "в лоб" занимает десятки секунд. У нас получилось уменьшить это время до 6 мс.

Заинтересовавшихся просим под кат.

Читать полностью »

image redmine-logo

image elastic-logo

У нас используется система управления проектами и задачами Redmine. Мы продолжаем допиливать ее под свои нужды, чтобы повысить удобство работы и расширить функционал. Очередной задачей стало ускорение поиска.

С тех пор как количество задач в Redmine выросло до нескольких сотен тысяч, время на обработку поискового запроса стало занимать десятки секунд, что недопустимо долго для нас. Поэтому мы решили внедрить полнотекстовый поиск на основе Elasticsearch. Про это и будет данный пост.
Читать полностью »

Мониторинг Elasticsearch через боль и страдания - 1

Мы наконец допинали функционал мониторинга elasticsearch до публичного релиза. Суммарно мы переделывали его три раза, так как результат нас не устраивал и не показывал проблемы, которые мы огребали на нашем кластере ES.

Под катом история про наш production кластер, наши проблемы и наш новый мониторинг ES.

Читать полностью »

Как мы делали поиск в elasticsearch на vulners.com - 1

Как мы писали ранее, в качестве основной базы для поиска на сайте используется elasticsearch. Поиск в elastic работает очень быстро и из коробки доступно много полезных функций для работы с данными — полнотекстовый поиск, неточный поиск, всевозможные методы агрегации и тд.

И в отличии от классических SQL баз данных или noSQL типа MongoDB здесь очень удобно делать неточный поиск по всему документу. Для этого используется синтаксис Query DSL. Для полнотекстового поиска по всему документу есть несколько поисковых запросов. У себя на сайте мы используем тип query_string. Этот запрос поддерживает Lucene синтаксис, который позволяет и нам и пользователю создавать сложные запросы в google-style. Вот примеры таких запросов:

title:apache AND title:vulnerability
type:centos cvss.score:[8 TO 10]

Можно сделать вот такой простой запрос и все:

{
  "query": {
    "query_string": {
      "query": "exploit wordpress"
    }
  }
}

Но начав впервые использовать query_string, вы столкнетесь с тем, что поиск выдает не то, что вы хотите видеть. Как же добиться от elasticsearch внятного результата поиска?
Читать полностью »

image

Безопасная настройка TLS всегда был головной болью. Как для владельцев небольших ресурсов, так и для компаний, размер инфраструктуры которых может достигать нескольких сотен или даже тысяч доменов. Проблемы с TLSSSL появляются постоянно — уязвимости в самих протоколах, крипто-алгоритмах или их имплементациях. От всем известных Poodle и HeartBleed, до достаточно экзотичных и свежих (CVE-2016-2107) проблем с AES-NI.

А к чему приводят проблемы с TLS?
К краже учетных записей пользователей, администраторов, внедрению в трафик вредоносного контента, рекламы или, как это было с HeartBleed, даже к прямому доступу к памяти сервера.

Давайте взглянем на картину в целом.
На июль 2016 по данным проекта SSL Pulse, который анализирует настройки Alexa Top 200k доменов:

  • 40% из них имеют ошибки в конфигурации или используют недостаточно стойкие наборы алгоритмов шифрования
  • 25% имеют серьезные проблемы приводящие к реальной реализации атак на пользователей ресурсов или на сами ресурсы

А значит, у всех нас проблемы!

Читать полностью »

Зачем все это нужно

Все кто использовал Elasticsearch каластер для своих нужд (особенно для логирования и как основную базу данных) на больших нагрузках сталкивался с проблемами консистентности и масштабируемости. Когда требуется распараллелить нагрузку на Elasticsearch обычно применялись статические решения то типу NGINX+Elasticsearch. Это позволяет распараллелить нагрузку, но выглядит не слишком гибко. Особенно если учесть что ноды могут сами выпадать из кластера и простой хелсчек покажет что все отлично, а на самом деле нода перегружена, исключена из кластера. В любом случае хотелось бы иметь данные о состоянии кластера из первых рук, а не довольствоваться простыми проверками.
Итак, приступим к построению балансировки .

Как мы будем это делать

В данном случае мы будем использовать CAT node API, которое является частъю мощьнейшего CAT API, который является инструментом поиска заголовков по Elasticsearch клстреру.
Мы будем использовать только Gobetween и встроенные механизмы Elasticsearch для балансировки записи /чтения СRUD (DATA) нод при произвольном количестве/статусе нод в кластере.

Читать полностью »

В какой-то момент разработки проекта встал вопрос поиска по большому количеству текстов. Причем, тексты имеют различную длину: от твиттов до больших статей. Сначала, основным поисковым движком был выбран встроенный в Postgres _tsvector. Для поиска по простым правилам его было вполне достаточно. Массив текстов рос с большой скоростью, а правила поиска усложнялись, поэтому встроенный движок уже не покрывал требований.

Да, существует sphinx, у него есть отличная интеграция с Postgres, но была цель найти решение для использования elasticsearch с Postgres. Почему? elasticsearch показывал хорошие результаты в некоторых case-ах проекта. Да и уже был сервер с ним для хранения логов logstash-а. Также было желание найти такой инструмент, который полностью возьмет на себя синхронизацию данных.

В результате всего на просторах сети был найден проект ZomboDb, который как раз подходил под требования.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js