Осколки и реплики в Elasticsearch

Я пытаюсь понять, что такое осколок и реплика в Elasticsearch, но мне не удалось понять это. Если я загружаю Elasticsearch и запускаю скрипт, то из того, что я знаю, я запустил кластер с одним узлом. Теперь этот узел (мой компьютер) имеет 5 осколков (?) И несколько реплик (?).

Каковы они, у меня есть 5 дубликатов индекса? Если так, то почему? Мне может понадобиться какое-то объяснение.

Ответ 1

Я попытаюсь объяснить реальным примером, поскольку ответы и полученные ответы не помогают вам.

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

Когда вы создаете индекс (индекс создается автоматически и при индексировании первого документа), вы можете определить, из скольких фрагментов он будет составлен. Если вы не укажете число, у него будет количество шардов по умолчанию: 5 основных цветов. Что это значит?

Это означает, чтоasticsearch создаст 5 первичных осколков, которые будут содержать ваши данные:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

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

Узел 1 будет содержать, например, только три шарда:

 ____    ____    ____ 
| 1  |  | 2  |  | 3  |
|____|  |____|  |____|

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

 ____    ____
| 4  |  | 5  |
|____|  |____|

Почему это происходит? Посколькуasticsearch - это распределенная поисковая система, и таким образом вы можете использовать несколько узлов/машин для управления большими объемами данных.

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

Другой тип осколка - это копия. По умолчанию установлено значение 1, что означает, что каждый основной фрагмент будет скопирован в другой фрагмент, который будет содержать те же данные. Реплики используются для повышения производительности поиска и восстановления после отказа. Осколок реплики никогда не будет размещен на том же узле, где находится связанный первичный объект (это было бы почти как размещение резервной копии на том же диске, что и исходные данные).

Возвращаясь к нашему примеру, с 1 репликой у нас будет целый индекс на каждом узле, поскольку 3 сегмента реплики будут размещены на первом узле, и они будут содержать точно такие же данные, что и основные цвета на втором узле:

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4R |  | 5R |
|____|  |____|  |____|  |____|  |____|

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

 ____    ____    ____    ____    ____
| 1R |  | 2R |  | 3R |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

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

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

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

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

Надеюсь, это прояснит вам.

Ответ 2

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

Реплики являются копиями осколков и обеспечивают надежность, если потеряна node. Часто бывает замешательство в этом числе, потому что количество копий == 1 означает, что кластер должен иметь основную и реплицированную копию осколка, доступную для зеленого.

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

Здесь вы можете найти определения: http://www.elasticsearch.org/guide/reference/glossary/

С наилучшими пожеланиями, Пол

Ответ 3

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

curl -XPUT 'localhost:9200/_settings' -d '
{
    "index" : {
        "number_of_replicas" : 0
    }
}
'

Обратите внимание, что вы должны сделать это только в своем локальном окне разработки.

Ответ 4

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

Реплики - это копии осколков.

A node является запущенным экземпляром упругого поиска, который принадлежит кластеру.

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

Ответ 5

Осколок:

  1. Будучи распределенным поисковым сервером, ElasticSearch использует концепцию под названием Shard для распределения индексных документов по всем узлам.
  2. index потенциально может хранить большой объем данных, которые могут превышать аппаратные ограничения single node
  3. Например, один индекс из миллиарда документов занимает 1 ТБ дисковое пространство может не поместиться на диске одного узла или может быть слишком медленно обслуживать поисковые запросы от одного узла.
  4. Для решения этой проблемы Elasticsearch предоставляет возможность разделите ваш индекс на несколько частей под названием shards.
  5. Когда вы создаете индекс, вы можете просто определить число shards что ты хочешь.
  6. Documents хранятся в shards, а осколки выделяются для nodes в ваш cluster
  7. Когда ваш cluster растет или сжимается, Elasticsearch будет автоматически переносите осколки между nodes, чтобы cluster оставался сбалансированным.
  8. Осколок может быть primary shard или replica shard.
  9. Каждый документ в вашем индексе принадлежит single primary shard, поэтому количество основных осколков, которое у вас есть, определяет максимальное объем данных, который может содержать ваш индекс
  10. replica shard - это просто копия основного осколка.

