Что такое эластик серч

Почему Elasticsearch — хороший выбор для сбора и анализа данных среднего объёма

Авторизуйтесь

Почему Elasticsearch — хороший выбор для сбора и анализа данных среднего объёма

Рассказывает Франсуа Руа, руководитель отдела разработки ГК «Авилекс»

Контекст задачи

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

Часто бывает так, что масштаб проекта ещё недостаточно велик для внедрения крупных программных платформ наподобие Hadoop, и в этом случае вам помогут универсальные варианты на базе стандартных NoSQL-решений, которые позволят справиться с накоплением и обработкой данных среднего объёма.

К таким решениям, исходя из нашей практики, относится Elasticsearch.

Что такое Elasticsearch

Elasticsearch — это представитель кластерных NoSQL с JSON REST API.

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

Аппаратная платформа — Java Virtual Machine.

Официальные клиенты доступны на Java, NET (C#), Python, Groovy, JavaScript, PHP, Perl, Ruby.

Elasticsearch разрабатывается компанией Elastic вместе со связанными проектами, называемыми Elastic Stack, — Elasticsearch, Logstash, Beats и Kibana.

Beats — легковесные агенты и отправители данных с различных устройств. Logstash собирает и обрабатывает данные зарегистрированных событий. За хранение и поиск данных отвечает Elasticsearch. Kibana визуализирует данные через web-интерфейс.

Сегодня Elastic Stack с успехом используется сервисами eBay, Adobe, Uber, Nvidia, Blizzard, Citibank, Volkswagen, Microsoft, SoundCloud, GitHub, Netflix, Amazon. Чем же привлекателен Elasticsearch в контексте поставленной задачи? Давайте разберёмся.

Простой выбор

Одним из пунктов технического задания в рамках нашего проекта было требование собирать и анализировать статистику примерно с 25 (+/- 5) тысяч различных устройств.

Аппаратные возможности, операционные системы, сетевые интерфейсы, типы и назначение устройств неоднородны — от смартфона и телевизора до инфраструктурного сервера.

Устройства находятся в отдельных зданиях (примерно 1500 зданий, в каждом от 10 до 20 устройств), обслуживаются однотипной, но изолированной от других зданий инфраструктурой.

Оценив поставленную задачу, мы поняли, что нам не нужна большая суперсистема, которую можно отнести к категории BigData и/или HighLoad. С другой стороны, любые привычные методы сохранения и обработки информации, такие как запись в текстовый файл или SQL-базу, не подходили из-за объёма и специфики данных, поскольку большая часть работы происходила с логами устройств. Сыграло свою роль и наличие дополнительной статистики, которую сообщают сервисы, запущенные на устройствах.
Также в нашем случае по оценке объёма входящих данных, скорости их поступления и озвученных задач аналитики не было необходимости отдельно строить OLTP- и OLAP-системы.

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

Да и Elastic Stack в целом предназначен для решения такого класса задач.

А что, собственно, собираем?

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

Что на базе собранной информации хотят получить аналитики и менеджеры?

Самый частый из встречающихся сценариев — он же был изначально озвучен в техническом задании — это сбор и хранение всей (сырой) статистики по всем устройствам и сервисам за последний месяц с последующей агрегацией по дням и группировкой по зданиям с «бессрочным» хранением полученного результата.

Raw-индексы перезаписываются каждый месяц новыми данными, Agg-индексы накапливаются по дням «бесконечно» (пока хватает дискового пространства).

Все остальные пожелания по группировке и разбивке данных, по аналитическим срезам, визуальному представлению и т. п. выполняются аналитиками и менеджерами самостоятельно с использованием как Kibana, так и Power BI.

Периодически некоторые данные, чаще всего новые, получаемые из исходных, выделяются в отдельную задачу предварительного расчёта, которая выполняется с помощью вычислительной платформы Spark «по расписанию» и сохраняется в ещё один Agg-индекс, откуда эти подготовленные данные попадают в сложные отчёты и т. д.

Немного фактов о системе

Elasticsearch, как выяснилось, прекрасно подходит для работы в пределах определённого объёма данных (2–10 терабайт в год, 20–30 миллиардов документов в индексах), а также хорошо интегрируется с кластером Spark.

Агенты (Beats) помогают на конкретном устройстве или конкретном сервере собрать информацию, которая интересует пользователей системы. С помощью этих агентов можно собирать разного рода данные: системную информацию Windows из журнала, логи операционной системы Linux, данные устройства на ОС Android, самим анализировать трафик с устройства, будь то TCP, HTTP и т. д.

Локальный для инфраструктуры каждого здания Logstash отлично справляется с отправкой данных, собираемых агентами устройств, в централизованный кластер Elasticsearch, а Kibana предоставляет удобный способ построения веб-отчётов.

Необходимые инфраструктурные ресурсы

В нашем случае используется Linux-кластер в составе 3–10 нод.

Нода — это 8 процессорных ядер, 16–32 гигабайта оперативной памяти, жёсткий диск размером 1–5 терабайт. Сеть 1 Гигабит.

Масштабируемость

Данная подсистема статистики может работать с любой сферой деятельности, где требуется сбор и анализ статистических данных среднего объёма. Это может быть обработка статистической информации с 1 000 и до 30 000 холодильников, мобильных устройств, ноутбуков, интерактивных панелей и т. д.

Когда устройств меньше, чем 1–3 тысячи, система избыточна, есть более простые решения. Количество в 10 000–30 000 единиц оптимально по объёму и скорости появления новых данных с устройств.

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

Хотя, если мы воспринимаем 50–100 тысяч устройств как три сегмента по 15–30 тысяч, то можно просто запустить три подсистемы нашей статистики.

Основная идея заключается в том, что чем более изолированы «сектора», тем проще применить решение формата «три по тридцать».

Заключение

На примере проекта городского масштаба мы рассмотрели применение Elasticsearch для работы с большими данными, оценили его преимущества и целесообразность применения для задач, где массивные решения вроде Hadoop избыточны.

Источник

Быстрый полнотекстовый поиск ElasticSearch

При разработке высоконагруженных сайтов или корпоративных систем частенько возникает проблема с разработкой быстрого и удобного поискового движка. Ниже перечислены наиболее важные, на мой взгляд, требования к такому движку:

Так вот, недавно на глаза мне попалась презентация Андрея Змиевского (Andrei Zmievski), где он описывал возможности elasticsearch. Презентацию можно посмотреть тут (на английском).

К сожалению, никакой информации на русском языке я найти не смог.

Что же это такое?

По сути — это новый фронт-енд к широко известному индексу Lucene. Главное отличие от конкурентов — это гибкость и простота в использовании. Добавление информации в индекс и поиск по индексу производятся с помощью простых HTTP запросов.

Установка и примеры работы с движком

Меня эта тема заинтересовала и я решил собственноручно испытать этот чудо-движок.
Итак, приступим

Установка

Индексация данных

Для примера создадим индекс пользователей хабра

Добавляем данные о первом пользователе

Добавляем данные о втором пользователе

Добавляем третьего пользователя

Поиск: пробуем в деле

Для ознакомления я приведу несколько простых примеров поиска. На самом деле этот движок полностью соответствует своему названию “elastic” и можно создавать самые разнообразные запросы. Подробнее о запросах можно прочитать на сайте проекта www.elasticsearch.org/guide/reference/api

параметр pretty=true отображает ответ в более читабельном виде

пример 1: ищем всех пользователей с именем Ivan

пример 2: ищем всех пользователей из Украины со знанием PHP

пример 3: ищем пользователей из России

пример 4: подсчитываем количество пользователей из России

P.S. UTF8 поддерживает нормально

Тестирование с большим объёмом данных

К сожалению у меня нет большого опыта работы с другими поисковыми движками, поэтому нет возможности и сравнить их с elasticsearch. Любопытства ради решил создать индекс из 5,000,000 пользователей.

Простенький скрипт для заполнения индекса (данные генерируются, но информация более-менее похожа на реальную)

На создание индекса на моём домашнем (не особо мощном) ПК ушло где-то 5 часов. Учитывая то что я абсолютно ничего не настраивал и не оптимизировал, считаю что результат довольно неплохой. Тем более что время генерирования индекса для меня не особо критично. Думаю если покопаться в настройках, да ещё и оптимизировать мой скрипт так чтобы высылал не одиночные а групповые запросы (подробнее тут), то время сократилось бы в разы. Ну а если ещё и распараллелить этот процесс — тогда время можно сократить до часа.

Проверяем количество записей в индексе

Проверяем скорость добавления новой записи

Проверяем скорость поиска информации

Выводы

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

В этой статье я описал лишь небольшую часть его функционала — самые простые и примитивные функции. За пределами этой статьи остались транзакции, репликaции, фильтры и очень много других полезных функций. Также стоит упомянуть что к этому движку уже написаны библиотеки на Java и PHP (возможно и на других языках).

П.С. Прошу прощения за некоторое косноязычие текста и терминов.

Источник

Основы Elasticsearch

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.

Подобные движки используются при сложном поиске по базе документов. Например, поиск с учетом морфологии языка или поиск по geo координатам.

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

Чтобы не зависеть от операционной системы, все запросы к ES я буду делать с помощью CURL. Также есть плагин для google chrome под названием sense.

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

Установка ES

Для этого нам сначала потребуется Java. Разработчики рекомендуют установить версии Java новее, чем Java 8 update 20 или Java 7 update 55.

После установки и запуска проверим работоспособность:

Нам придет приблизительно такой ответ:

Индексация

ES автоматически создал индекс blog и тип post. Можно провести условную аналогию: индекс — это база данных, а тип — таблица в этой БД. Каждый тип имеет свою схему — mapping, также как и реляционная таблица. Mapping генерируется автоматически при индексации документа:

В ответе сервера я добавил в комментариях значения полей проиндексированного документа:

Стоит отметить, что ES не делает различий между одиночным значением и массивом значений. Например, поле title содержит просто заголовок, а поле tags — массив строк, хотя они представлены в mapping одинаково.
Позднее мы поговорим о маппинге более подобно.

Запросы

Извлечение документа по его id:

Ключ _version показывает версию документа. Он нужен для работы механизма оптимистических блокировок. Например, мы хотим изменить документ, имеющий версию 1. Мы отправляем измененный документ и указываем, что это правка документа с версией 1. Если кто-то другой тоже редактировал документ с версией 1 и отправил изменения раньше нас, то ES не примет наши изменения, т.к. он хранит документ с версией 2.

Ключ _source содержит тот документ, который мы индексировали. ES не использует это значение для поисковых операций, т.к. для поиска используются индексы. Для экономии места ES хранит сжатый исходный документ. Если нам нужен только id, а не весь исходный документ, то можно отключить хранение исходника.

Если нам не нужна дополнительная информация, можно получить только содержимое _source:

Также можно выбрать только определенные поля:

Давайте проиндексируем еще несколько постов и выполним более сложные запросы.

Сортировка

Мы выбрали последний пост. size ограничивает кол-во документов в выдаче. total показывает общее число документов, подходящих под запрос. sort в выдаче содержит массив целых чисел, по которым производится сортировка. Т.е. дата преобразовалась в целое число. Подробнее о сортировке можно прочитать в документации.

Фильтры и запросы

ES с версии 2 не различает фильты и запросы, вместо этого вводится понятие контекстов.
Контекст запроса отличается от контекста фильтра тем, что запрос генерирует _score и не кэшируется. Что такое _score я покажу позже.

Фильтрация по дате

Используем запрос range в контексте filter:

Фильтрация по тегам

Используем term query для поиска id документов, содержащих заданное слово:

Полнотекстовый поиск

Три наших документа содержат в поле content следующее:

Смешная история про котят

Смешная история про щенков

Душераздирающая история про бедного котенка с улицы

Используем match query для поиска id документов, содержащих заданное слово:

Однако, если искать «истории» в поле контент, то мы ничего не найдем, т.к. в индексе содержатся только оригинальные слова, а не их основы. Для того чтобы сделать качественный поиск, нужно настроить анализатор.

Поле _score показывает релевантность. Если запрос выпоняется в filter context, то значение _score всегда будет равно 1, что означает полное соответствие фильтру.

Анализаторы

Анализаторы нужны, чтобы преобразовать исходный текст в набор токенов.
Анализаторы состоят из одного Tokenizer и нескольких необязательных TokenFilters. Tokenizer может предшествовать нескольким CharFilters. Tokenizer разбивают исходную строку на токены, например, по пробелам и символам пунктуации. TokenFilter может изменять токены, удалять или добавлять новые, например, оставлять только основу слова, убирать предлоги, добавлять синонимы. CharFilter — изменяет исходную строку целиком, например, вырезает html теги.

В ES есть несколько стандартных анализаторов. Например, анализатор russian.

Воспользуемся api и посмотрим, как анализаторы standard и russian преобразуют строку «Веселые истории про котят»:

Стандартный анализатор разбил строку по пробелам и перевел все в нижний регистр, анализатор russian — убрал не значимые слова, перевел в нижний регистр и оставил основу слов.

Посмотрим, какие Tokenizer, TokenFilters, CharFilters использует анализатор russian:

Опишем свой анализатор на основе russian, который будет вырезать html теги. Назовем его default, т.к. анализатор с таким именем будет использоваться по умолчанию.

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

Создание индекса

Выше мы описали default анализатор. Он будет применяться ко всем строковым полям. Наш пост содержит массив тегов, соответственно, теги тоже будут обработаны анализатором. Т.к. мы ищем посты по точному соответствию тегу, то необходимо отключить анализ для поля tags.

Создадим индекс blog2 с анализатором и маппингом, в котором отключен анализ поля tags:

Добавим те же 3 поста в этот индекс (blog2). Я опущу этот процесс, т.к. он аналогичен добавлению документов в индекс blog.

Полнотекстовый поиск с поддержкой выражений

Познакомимся с еще одним типом запросов:

Т.к. мы используем анализатор с русским стеммингом, то этот запрос вернет все документы, хотя в них встречается только слово ‘история’.

Запрос может содержать специальные символы, например:

Источник

Поиск по вашему сайту, как в Яндексе или Google: зачем компаниям нужен Elasticsearch

Рассказываем на реальных примерах Netflix, Тинькофф, GitHub и других компаний, как одна технология помогает оптимизировать поиск по сайту, организовать мониторинг бизнес-показателей, обрабатывать неструктурированные сообщения сторонних систем и текстовые журналы, метрики сетевых, IoT и других устройств.

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

Elasticsearch (ES) – поисковая система с открытым исходным кодом, которая позволяет в режиме реального времени искать и анализировать данные в нереляционном хранилище. Elasticsearch – ядро экосистемы Elastic Stack, в состав которой также входят Logstash, Kibana и Beats.

Экосистема Elastic Stack состоит из сервисов, которые помогают собрать разнородные данные в едином хранилище и визуализировать результаты.

ES легко масштабируется и обладает высокой отказоустойчивостью. Когда речь идет о действительно больших объемах данных, многие системы не справляются с индексацией и поиском, и возникает вопрос масштабирования как инфраструктуры, так и сервисов. В Elasticsearch горизонтальное масштабирование реализовано на уровне архитектуры, поэтому в кластер можно «на лету» добавлять сервера, а сервис сам перераспределит нагрузку. Elasticsearch хранит данные в структуре, называемой индексом. Он автоматически распределяется по узлам кластера, а при сбое одного из них — перераспределяется на оставшиеся, используя внутренний механизм репликации данных.

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

Развертывание Elasticsearch на виртуальных машинах в облаке позволяет сократить время запуска и трудозатраты. Например, в облачной платформе Google, Amazon Web Services или Microsoft Azure.

Однако наиболее простой способ запуска кластера Elasticsearch – управляемый сервис. Облачные платформы позволяют создать кластер ES с оптимальной конфигурацией в несколько кликов, и при этом не нужно заниматься обновлением программного обеспечения, резервным копированием, мониторингом или обеспечением отказоустойчивости и безопасности. При изменении нагрузки масштабирование производится парой кликов. Как правило, облачные провайдеры предоставляет сервис в составе интегрированной экосистемы, что позволяет сэкономить время на связывании компонентов обработки данных между собой. А также всегда доступны инструменты для оперативного реагирования и управления кластером. Эту услугу предоставляет, например, Yandex.Cloud.

Elasticsearch позволяет качественно и быстро обрабатывать текст, в том числе при полнотекстовом поиске по всем выражениям во всех документах базы данных. Здесь можно привести в пример Яндекс или Google. Вы ввели запрос, и система поиска начинает анализировать все страницы в интернете без исключения, а не ищет абсолютно точное или универсальное совпадение с вашим запросом. Elasticsearch также анализирует и сохраняет все данные. Как это происходит?

Основой для работы с текстовыми документами является анализатор. Он представляет собой цепочкупоследовательных обработчиков.

Источник

С чего начинается Elasticsearch

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

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

Вторая проблема заключается в том, что пытаясь разобраться с начала, получить общую картину окажется непросто. Да инфы навалом, но последовательность в ее изучении выстраивается постфактум. Придется из книг бежать в документацию, а из документации обратно в книги, параллельно разгугливая тонкости, только чтобы понять, что такое Elasticsearch, почему он работает именно так и для чего же его вообще использовать, а где стоит выбрать что-то попроще.

В этой статье я попытался последовательно объяснить то что мне кажется главным в Elasticsearch, то для чего он был придуман и как он устроен.

Для наглядности выдумаем себе задачу. Реализация поиска в коллективном блоге по всем материалам и пользователям. Система позволяет создавать теги, сообщества, геометки и все остальные штуки, которые нам помогают категоризировать огромное количество информации.

Схема хранения данных

То, какие действия с данными мы будем производить определит схему их хранения:

Представьте еще раз сколько атрибутов может иметь публикация и сколько связанных с ней объектов. Автор, категория, сообщество, геометки, медиафайлы, теги, связанные публикации. Этот список можно продолжать до исчерпания фантазии. Если мы храним это в привычной реляционной базе то имеем миллион связей и миллиард атрибутов. Это прекрасно подходит для структурированного хранения долгие годы, но не очень вяжется с требованиями быстрого поиска.

А что если мы захотим добавить пару интеграций с внешними системами? Придется реализовать дополнительные таблицы или даже базы. Нам всегда будет нужно что-то добавить или изменить в объектах доступных для поиска. Вы понимаете к чему я клоню.

Намного быстрее читать из объектов, содержащих все необходимое здесь и сейчас. И намного проще вносить изменения в неструктурированную схему данных.

К тому же такие структуры данных проще делить, разносить по разным физическим хранилищам, распределять, ведь объекты уже содержат все необходимое.

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

Elasticsearch это документоориентированная база данных

Поиск

Теперь необходимо определиться с механизмами поиска. Данные организованы в виде документов. Как мы привыкли осуществлять поиск по документу?

Типичным примером документа будет веб-страница. Если мы попытаемся поискать по всей странице в браузере, поиск будет осуществляться по всему содержащемуся тексту. И это удобно для большинства кейсов.

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

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

Что такое индекс на самом деле? Если не вдаваться в детали, индекс это сбалансированное дерево, то есть дерево, в котором длина путей(количество шагов межу узлами) не будет отличаться больше чем на один шаг.

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

А что если сделать все наоборот — собрать список всех используемых слов и узнать, в каких документах они встречаются. Да, индексация займет больше времени, но нас в первую очередь интересует именно скорость поиска, а не индексации.

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

Хороший пример — популярная open-source библиотека полнотекстового поиска, конечно же, с обратным индексом, Apache Lucene.

Elasticsearch использует индексы Lucene для хранения данных и поиска

Масштабирование

Как бы мы не пытались оптимизировать структуры данных и алгоритмы поиска, когда речь заходит о действительно больших массивах данных и действительно большом количестве запросов, необходимо задуматься о возможности повлиять на производительность системы путем увеличения аппаратного ресурса. Проще говоря, мы хотим иметь возможность накинуть немного памяти, ЦП и дискового пространства, чтобы все ехало быстрее. Мы можем назвать это масштабируемостью.

Самый простой вариант — накинуть железа на сервер. Если представить каждую условную единицу вычислительной мощности как деревянный кубик, то сейчас мы сложим кубики в одно место или один на другой, строя башню вертикально. Такое масштабирование и называется вертикальным.

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

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

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

Распределенный индекс

Ок, для хранения данных и поиска мы будем использовать инстанс Lucene. Но ранее мы решили, что для обеспечения горизонтального масштабирования нам необходимо иметь возможность размещать данные на разных машинах. В действительности, какая разница как данные хранятся физически? Важно чтобы мы имели единое логическое хранилище. Каждый инстанс Lucene должен стать частью одного большого индекса, или осколком(shard) разбитого индекса. Шард будет выполнять непосредственно операции по поиску и записи данных.

Shard в Elasticsearch — это логическая единица хранения данных на уровне базы, которая является отдельным экземпляром Lucene.

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

Классическое сравнение индекса с другими базами выглядит примерно так.

Но существуют отличия в использовании этих абстракций. Рассмотрим еще один классический пример. У пользователя системы может храниться очень много информации, и мы решаем создавать новую базу для каждого пользователя. Это звучит дико! Но на самом деле в Elasticsearch это распространенная и даже хорошая практика. Индекс это довольно легкий механизм и лучше разделять большие данные, тем более, когда это логически оправдано. Системе проще работать с небольшими индексами чем с разросшейся базой для всего. Например, так вы можете создавать отдельный индекс для логов на каждый день и это широко используется.

По умолчанию количество шардов для индекса будет равным 5, но его всегда возможно изменить в настройках index.number_of_shards: 1 или с помощью запроса шаблонов индекса.

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

Каждый шард способен хранить примерно 2 32 или 4294967296 записей, это значит, что скорее всего вы упретесь в лимит вашего диска. Однако стоит понимать, все шарды будут участвовать в поиске и если мы будем искать по сотне пустых, потратим время впустую. Если шарды будут слишком большими мы так же будем тратить лишнее время на поиск, а так же операций перемещения и индексации станут очень тяжелыми.

Забегая вперед. Со временем Elasticsearch двигает и изменяет шарды, объединяя дробные и мелкие в большие. Следите за размером ваших шардов, при достижении 10ГБ производительность значительно падает.

Кластер

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

Ранее мы решили, что за операции поиска и индексации отвечает отдельный инстанс Lucene(шард). Для того, чтобы обращаться к распределенной системе шардов, нам необходимо иметь некий координирующий узел, именно он будет принимать запросы и давать задания на запись или получение данных. То есть помимо хранения данных мы выделяем еще один вариант поведения программы — координирование.

Таким образом мы изначально ориентируемся на два вида узлов — CRUD-узлы и координирующие узлы. Назовем их data node и coordinating node. У нас есть куча машин объединенных в сеть и все это очень напоминает кластер.

Каждый запущенный экземпляр Elasticsearch является отдельным узлом(node). Cluster — это совокупность определенных нод. Когда вы запускаете один экземпляр ваш кластер будет состоять из одной ноды.

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

Каждый тип ответственности узлов налагает определенные системные требования. Очевидно, что data-ноды будут часто обращаться к диску и использовать значительные объемы памяти в процессе работы.

Мы так же можем утверждать, что не все данные будут запрашиваться одинаково часто. Данные постепенно «остывают» по мере снижения запросов. Мы можем назвать это жизненным циклом хранения данных. Хорошей идеей было бы держать хайповые публикации там, откуда их можно быстро достать, а забытые мемы 2007 можно положить подальше.

Начиная с версии 6.7 Elasticsearch предлагает механизм управления жизненным циклом. Для этого доступны три типа нод — hot, warm и cold.

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

Именно такой механизм поможет нам выполнять операции с шардами. Координирующий узел получит запрос, предварительно переформулирует его для внутрикластерного взаимодействия и выполнит запросы к нашим worker-нодам(в данном случае к data-нодам).

Следовательно, coordinating-ноды должны иметь достаточный ресурс памяти, ЦП и быструю сеть, но при этом могут иметь скромный диск, ведь не осуществляют хранения данных.

Однако при большой частоте запросов, такие ноды могут стать узким местом системы. Мы можем пойти привычным путем и превратить точку внешнего доступа в плоскость. Пусть координирующих нод будет множество.

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

Управление кластером

На данном этапе мы имеем возможность доступа к данным из множества точек — coordinating-нод. В этом нет проблем, если мы говорим о простых операциях чтения/записи в существующий индекс. Но если говорить о выделении новых шардов или их перемещении, может начаться путаница.

Предположим, возможность coordinating-нодам управления состоянием кластера. Один узел примет решение о перемещении шарда на одну data-ноду, а второй о перемещении того же на другую. Список возможных общекластерных действий может быть довольно широким, а список возможных конфликтов еще шире.

Очевидно такие важные решения должен принимать один центральный узел. Мы определили, что для каждого типа действий необходимо выделять отдельную роль, чтобы избежать потерь производительности на ноде. И «главный в кластере» звучит как отдельная ответственность.

Назовем такие ноды master-node. Активный мастер всегда должен быть один, он будет управлять топологией кластера: создавать новый индекс, выделять и распределять шарды, перемещать их и объединять в случае необходимости. Мастер всегда знает все о состоянии кластера.

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

Репликация данных

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

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

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

Таким образом мы всегда имеем реплики всех шардов и не поднимаем неэффективно простаивающие ноды.

Основной шард назовем первичным или primary shard, а любую из его копий реплицирующим шардом или replica shard, первичный шард и его реплики это группа репликации.

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

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

Отказоустойчивость

Сейчас данные будут доступны даже в случае сбоя одного из хранящих узлов. Но что если кластер потеряет мастера? Потеря единственного мастера равноценна потере кластера.

Тут все по привычной схеме — поднимаем несколько мастеров.

Но если у нас есть, например, два управляющих узла, как понять, какой из них в данный момент должен управлять кластером? Как они смогут договориться о своих решениях? Очевидно, что в каждый момент времени должен быть только один управляющий кластером узел.

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

Представим. Главный управляющий узел стал недоступен для кластера, кластер берет первого кандидата и устанавливает его на вакантное место. Спустя определенное время первый мастер возвращается в кластер и ничего не знает о том, что его место уже занято. Мастер-ноды являются своего рода его мозгом, и теперь мозг кластера становится разделен. Это классическая проблема распределенных систем и она так и называется split-brain problem.

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

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

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

Теперь важно понять когда можно считать, что голосование прошло успешно? Если проголосовали все участники? Или половина? Или другое любое другое магическое количество?

Решение этой проблемы заключается в определении кворума. Это умное название для контрольного количества голосующих.

Очевидно, что такое важное решение как выбор мастера должно приниматься на основе большинства, то есть 50%+один голос. Справедливо, надежно. Это значение и станет кворумом.

Таким образом, количество кандидатов на мастера должно быть нечетным и не меньше трех. Рекомендуется использовать простую формулу для расчета оптимально количества таких нод:
КОЛИЧЕСТВО_КАНДИДАТОВ = ОБЩЕЕ_КОЛИЧЕСТВО_НОД/2 + 1

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

Elasticsearch автоматически изменяет конфигурацию голосования при изменении кластера. Поэтому нельзя одновременно отключать половину или более голосующих нод. Например, если в вашей конфигурации в данный момент 7 голосующих нод и вы отключили сразу 4, кластер станет недоступным, потому что останется 3 ноды, а в конфигурации голосования кворумом является значение 4.

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

Транспорт

Пришло время поговорить о том, как общаться с кластером из внешних систем, и как будут общаться узлы внутри кластера. Есть ряд плюсов и минусов использования и традиционных, и специальных протоколов. Для краткого сравнения существует таблица.

Для внутренней коммуникации в кластере Elsaticsearch использует нативный протокол.

Заключение

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

Я постарался кратко и последовательно рассказать о том, как и почему именно так это устроено. В этой статье я намеренно не стал упоминать об экосистеме Elastic, плагинах, запросах, токенизации, маппинге и остальном. Так же я не сказал об Ingest и machine learning нодах, на мой взгляд, они дают дополнительные возможности и не являются базовыми.

Дополнительные материалы

Книга Elasticsearch 5.x Cookbook, Third Edition

Источник