Elasticsearch: Index vs Shard

Разберём на простом примере разницу между Индексом и Шардом в Elasticsearch.

Index — это логическая коллекция данных. Как папка с названием или база данных. Это то, с чем ты работаешь как пользователь.

Shard — это физический кусок этого индекса. Реальные файлы на диске, которые хранят часть данных.

Index состоит из shards. Один index разрезается на несколько шардов, которые распределяются по серверам (nodes).

---

Аналогия с книгой (самая простая)

Index = Книга целиком

Представьте энциклопедию “Животные мира” — это index. У неё есть название, тема, структура. Когда вы говорите “дай мне книгу про животных”, вы имеете в виду всю книгу целиком.

Shard = Том этой книги

Энциклопедия слишком толстая, чтобы уместиться в одну физическую книгу. Поэтому её разделили на тома:

• Том 1 (Shard 0): А-Г (от Аиста до Гориллы)
• Том 2 (Shard 1): Д-Л (от Дельфина до Лошади)
• Том 3 (Shard 2): М-Я (от Медведя до Ящерицы)

Каждый том — это shard. Это реальная физическая книга, которую можно взять в руки и положить на конкретную полку (сервер/node).

Node = Полка/Библиотека

А теперь представьте, что у вас три библиотеки (nodes) в разных городах:

• Библиотека в Москве (Node 1): хранит Том 1
• Библиотека в Питере (Node 2): хранит Том 2
• Библиотека в Казани (Node 3): хранит Том 3

Когда кто-то хочет найти информацию про “Жирафа”:

1. Запрос идёт во все три библиотеки одновременно (параллельный поиск)
2. Каждая библиотека ищет в своём томе
3. Библиотека в Питере находит “Жирафа” в своём томе (буква Ж → Том 2)
4. Результат возвращается пользователю

Вы, как пользователь, работаете с “Животными мира” (index) целиком, не думая о том, что физически это три тома в трёх городах.

---

Техническая картина

INDEX: "my-blog-posts"
│
├─── SHARD 0 (физические файлы на диске Node 1)
│    ├── Документы: 1, 4, 7, 10, 13...
│    └── ~333 MB данных
│
├─── SHARD 1 (физические файлы на диске Node 2)
│    ├── Документы: 2, 5, 8, 11, 14...
│    └── ~333 MB данных
│
└─── SHARD 2 (физические файлы на диске Node 3)
     ├── Документы: 3, 6, 9, 12, 15...
     └── ~333 MB данных