Реплика:

  1. Replica shard является копией primary Shard, чтобы предотвратить потерю данных в случай аппаратного сбоя.
  2. Elasticsearch позволяет вам сделать одну или несколько копий ваших индексов осколки в так называемые осколки-реплики или replicas для краткости.
  3. index также может быть воспроизведен с нуля (т.е. без реплик) или более раз.
  4. number of shards и реплики могут быть определены для каждого индекса на время создания индекса.
  5. После того как индекс создан, вы можете в любое время динамически изменять количество реплик, но вы cannot change the number of shards после того, как-фактум.
  6. По умолчанию каждому индексу в Elasticsearch выделяется 5 основных шардов и 1 replica, что означает, что если у вас есть как минимум два узла в вашем кластере в вашем индексе будет 5 основных шардов и еще 5 осколки реплик (1 полная копия) в общей сложности 10 осколков в индекс.

Ответ 6

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

Следите за видео, которое объясняет суть ES https://www.youtube.com/watch?v=PpX7J-G2PEo

Статья о нескольких индексах или множественных осколках Упругий поиск, несколько индексов по сравнению с одним индексом и типами для разных наборов данных?

Ответ 7

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

Таким образом ,asticsearch разбивает документы в индексе по нескольким узлам в кластере. Каждый раздел документа называется осколком. Каждый узел, несущий осколок документа, будет иметь только подмножество документа. Предположим, у вас есть 100 товаров и 5 осколков, у каждого осколка будет 20 товаров. Это разделение данных делает поиск с малой задержкой возможным в эластичном поиске. поиск ведется параллельно на нескольких узлах. Результаты агрегируются и возвращаются. Однако осколки не обеспечивают отказоустойчивости. Это означает, что если какой-либо узел, содержащий осколок, не работает, состояние кластера становится желтым. Это означает, что некоторые данные недоступны.

Для повышения отказоустойчивости реплики входят в рисунок. По умолчанию упругий поиск создает одну реплику каждого осколка. Эти реплики всегда создаются на другом узле, где основной сегмент не находится. Поэтому для обеспечения отказоустойчивости системы вам может потребоваться увеличить количество узлов в кластере, и это также зависит от количества сегментов вашего индекса. Общая формула для расчета количества узлов, требуемого на основе реплик и сегментов, представляет собой "количество узлов = количество сегментов * (количество реплик + 1)". Стандартная практика заключается в том, чтобы иметь как минимум одну реплику для отказоустойчивости.

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

Вы можете настроить количество сегментов и реплик для своего индекса с помощью приведенной ниже команды.

curl -XPUT 'localhost:9200/sampleindex?pretty' -H 'Content-Type: application/json' -d ' { "settings":{ "number_of_shards":2, "number_of_replicas":1 } } '

Ответ 8

Elasticsearch великолепно масштабируется со всеми преимуществами его распределенной архитектуры. Это стало возможным благодаря шардингу. Теперь, прежде чем углубляться в это, давайте рассмотрим простой и очень распространенный вариант использования. Предположим, у вас есть индекс, который содержит огромное количество документов, и для простоты рассмотрим, что размер этого индекса равен 1 ТБ (т.е. сумма размеров каждого документа в этом индексе равна 1 ТБ).). Также предположим, что у вас есть два узла с 512 ГБ свободного места для хранения данных. Как ясно видно, весь наш индекс не может храниться ни в одном из двух доступных узлов, и, следовательно, нам необходимо распределить наш индекс по этим узлам.

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

Ответ 9

Не ответ, а еще одна ссылка для основных понятий на ElasticSearch, и я думаю, что они довольно понятны как дополнение к ответу @javanna.

Осколки

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

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

Осколок важен по двум основным причинам:

  • Это позволяет вам горизонтально разделять/масштабировать объем вашего контента.
  • Он позволяет вам распределять и распараллеливать операции между сегментами (возможно, на нескольких узлах), тем самым повышая производительность/пропускную способность.

Реплики

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

Репликация важна по двум основным причинам:

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