Стратегия резервного копирования, архивирования и очистки Elasticsearch Index с Rollover для данных, отличных от журналов - PullRequest
0 голосов
/ 08 января 2020

Извините, что скопировал мой вопрос со страницы обсужденияasticsearch здесь:

Привет,

У нас есть такой сценарий, что существует один индекс (5 осколков), который содержит 2 миллиона записей и увеличивается быстро Скорость увеличения размера индекса подобна размеру, достигающему около 200 ГБ (2 миллиона записей) за 15 дней.

Данные не основаны на времени, но имеют свой собственный жизненный цикл с указанными датами c в записи. Таким образом, основанное на времени управление индексами здесь не поможет.

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

Мы заметили, что чтение и запись по одному и тому же индексу идет медленно. Мы пытаемся сделать этот активный индекс более легким, чтобы повысить производительность запросов и индексирования, передавая данные в другие индексы (как «горячие» только для чтения), где мы все еще можем искать данные. И по прошествии некоторого времени мы можем очистить индексы после истечения срока действия данных (около 1 года).

Здесь, насколько мне известно, то, что мы ожидаем, похоже на управление жизненным циклом индекса (ILM), где HOT, WARM и индексы COLD классифицированы (но не как индексы, основанные на времени)

В нашем случае мы хотим передать данные на основе некоторых полей в документе, таких как creationDate или статус документа.

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

Кроме того, мы планируем _forcemerge индекса WARM и COLD только для чтения.

Мои запросы:

Мы собираемся правильный путь или кто-то может порекомендовать более эффективный способ справиться с этим сценарием?

Влияет ли это на производительность индексации и запросов?

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

Запись:

{
    "id": "record id",
    "fieldB": "sdfsdfsdf",
    "fieldC": "sgfdgdfgg",
    "fieldD": "asfsdfdsf",
    "fieldE": 40,
    "fieldF": 3,
    "fieldG": "sdfsdfsdf",
    "fieldH": "Value",
    "timeRaised": "2019-09-10T16:51:15.015Z",
    "timeChanged": "2019-09-10T16:51:15.015Z",
    "statusChangeDate": "2019-09-05T16:51:15.015Z",
    "status": "SUBMITTED",
    "fieldI": "sdfsafsdf",
    "fieldJ": [],
    "fieldK": [],
    "fieldL": [],
    "fieldM": [],
    "fieldN": [],
    "fieldO": [],
    "fieldP": [],
    "fieldQ": [],
    "fieldR": [],
    "fieldS": [],
    "fieldT": "",
    "fieldU": 0,
    "fieldV": 0,
    "fieldw": ""
}

Я уже перешел по следующим ссылкам:

https://dzone.com/articles/time-based-indexing-in-elastic-search-using-java

https://www.elastic.co/blog/managing-time-based-indices-efficiently

...