Быстрый полнотекстовый поиск 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 — хороший выбор для сбора и анализа данных среднего объёма
Рассказывает Франсуа Руа, руководитель отдела разработки ГК «Авилекс»
Контекст задачи
Когда ваш бизнес предполагает анализ статистических данных, поступающих из разных источников, вам требуется эти данные собирать, хранить, индексировать, трансформировать в другие данные, анализировать и т. д.
Часто бывает так, что масштаб проекта ещё недостаточно велик для внедрения крупных программных платформ наподобие 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 избыточны.
Поиск по вашему сайту, как в Яндексе или 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 также анализирует и сохраняет все данные. Как это происходит?
Основой для работы с текстовыми документами является анализатор. Он представляет собой цепочкупоследовательных обработчиков.
Изучаем ELK. Часть I — Установка Elasticsearch
Вступительное слово
Эта статья является первой в серии статей по стеку Elasticsearch, Logstash, Kibana (ELK). Цикл статей ориентирован на тех, кто только начинает знакомится со стеком ELK, и содержит минимально необходимый набор знаний, чтобы успешно запустить свой первый кластер ELK.
В рамках данного цикла будут рассмотрены такие темы, как:
установка и настройка компонентов ELK,
безопасность кластера, репликация данных и шардирование,
конфигурирование Logstash и Beat для сборки и отправки данных в Elasticsearch,
визуализация в Kibana
запуск стека в Docker.
В данной статье будет рассмотрена процедура установки Elasticsearch и конфигурирование кластера.
План действий:
Скачиваем и устанавливаем Elasticsearch.
Запускаем и проверяем работоспособность кластера.
Делаем важные настройки.
Скачиваем и устанавливаем Elasticsearch
Существует множество вариантов установки Elasticsearch, под любые нужды и желания. С перечнем можно ознакомится на официальном сайте. Не смотря на то, что на своем стенде я использовал установку из Deb пакетов, считаю правильным так же описать установку из RPM пакетов и архива tar.gz для Linux системы.
Установка из Deb пакетов
Импортируем Elasticsearch PGP ключ:
Устанавливаем apt-transport-https пакет:
Перед установкой пакета необходимо добавить репозиторий Elastic:
Устанавливаем Elasticsearch из пакета:
Настраиваем Elasticsearch для автоматического запуска при запуске системы:
Установка из RPM пакетов
Импортируем Elasticsearch PGP ключ:
В директории /etc/yum.repos.d/ создаем файл репозитория Elasticsearch elasticsearch.repo :
Установка из архива tar.gz
Скачиваем архив с Elasticsearch
Извлекаем данные из архива и переходим в каталог с Elasticsearch:
На этом шаге установка из архива считается завершенной.
Для запуска Elasticsearch можно создать отдельного пользователя, предоставив все необходимые права к каталогу с Elasticsearch и указывая данного пользователя при настройке файловых дескрипторов.
Настраиваем кластер
На текущем этапе у нас есть три хоста с установленным Elasticsearch. Следующим и самым важным этапом является настройка каждого узла для объединения их в единый кластер.
Ниже будут приведены пример конфигурации для узла es-node01. Аналогичные настройки необходимо сделать на каждом узле, указав соответствующие имя и адрес.
Указываем имя узла и определяем роли. Укажем для узла роли master и data :
master Данная роль дает возможность узлу быть избранным, как управляющий узел кластера
data узел с данной ролью содержит данные и выполняет операции с этими данными
Со списком всех ролей узла можно ознакомится тут.
Настраиваем адрес и порт, на которых узел будет принимать запросы:
Определяем имя кластера и начальный список узлов в голосовании по выбору master узла:
При начальной загрузке кластера определяются узлы, участвующие в голосовании по выбору мастера, поэтому в новом кластере мы должны указать перечень этих узлов. Если данный параметр оставить пустым (по умолчанию), то узел будет ожидать подключения к уже созданному кластеру.
Данный параметр следует удалить после создания кластера и не использовать при добавлении новых узлов в существующий кластер.
Указываем список master узлов кластера:
Определяем, где будем хранить данные и логи
На выходе мы должны получить следующий конфигурационный файл:
При необходимости настраиваем межсетевой экран на хосте:
Запускаем и проверяем
Запускаем на каждом узле службу elasticsearch :
Для установки из архива используем:
или если мы хотим запустить Elasticsearch как демон, то:
После запуска первого узла в логах можно увидеть, что узел ожидает подключение других узлов, чтобы определить, кто возьмет роль master :
После включения остальных узлов в логах появится запись о том, что кластер собрался:
Проверяем состояние кластера, обратившись к любому его узлу:
Делаем важные настройки
Для нормальной работы кластера необходимо произвести еще некоторые настройки.
Heap size
Отключаем подкачку
Подкачка негативно сказывается на производительности и стабильности работы Elasticsearch, ведь система может выгрузить страницы JVM на диск. Есть несколько вариантов работы с подкачкой:
Полное отключение подкачки. Перезапуск Elasticseach при этом не требуется.
Использование mlockall для блокировки адресного пространства в оперативной памяти.
Перезапускаем Elasticsearch и проверяем настройки через запрос к любому узлу:
Если перезапуск Elasticsearch завершился ошибкой вида:
или проверка показывает, что данная настройка не применилась, необходимо сделать следующее в зависимости от способа установки:
Установка из архива
Установка из пакета RPM или Deb
и укажите следующее значение:
Настройка файловых дескрипторов
Elasticsearch работает с большим количеством файловых дескрипторов, и их нехватка может катастрофически сказаться на его работе. Согласно официальной документации необходимо указать значение файловых дескрипторов не ниже 65 536.
Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.
Для установки из архива необходимо в файле /etc/security/limits.conf установить параметр nofile для пользователя, который осуществляет запуск Elasticsearch. В примере ниже таким пользователем является elasticsearch :
Проверить установленные значения можно следующим образом:
Настройка виртуальной памяти
Elasticsearch по умолчанию использует каталог mmapfs для хранения индексов, и ограничение операционной системы по умолчанию для счетчиков mmap может привести к нехватки памяти. Для настройки запустите из-под root следующую команду:
Если Elasticsearch установлен из RPM или Deb пакетов, то настройка не требуется.
Настройка потоков
Необходимо убедиться, что количество потоков, которые Elasticsearch может создавать, было не менее 4096.
DNS кеширование
Временный каталог для JNA
На этом шаге дополнительные настройки Elasticsearch окончены.
Заключение
Дойдя до этого места, вы должны иметь работоспособный кластер Elasticsearch.
В следующей статье будут описаны процедуры установки и настройки Kibana и Logstash. А в качестве проверки работоспособности кластера соберём данные из файла и посмотрим на них с помощью Kibana.
Масштабирование поиска. Elasticsearch. Его преимущества и основные требования для установки
Добрый день. Меня зовут Роман Ларчиков, я инженер по технической поддержке Docsvision. Данная статья подготовлена для тех, кого интересуют технические детали реализации масштабирования поиска и знакомство с работой Elasticsearch. В статье пойдёт рассказ о причинах использования ES, требованиях к системе, а также о преимуществах над поиском от MS SQL Server.
Если вам интересно в более общих чертах узнать о том, как мы масштабировали поиск в последней версии нашей платформы – об этом рассказывали мои коллеги на вебинаре «Docsvision ECM. Масштабирование поиска ElasticSearch».
Почему Elasticsearch?
Для начала, стоит отметить, что версия платформы Docsvision 5.5 принципиально отличается от предыдущих своей модульной архитектурой. В связи с этим нам необходимо было обеспечить возможность практически неограниченного масштабирования системы с сохранением скорости работы. В частности, требовалось получить возможность масштабирования сервиса индексации и при высокой скорости его работы.
В этой связи в версии Docsvision 5.5 появилась возможность использования внешних (сателлитных) баз данных. Теперь нет необходимости все данные хранить в рамках одной БД, которая при интенсивной работе ежедневно разрастается в объемах, что затрудняет процесс обслуживания БД, оперативность ее восстановления при падениях и замедляет в целом работу самой БД.
Использование одной БД для всего – плохо. Реализованная в Docsvision 5.5 возможность выноса данных в отдельные внешние БД позволяет правильно реструктурировать базу данных. Таким образом, если говорить о поиске, то данные индексации можно будет хранить уже за пределами основной БД, исключив влияние на её размер.
Удобство настройки, гибкость, надежность, масштабируемость, скорость индексирования и поиска в режиме онлайн – это всё про Elasticsearch.
Elasticsearch прекрасно ориентирован на работу с документами. После индексации мы можем выполнять поиск, сортировать, фильтровать данные, а не строки данных в столбцах. Что, в свою очередь, демонстрирует иной подход к поиску данных, и указывает на то, что Elasticsearch может выполнять сложный полнотекстовый поиск.
Документы представлены в виде объектов JSON. При этом сериализация (процесс перевода какой-либо структуры данных в последовательность бит) JSON поддерживается большинством языков программирования и является уже стандартным форматом для NoSQL.
1. Знакомство с Elasticsearch
1.1. Что это такое?
Elasticsearch — это масштабируемый полнотекстовый поисковый движок с открытым исходным кодом, использующий библиотеку Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте.
Он предназначен для сложных поисков по базе документов/файлов. В базе данных Elasticsearch таблицы называются индексами, а процесс загрузки документов — индексированием.
Можно его считать и не реляционным хранилищем документов в формате JSON, и поисковой системой на базе полнотекстового поиска Lucene. Официальные клиенты доступны на Java, NET (C#), Python, Groovy, JavaScript, PHP, Perl, Ruby.
ES разрабатывается компанией Elastic вместе со связанными проектами, называемыми Elastic Stack — Elasticsearch, Logstash, Beats и Kibana.
За хранение и поиск данных отвечает Elasticsearch (далее для краткости в статье будем называть его ES).
1.2. Преимущества поискового движка Elasticsearch в сравнении с поисковым движком MS SQL
В Docsvision 5.5 есть возможность выбора, с каким поисковым движком работать. В этой статье сделаю акцент на использовании поискового движка Elasticsearch и расскажу о его преимуществах над поиском от MS SQL Server.
2. Требуемое ПО и системные требования для установки Elasticsearch
ES можно развернуть не только на высокопроизводительных серверах, но и на ноутбуке. Но если речь идет о продуктивной среде, то стоит использовать отдельный сервер и придерживаться некоторых рекомендаций, которые стоит учесть.
2.1. Оперативная память
Наиболее критичным ресурсом для ES является оперативная память. Это первостепенный ресурс, который вероятнее всего закончится первым. Минимальный допустимый размер — 8Gb, рекомендуемый — от 16 до 64 Gb. Допускается больше, если в этом действительно есть необходимость.
Сортировка и агрегация могут потреблять большое количество памяти, поэтому важно иметь достаточный её запас. Машина с 64 ГБ оперативной памяти — идеальное решение, но машины с 32 ГБ и 16 ГБ также распространены. Если на машине установлено 8 Гб и менее, это может привести к обратным результатам (в конечном итоге вам может потребоваться несколько таких «маленьких» машин). Использование более 64 Гб тоже имеет свои особенности.
2.2. Процессор
ES, как правило, не имеет больших требований к процессору, поэтому его выбор имеет меньшее значение, чем другие ресурсы.
Но стоит придерживаться правила. Выбирать стоит современный процессор с несколькими ядрами. Как правило, сервера в кластере используют двух-восьмиядерные машины.
Если стоит выбор между более быстрыми процессорами или процессорами с несколькими ядрами, стоит выбирать последние. Дополнительный параллелизм, предлагаемый несколькими ядрами, даст больший результат, нежели чуть более высокая тактовая частота.
2.3. Диск
Диск – также важный ресурс для быстрой работы ES. Он важен при использовании кластера и вдвойне важен для кластеров с большими объёмами индексируемых данных.
Диски являются самой медленной подсистемой на сервере, а это означает, что кластеры с интенсивной записью могут оказывать высокую нагрузку на диски, что, в свою очередь, становится узким местом сервера. Если имеется возможность использовать твердотельные накопители, то необходимо использовать именно их, т.к. они намного превосходят любые вращающиеся носители. Узлы с SSD-поддержкой имеют заметное повышение производительности как запросов, так и индексации.
Если предполагается использование жестких дисков (HDD), то желательно использовать высокопроизводительные серверные диски (диски со скоростью вращения шпинделя 15000 об/мин).
Использование RAID 0 — эффективный способ увеличения скорости диска как для вращающихся дисков, так и для SSD. Нет необходимости использовать варианты RAID с зеркальным отображением или контролем четности, поскольку высокая доступность встроена в ES через реплики.
2.4. Планировщик ввода/вывода
Если используются твердотельные накопители, то стоит убедиться, что планировщик ввода-вывода операционной системы настроен правильно. Когда происходит запись данных на диск, планировщик ввода/вывода решает, когда эти данные действительно отправляются на диск. В большинстве случаев по умолчанию используется планировщик cfq (полностью честная очередь).
Этот планировщик распределяет временные интервалы для каждого процесса, а затем оптимизирует доставку этих различных очередей на диск. Он оптимизирован для работы с HDD: характер вращающихся пластин означает, что более эффективно записывать данные на диск в зависимости от физического расположения.
Однако это неэффективно для твердотельных накопителей, поскольку в них не используются вращающиеся пластины. Вместо этого следует использовать крайний срок или noop. Планировщик крайнего срока оптимизирует в зависимости от того, как долго ожидали записи, тогда как noop — это просто простая очередь FIFO.
Эти простые изменения могут существенно улучшить пропускную способность при записи с помощью правильного планировщика.
2.5. Сеть
Быстрая и надежная сеть важна для производительности в распределенной системе. Низкая задержка гарантирует, что узлы могут легко обмениваться данными, а высокая пропускная способность помогает перемещать и восстанавливать данные.
Современные сети центров обработки данных (1 GbE, 10 GbE) достаточны для подавляющего большинства кластеров.
Стоит избегать кластеров, которые охватывают несколько центров обработки данных, даже если центры обработки данных расположены в непосредственной близости. Определенно избегайте кластеров, которые охватывают большие географические расстояния.
Кластеры ES предполагают, что все узлы равны. Большие задержки, как правило, усугубляют проблемы в распределенных системах и затрудняют отладку и разрешение.
2.6. Общие рекомендации
Стоит отдавать предпочтение «средним» и «большим» машинам, избегая низкопроизводительных машин, чтобы исключить издержки простого запуска ES. В то же время стоит избегать по-настоящему огромных машин: они часто приводят к несбалансированному использованию ресурсов (например, используется вся память, но не центральный процессор) и могут добавить логистическую сложность, если необходимо запустить несколько узлов на машину.
3. Заключение
После того как мы выяснили, что такое Elasticsearch, его ключевые преимущества и требования для установки, можно приступать к самой установке ES для последующего конфигурирования в Docsvision.
О том как его установить и выполнить конфигурацию, а также проверить индексацию, т.е. работоспособность в Docsvision, читайте публикацию моего коллеги здесь.
Интересна тема? Тогда можно воспользоваться этой ссылкой и узнать ещё больше! А здесь можно зарегистрироваться на курсы.
