Добрый день. Меня зовут Роман Ларчиков, я инженер по технической поддержке Docsvision. Данная статья подготовлена для тех, кого интересуют технические детали реализации масштабирования поиска и знакомство с работой Elasticsearch. В статье пойдёт рассказ о причинах использования ES, требованиях к системе, а также о преимуществах над поиском от MS SQL Server.
Если вам интересно в более общих чертах узнать о том, как мы масштабировали поиск в последней версии нашей платформы – об этом рассказывали мои коллеги на вебинаре «Docsvision ECM. Масштабирование поиска ElasticSearch».
Для начала, стоит отметить, что версия платформы Docsvision 5.5 принципиально отличается от предыдущих своей модульной архитектурой. В связи с этим нам необходимо было обеспечить возможность практически неограниченного масштабирования системы с сохранением скорости работы. В частности, требовалось получить возможность масштабирования сервиса индексации и при высокой скорости его работы.
В этой связи в версии Docsvision 5.5 появилась возможность использования внешних (сателлитных) баз данных. Теперь нет необходимости все данные хранить в рамках одной БД, которая при интенсивной работе ежедневно разрастается в объемах, что затрудняет процесс обслуживания БД, оперативность ее восстановления при падениях и замедляет в целом работу самой БД.
Использование одной БД для всего – плохо. Реализованная в Docsvision 5.5 возможность выноса данных в отдельные внешние БД позволяет правильно реструктурировать базу данных. Таким образом, если говорить о поиске, то данные индексации можно будет хранить уже за пределами основной БД, исключив влияние на её размер.
Удобство настройки, гибкость, надежность, масштабируемость, скорость индексирования и поиска в режиме онлайн – это всё про Elasticsearch.
Elasticsearch прекрасно ориентирован на работу с документами. После индексации мы можем выполнять поиск, сортировать, фильтровать данные, а не строки данных в столбцах. Что, в свою очередь, демонстрирует иной подход к поиску данных, и указывает на то, что Elasticsearch может выполнять сложный полнотекстовый поиск.
Документы представлены в виде объектов JSON. При этом сериализация (процесс перевода какой-либо структуры данных в последовательность бит) JSON поддерживается большинством языков программирования и является уже стандартным форматом для NoSQL.
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).
В Docsvision 5.5 есть возможность выбора, с каким поисковым движком работать. В этой статье сделаю акцент на использовании поискового движка Elasticsearch и расскажу о его преимуществах над поиском от MS SQL Server.
Основные преимущества:
ES можно развернуть не только на высокопроизводительных серверах, но и на ноутбуке. Но если речь идет о продуктивной среде, то стоит использовать отдельный сервер и придерживаться некоторых рекомендаций, которые стоит учесть.
Наиболее критичным ресурсом для ES является оперативная память. Это первостепенный ресурс, который вероятнее всего закончится первым. Минимальный допустимый размер — 8Gb, рекомендуемый — от 16 до 64 Gb. Допускается больше, если в этом действительно есть необходимость.
Сортировка и агрегация могут потреблять большое количество памяти, поэтому важно иметь достаточный её запас. Машина с 64 ГБ оперативной памяти — идеальное решение, но машины с 32 ГБ и 16 ГБ также распространены. Если на машине установлено 8 Гб и менее, это может привести к обратным результатам (в конечном итоге вам может потребоваться несколько таких «маленьких» машин). Использование более 64 Гб тоже имеет свои особенности.
ES, как правило, не имеет больших требований к процессору, поэтому его выбор имеет меньшее значение, чем другие ресурсы.
Но стоит придерживаться правила. Выбирать стоит современный процессор с несколькими ядрами. Как правило, сервера в кластере используют двух-восьмиядерные машины.
Если стоит выбор между более быстрыми процессорами или процессорами с несколькими ядрами, стоит выбирать последние. Дополнительный параллелизм, предлагаемый несколькими ядрами, даст больший результат, нежели чуть более высокая тактовая частота.
Диск – также важный ресурс для быстрой работы ES. Он важен при использовании кластера и вдвойне важен для кластеров с большими объёмами индексируемых данных.
Диски являются самой медленной подсистемой на сервере, а это означает, что кластеры с интенсивной записью могут оказывать высокую нагрузку на диски, что, в свою очередь, становится узким местом сервера. Если имеется возможность использовать твердотельные накопители, то необходимо использовать именно их, т.к. они намного превосходят любые вращающиеся носители. Узлы с SSD-поддержкой имеют заметное повышение производительности как запросов, так и индексации.
Если предполагается использование жестких дисков (HDD), то желательно использовать высокопроизводительные серверные диски (диски со скоростью вращения шпинделя 15000 об/мин).
Использование RAID 0 — эффективный способ увеличения скорости диска как для вращающихся дисков, так и для SSD. Нет необходимости использовать варианты RAID с зеркальным отображением или контролем четности, поскольку высокая доступность встроена в ES через реплики.
Если используются твердотельные накопители, то стоит убедиться, что планировщик ввода-вывода операционной системы настроен правильно. Когда происходит запись данных на диск, планировщик ввода/вывода решает, когда эти данные действительно отправляются на диск. В большинстве случаев по умолчанию используется планировщик cfq (полностью честная очередь).
Этот планировщик распределяет временные интервалы для каждого процесса, а затем оптимизирует доставку этих различных очередей на диск. Он оптимизирован для работы с HDD: характер вращающихся пластин означает, что более эффективно записывать данные на диск в зависимости от физического расположения.
Однако это неэффективно для твердотельных накопителей, поскольку в них не используются вращающиеся пластины. Вместо этого следует использовать крайний срок или noop. Планировщик крайнего срока оптимизирует в зависимости от того, как долго ожидали записи, тогда как noop — это просто простая очередь FIFO.
Эти простые изменения могут существенно улучшить пропускную способность при записи с помощью правильного планировщика.
Быстрая и надежная сеть важна для производительности в распределенной системе. Низкая задержка гарантирует, что узлы могут легко обмениваться данными, а высокая пропускная способность помогает перемещать и восстанавливать данные.
Современные сети центров обработки данных (1 GbE, 10 GbE) достаточны для подавляющего большинства кластеров.
Стоит избегать кластеров, кот��рые охватывают несколько центров обработки данных, даже если центры обработки данных расположены в непосредственной близости. Определенно избегайте кластеров, которые охватывают большие географические расстояния.
Кластеры ES предполагают, что все узлы равны. Большие задержки, как правило, усугубляют проблемы в распределенных системах и затрудняют отладку и разрешение.
Стоит отдавать предпочтение «средним» и «большим» машинам, избегая низкопроизводительных машин, чтобы исключить издержки простого запуска ES. В то же время стоит избегать по-настоящему огромных машин: они часто приводят к несбалансированному использованию ресурсов (например, используется вся память, но не центральный процессор) и могут добавить логистическую сложность, если необходимо запустить несколько узлов на машину.
После того как мы выяснили, что такое Elasticsearch, его ключевые преимущества и требования для установки, можно приступать к самой установке ES для последующего конфигурирования в Docsvision.
О том как его установить и выполнить конфигурацию, а также проверить индексацию, т.е. работоспособность в Docsvision, читайте публикацию моего коллеги здесь.
Интересна тема? Тогда можно воспользоваться этой ссылкой и узнать ещё больше! А здесь можно зарегистрироваться на курсы.
Если вам интересно в более общих чертах узнать о том, как мы масштабировали поиск в последней версии нашей платформы – об этом рассказывали мои коллеги на вебинаре «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.
Основные преимущества:
- Возможность сервиса индексации получать доступ к внешним хранилищам данным. При этом данные корректно индексируются и корректно выводятся при поиске. При использовании поискового движка SQL Server была возможность искать только по тем данным, которые хранятся в основной БД.
- ES — это opensource проект, и многие мировые компании его используют для поиска по огромным массивам данных.
- ES позволяет оперировать петабайтами данных, обрабатывая десятки миллиардов документов в индексах, при этом показывая высокую скорость.
- При росте объема данных можно провести масштабирование (кластеризацию). В отличие от ES, полнотекстовый движок SQL Server не имеет возможности масштабирования.
- ES по сути — это большая БД, где с помощью запросов мы получаем данные.
- ES умеет работать с разными запросами (простые, сложные, структурированные), с различными типами данных.
- Умеет делать агрегацию, проводить анализ, собрать сущности, закономерности и упростить поиск.
- Также к преимуществам ES можно отнести скорость поиска и быструю выдачу результатов. По индексам происходит быстрая выборка данных из базы и показ результата поиска.
- Высокая отказоустойчивость. Имеется механизм обнаружения проблем, позволяет найти проблемы в кластере, локализовать их, что, в свою очередь, обеспечивает высокую отказоустойчивость.
- Умеет работать с различными данными, будь то числа, текст, геоданные, структурированные и неструктурированные данные.
- ES легко разворачивается (более подробно ниже). С точки зрения Docsvision, поиск ES настраивается быстрее, чем поиск от SQL сервера.
- Скорость индексирования данных — большое преимущество над поиском SQL. Как только мы добавляем новую карточку, она сразу попадает в очередь на индексирование, и сервис работает в режиме онлайн, с небольшим периодом индексации. При использовании полнотекстового поиска мы могли задать периодичность индексирования или выполнять индексацию вручную, т.е. приходилось добавлять карточку, затем ждать момент индексации. Как правило, в крупных компаниях индексация настроена ежедневно на нерабочее время, т.е. информация в индексах появлялась только на следующий день. При использовании ES результат получаем практически сразу.
- БД не увеличивается в размерах при добавлении языков. В отличие от ES, при использовании полнотекстового поиска в MS SQL проиндексированные данные увеличивают размер основной базы данных, особенно если индексирование настроено на разные языки, к примеру, на русский/нейтральный/английский. В таком случае, рост таблиц индексирования увеличивается уже в несколько раз, нежели был бы выбран только один язык для индексирования, к примеру, нейтральный.
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, читайте публикацию моего коллеги здесь.
Интересна тема? Тогда можно воспользоваться этой ссылкой и узнать ещё больше! А здесь можно зарегистрироваться на курсы.
