Шарды и реплики OpenSearch: Объяснения, оптимизация и многое другое

OpenSearch расширяет возможности Lucene, создавая на его основе распределенную систему, и при этом решает проблемы масштабируемости и отказоустойчивости. Он также предоставляет REST API на основе JSON, что делает взаимодействие с другими системами очень простым.

Распределенные системы, такие как OpenSearch, могут быть очень сложными, с множеством факторов, которые могут повлиять на их производительность и стабильность. Шарды и реплики - одни из самых фундаментальных понятий в OpenSearch, и понимание того, как они работают, позволит вам эффективно управлять кластером OpenSearch.

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

Понимание шардов

Данные в индексе OpenSearch могут вырасти до огромных размеров. Чтобы сделать его управляемым, он разделен на несколько шардов. Каждый шард OpenSearch представляет собой индекс Apache Lucene, причем каждый отдельный индекс Lucene содержит подмножество документов в индексе OpenSearch. Такое разделение индексов позволяет держать под контролем использование ресурсов. Индекс Apache Lucene имеет ограничение в 2 147 483 519 документов.

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

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

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

Идеальное количество шардов должно определяться в зависимости от объема данных в индексе. Как правило, оптимальный шард должен вмещать 30-50 ГБ данных. Например, если вы ожидаете, что за день накопится около 300 ГБ журналов приложений, то разумным будет иметь около 10 шардов в этом индексе.

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

• Initializing: Начальное состояние перед использованием шарда.
• Started (запущен): Состояние, в котором шард активен и может принимать запросы.
• Relocating: Состояние, возникающее при перемещении шардов на другой узел. Это может быть необходимо при определенных условиях, например, когда на узле, на котором они находятся, заканчивается дисковое пространство.
• Unassigned: Состояние шарда, который не удалось назначить. В этом случае указывается причина, например, если узел, на котором находится шард, больше не находится в кластере (NODE_LEFT) или из-за восстановления в закрытый индекс (EXISTING_INDEX_RESTORED).

Чтобы просмотреть все шарды, их состояния и другие метаданные, используйте следующий запрос:

Чтобы просмотреть шарды для определенного индекса, добавьте к URL название индекса, например

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

Понимание принципов работы реплик

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

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

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

Еще один фактор, который следует учитывать при работе с репликами, - это количество доступных узлов. Реплики всегда размещаются на разных узлах, отличных от основного шарда, поскольку две копии одних и тех же данных на одном узле не обеспечат никакой защиты в случае сбоя узла. В результате, чтобы система поддерживала n реплик, в кластере должно быть не менее n + 1 узлов. Например, если в системе два узла, а индекс настроен на шесть реплик, будет выделена только одна реплика. С другой стороны, система с семью узлами вполне способна обслуживать один первичный шард и шесть реплик.

Оптимизация шардов и реплик

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

Для разделения новых и старых индексов можно использовать API rollover index. Его можно настроить на автоматическое создание нового индекса при достижении определенного порога - размера индекса на диске, количества документов или возраста. Этот API также полезен для контроля размеров шардов. Поскольку количество шардов нельзя легко изменить после создания индекса, если не выполняются условия переноса, шарды будут продолжать накапливать данные.

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

Шарды и реплики как основа OpenSearch

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

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