Elasticsearch: Как я могу уменьшить количество первичных осколков?

Question

Я испытываю некоторые трудности с Elasticsearch. Кстати, я использую Elasticsearch в качестве службы Windows.

Примечание:

1. Я не могу подключиться к своему кластеру Elasticsearch (1 узел) через Cerebro .
2. Запросы Elasticsearch истекают. Сначала Кибана заметил таймауты , а затем я начал дальнейшее расследование.
3. Когда я перезапускаю службу Elasticsearch, запуск занимает много времени. Следует отметить, что когда я запускаю _cat/indices, для перехода индексов с желтого на красный требуется много времени.

Я пробежал _cluster/stats?human&pretty и заметил следующее:

  "indices": {
    "count": 159,
    "shards": {
      "total": 793,
      "primaries": 793,
      "replication": 0.0,
      "index": {
        "shards": {
          "min": 3,
          "max": 5,
          "avg": 4.987421383647798
        },
        "primaries": {
          "min": 3,
          "max": 5,
          "avg": 4.987421383647798
        },
        "replication": {
          "min": 0.0,
          "max": 0.0,
          "avg": 0.0
        }
      }
    },
    "docs": {
      "count": 664553,
      "deleted": 0
    },
    "store": {
      "size": "525.8mb",
      "size_in_bytes": 551382263
    },
    "fielddata": {
      "memory_size": "0b",
      "memory_size_in_bytes": 0,
      "evictions": 0
    },

---

Мой вопрос:

• Является ли 793 осколка красным флагом? Должен ли я настроить это?

---

ОБНОВЛЕНИЕ: Я полагаю, что у есть выделено слишком много осколков.

Итак, мой пересмотренный вопрос:

• Как я могу исправить ситуацию, когда я выделил слишком много осколков?
  • В частности, сколько осколков мне нужно сжать?
  • А какие команды мне нужно выполнить, чтобы уменьшить количество осколков?
    • Особенно учитывая тот факт, что мой кластер Elasticsearch (то есть 1 узел) очень долго перезапускается.

Answer 1

Наличие 793 первичных осколков только на 1 узле эластичного поиска - это большой НЕТ .Масштаб Elasticsearch происходит от его распределенной природы.Кроме того, я заметил, что у вас нет никакой реплики, поэтому она также ненадежна. Если некоторые первичные осколки повреждены, то в этом случае у них нет механизма восстановления.

Приходите к вамвопрос, на сколько сегментов я должен сжиматься?
Это полностью зависит от ваших требований: если у вас большие данные (более 100 ГБ), вы должны разделиться на несколько основных сегментов, и они должны жить на нескольких узлах.повысить производительность (полученную за счет небольшого размера сегмента и другого оборудования) и обеспечить горизонтальную масштабируемость (HS).

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

Для получения дополнительной информации о стратегии шардинга см. это руководство.

Вы можете уменьшить количество шардов, используя ссылку https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-shrink-index.html пользователь The_Pingu предоставлен, но это также зависит от того, какую версию ES вы используете.и я хотел бы предложить, прежде чем идти по этому пути, вы должны рассмотреть следующие архитектурные аспекты.

1. Сколько узлов у вас должно быть в кластере ES, одноузловой кластер ES определенно не рекомендуется в производстве, так как выпотерять высокую доступность, даже если у вас есть небольшие данные в производстве.
2. Сколько осколков вам нужно.
3. Сколько реплик вам нужно.(хотя это можно легко изменить во время выполнения без особых накладных расходов).

Answer 2

, если вы работаете с Flexiblesearch на одной машине, я бы сказал, что да, это довольно большой красный флаг. Вы должны быть в состоянии сделать то, что вы хотите с 1 осколок. смотрите там для более подробной информации: Множество осколков на одной машине