Настройка для использования дискового пространства

По умолчанию Elasticsearch индексирует и добавляет значения документов для большинства полей, чтобы они могли быть проиндексированы и агрегированы «из коробки». Например, если у вас есть числовое поле под названием foo, на котором необходимо выполнить гистограммы, но которое никогда не нужно фильтровать, вы можете безопасно отключить индексацию этого поля в своих отображениях:

PUT index
{
  "mappings": {
    "properties": {
      "foo": {
        "type": "integer",
        "index": false
      }
    }
  }
}

text поля хранят нормализационные факторы в индексе, чтобы облегчить оценку документов. Если вам нужны только возможности сопоставления с полем text, но вам не важны созданные оценки, вы можете использовать тип match_only_text вместо него. Этот тип поля экономит значительное место, отбросив информацию об оценке и позициях.

Динамические отображения строк по умолчанию динамические отображения строк будут индексировать строковые поля как text и keyword. Это приводит к неэффективному использованию ресурсов, если вам нужно только одно из них. Как правило, поле id нужно индексировать только как keyword, а поле body — только как поле text.

Это можно отключить, настроив явные отображения для строковых полей или создав динамические шаблоны, которые будут отображать строковые поля как text или keyword.

Например, вот шаблон, который можно использовать для отображения строковых полей только как keyword:

PUT index
{
  "mappings": {
    "dynamic_templates": [
      {
        "strings": {
          "match_mapping_type": "string",
          "mapping": {
            "type": "keyword"
          }
        }
      }
    ]
  }
}

Более крупные фрагменты будут более эффективны для хранения данных. Чтобы увеличить размер фрагментов, можно уменьшить количество основных фрагментов в индексе, создавая индексы с меньшим количеством основных фрагментов, создавая меньше индексов (например, используя API изменения индекса) или изменяя существующий индекс с помощью API уменьшения индекса.

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

Поле _source хранит исходный JSON-тело документа. Если вам не нужен к нему доступ, вы можете отключить его. Однако API, которые нуждаются в доступе к _source, такие как обновление и переиндексация, не будут работать.

Поля _source и сохранённые поля могут занимать значительный объем дискового пространства. Их можно сжать более агрессивно, используя кодек best_compression кодек.

Индексы в Elasticsearch хранятся в одном или нескольких фрагментах. Каждый фрагмент представляет собой индекс Lucene и состоит из одного или нескольких сегментов — фактических файлов на диске. Более крупные сегменты более эффективны для хранения данных.

API принудительного слияния можно использовать для уменьшения количества сегментов на фрагмент. Во многих случаях количество сегментов можно уменьшить до одного на фрагмент, установив max_num_segments=1.

API уменьшения индекса позволяет уменьшить количество фрагментов в индексе. В сочетании с API принудительного слияния выше это может значительно уменьшить количество фрагментов и сегментов индекса.

Тип, который вы выбираете для числовых данных, может существенно повлиять на использование дискового пространства. В частности, целые числа должны храниться с использованием целочисленного типа (byte, short, integer или long), а числа с плавающей запятой должны храниться в scaled_float, если это уместно, или в наименьшем типе, соответствующем случаю использования: использование float вместо double или half_float вместо float поможет сэкономить место на диске.

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

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

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

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