Как настроить количество осколков на кластер в elasticsearch

Я не понимаю конфигурацию осколков в ES. У меня есть несколько вопросов о шранге в ES:

  • Количество первичных осколков настраивается с помощью параметра index.number_of_shards, правильно?

    Таким образом, это означает, что количество осколков настроено для каждого индекса. Если это так, если у меня есть 2 индекса, то у меня будет 10 осколков на node?

  • Предполагая, что у меня есть один node (Node 1), который настроен с тремя осколками и 1 репликой. Затем я создаю новый node (Node 2) в том же кластере с двумя осколками. Итак, я предполагаю, что у меня будет реплика только на два осколка, верно?

    Кроме того, что происходит в случае, если node 1 не работает, как кластер "знает", что он должен иметь 3 осколка вместо 2? Поскольку у меня есть только 2 осколка на node 2, это означает, что я потерял данные одного из осколков в node 1?

3 ответа

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

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/glossary.html

Это довольно хорошее описание:

2.3 Основы индексов

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

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

Индексы в elasticsearch не являются 1:1 сопоставлениями с индексами Lucene, они на самом деле оговорены через настраиваемое количество индексов Lucene, 5 по умолчанию, с 1 репликой на каждый осколок. Одна машина может иметь большее или меньшее количество осколков для данного индекса, чем другое машин в кластере. Elasticsearch пытается сохранить общие данные по всем показателям, равным на всех машинах, даже если это означает что некоторые индексы могут быть непропорционально представлены на заданном машина. Каждый осколок имеет настраиваемое количество полных реплик, которые всегда хранятся в уникальных экземплярах. Если кластер не большой достаточно для поддержки указанного количества реплик кластеров здоровье будет сообщаться как ухудшенное "желтое состояние". Основной разработчик следовательно, всегда полагает, что его работая в деградированном состоянии, учитывая, что по умолчанию индексы, один у исполняемого экземпляра нет сверстников для репликации его данных. Обратите внимание, что это не оказывает практического влияния на его эксплуатацию в целях развития. Это однако рекомендуется, чтобы elasticsearch всегда выполнялся на нескольких серверов в производственных средах. Как кластерная база данных, многие из данные гарантируют шарнир на нескольких доступных узлах.

Отсюда: http://exploringelasticsearch.com/modeling_data.html#sec-modeling-index-basics

Когда вы создаете индекс, вы указываете, сколько первичных и реплик осколков http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-create-index.html. ES по умолчанию имеет 5 первичных осколков и 1 осколок реплики на первичный, в общей сложности 10 осколков.

Эти осколки будут сбалансированы по количеству узлов, которые у вас есть в кластере, при условии, что первичная и их реплика не могут находиться на одном и том же node. Поэтому, если вы начинаете с 2-х узлов и по умолчанию 5 первичных осколков и 1 реплика на основной, вы получите 5 осколков за node. Добавьте больше узлов и количество осколков на node капли. Добавьте больше индексов и количество обрывов на node увеличивается.

Во всех случаях количество узлов должно быть на 1 больше настроенного количества реплик. Поэтому, если вы настроите 1 реплика, у вас должно быть 2 узла, чтобы первичный мог находиться на одном и на одной реплике на другом, иначе реплики не будут назначены, а статус вашего кластера будет желтым. Если у вас он настроен на 2 реплики, что означает 1 первичный осколок и 2 черепа реплик, вам нужно как минимум 3 узла, чтобы держать их в отдельности. И так далее.

На ваши вопросы нельзя ответить напрямую, потому что они основаны на неправильных предположениях о том, как работает ES. Вы не добавляете node с осколками - вы добавляете node, а затем ES перебалансирует существующие осколки во всем кластере. Да, у вас есть некоторый контроль над этим, если вы хотите, но я бы не сделал этого, пока вы не узнаете больше о действиях ES. Я прочитал здесь: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-allocation.html и здесь: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-reroute.html и здесь: http://exploringelasticsearch.com/advanced_techniques.html#advanced-routing

Из последней ссылки:

8.1.1 Как работает маршрутизация Elasticsearch

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

Основной механизм, с помощью которого масштабируются шкалы elasticsearch. Sharding - общий метод разделения данных и вычислений на нескольких серверах, где свойство документа имеет функцию возвращая неизменное значение, применяемое к нему, чтобы определить, какие сервер будет сохранен. Значение, используемое для этого в elasticsearch это поле документов _id по умолчанию. Алгоритм, используемый для преобразования значение идентификатора осколка - это то, что известно как последовательное хеширование алгоритм.

Поддержание хорошей производительности кластера зависит от даже осколка балансировка. Если данные распределены неравномерно по кластеру машины будут чрезмерно утилизированы, а другие останутся в основном бездействующими. Чтобы этого избежать, мы хотим, чтобы даже распределение чисел, выходящих из наш согласованный алгоритм хэширования. Идентификаторы документов обычно потому, что они распределены равномерно, если они являются либо UUID или монотонно увеличивающихся ids (1,2,3,4...).

Это подход по умолчанию, и он обычно работает хорошо, поскольку он решает проблема выравнивания данных по кластеру. Это также означает, что выборки для одного документа нужно только направлять в осколок, который хэши документа. Но как насчет запросов на маршрутизацию? Если, например, мы сохраняем историю пользователей в elasticsearch и используем UUID для каждая часть данных истории пользователя, данные пользователя будут храниться равномерно через кластер. Тем не менее, здесь есть некоторые отходы, поскольку это означает, что наши поиски данных пользователей имеют плохую локальность данных. Запросы должны выполняться на всех осколках внутри индекса и выполняться против всевозможные данные. Предполагая, что у нас есть много пользователей, мы можем повысить производительность запросов, последовательно прокладывая все данных пользователей до одного осколка. Как только данные пользователей будут так сегментированные, ну, только нужно выполнить через один осколок, когда выполняя операции с данными пользователей.


  • Да, количество осколков за один индекс. Итак, если у вас есть 2 индекса, каждый из которых имеет 5 осколков, то да, у вас будет всего 10 осколков, распределенных по всем вашим узлам.

  • Количество осколков не связано с количеством узлов в кластере. Если у вас есть 3 осколка и один node, очевидно, что все три осколка будут находиться на этом node. Однако, если вы затем добавите дополнительный node, больше не будет создано магическое создание, и вы не можете указать, что определенное количество осколков должно находиться на этом новом node. Скорее, существующие осколки распределяются как можно более равномерно по всем узлам, в результате чего один node имеет 2 осколка и один node с 1 осколком, в общей сложности 3. Если вы добавили третий node, то каждый node вмещает 1 осколок в общей сложности 3. Другими словами, количество осколков фиксировано и не масштабируется при добавлении большего количества узлов.

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


Ответ 1) да, у вас будет 10 осколков fr 2 с 5 осколками.

Ответ 2) Я думаю, вы путаете с осколками и индексом.

Осколки разделены куском для индекса не для node.

Если вы создаете индекс с тремя осколками и 1 репликой.

Вы получите 3 первичных осколка и 3 реплики.

Если вы начнете новый node, то осколки будут сбалансированы с новым node. Таким образом, у вас будет 3 осколка в старых node и 3 осколках в новом node.

Если старый node терпит неудачу, вы выживете с новыми данными node. Он будет иметь точную копию старого node.

Чтобы понять основные понятия elasticsearch обратитесь

HOpe помогает..!

licensed under cc by-sa 3.0 with attribution.