```

При запросе:

GET /my-blog-posts/_search
{
  "query": { "match": { "title": "Elasticsearch" } }
}

идёт обращение к INDEX (my-blog-posts).

Elasticsearch:

1. Отправляет запрос на все 3 шарда параллельно
2. Каждый шард ищет в своих документах
3. Результаты собираются и объединяются
4. Приходит единый ответ

Ключевые отличия index от shard

Практический пример: интернет-магазин

Index = “products”

У вас есть индекс со всеми товарами магазина:

PUT /products
{
  "settings": {
    "number_of_shards": 5
  }
}

Вы создали один index под названием “products”.

Но физически – это 5 shards

Elasticsearch автоматически разделил данные на 5 кусков:

products[0] → Node 1 (сервер в Москве)
├─ iPhone 15
├─ MacBook Air
└─ 10,000 других товаров

products[1] → Node 2 (сервер в Питере)
├─ Samsung Galaxy
├─ Dell XPS
└─ 10,000 других товаров

products[2] → Node 1 (сервер в Москве)
├─ Lenovo ThinkPad
└─ 10,000 других товаров

products[3] → Node 3 (сервер в Казани)
└─ 10,000 других товаров

products[4] → Node 2 (сервер в Питере)
└─ 10,000 других товаров

Важно: несколько шардов могут быть на одном node! Это нормально.

Поиск товара

Пользователь ищет “iPhone”:
GET /products/_search?q=iPhone
Ваш запрос к index “products”, но:

1. Elasticsearch рассылает запрос на все 5 шардов
2. Shard 0 (Node 1) находит “iPhone 15”
3. Остальные шарды возвращают пустые результаты
4. Вы получаете iPhone 15

Вы не знали и не должны знать, что iPhone лежит в shard 0 на Node 1. Вы просто работаете с индексом “products”.

Почему это разделение важно?

1. Масштабирование

Проблема: один индекс вырос до 1 терабайта, не влезает на один сервер (node).

Решение: делите индекс на 10 шардов по 100 гигабайт, распределяете по 10 серверам.

Index "logs" (1 TB)
├─ Shard 0: 100 GB → Node 1
├─ Shard 1: 100 GB → Node 2
├─ Shard 2: 100 GB → Node 3
├─ ...
└─ Shard 9: 100 GB → Node 10

Index остаётся один, но физически разбит на куски по серверам.

2. Производительность

Когда ищешь в индексе из 10 шардов на 10 серверах:

• Параллельный поиск — все 10 серверов ищут одновременно
• В 10 раз быстрее, чем один сервер последовательно

3. Отказоустойчивость

Index “products” (3 primary shards + replicas)

Node 1:
├─ Shard 0 (primary)
└─ Shard 1 (replica копия)

Node 2:
├─ Shard 1 (primary)
└─ Shard 2 (replica копия)

Node 3:
├─ Shard 2 (primary)
└─ Shard 0 (replica копия)

Node 1 сломался? Не проблема:

• Shard 0 есть реплика на Node 3
• Shard 1 primary жив на Node 2
• Index продолжает работать

Частые вопросы

Сколько шардов создавать?

• Index маленький (<50GB): 1-2 шарда достаточно
• Index средний (50-500GB): 3-5 шардов
• Index огромный (>500GB): расчёт по формуле, aim for 20-50GB per shard

Современный подход: начните с 1 шарда, если растёт — используйте Split API или ILM с rollover.

Можно ли изменить количество шардов?

Primary shards: НЕТ, количество фиксируется при создании индекса. Можно только через reindex в новый индекс или Split/Shrink API.

Replica shards: ДА, можно менять когда угодно:

PUT /products/_settings
{
  "number_of_replicas": 2
}

Что если один shard потерялся?

Если есть replica — ничего страшного, Elasticsearch автоматически переведёт реплику в primary.

Если реплики нет — данные в этом шарде потеряны, index частично нерабочий.

Поэтому для production нужна, минимум, 1 replica на каждый shard.

Итоговая схема

CLUSTER (весь Elasticsearch)
│
├─── NODE 1 (сервер Москва)
│    ├─ Index "users" → Shard 0 (primary)
│    ├─ Index "users" → Shard 2 (replica)
│    └─ Index "products" → Shard 1 (primary)
│
├─── NODE 2 (сервер Питер)
│    ├─ Index "users" → Shard 1 (primary)
│    ├─ Index "users" → Shard 0 (replica)
│    └─ Index "logs" → Shard 0 (primary)
│
└─── NODE 3 (сервер Казань)
     ├─ Index "users" → Shard 2 (primary)
     ├─ Index "products" → Shard 0 (primary)
     └─ Index "logs" → Shard 1 (primary)

Пользователь видит: indices (users, products, logs)

Elasticsearch видит: shards, распределённые по nodes

Пользователь работает с indices, Elasticsearch работает с shards.

---

Финальная аналогия

Представьте большую компанию:

• Company (Index): “Яндекс” — это логическая сущность, один бренд
• Departments (Shards): офис в Москве, офис в Питере, офис в Екатеринбурге — физические куски компании
• Buildings (Nodes): здания, где расположены офисы

Когда клиент обращается к “Яндексу” (index), его запрос может обработать любой офис (shard), и клиенту всё равно — он работает с компанией как с единым целым.

Index — логика. Shard — физика. Node — железо.