Elasticsearch — Tudo que você precisa saber sobre a ferramenta de buscas da Elastic — Parte 6.4 — Ciclo de Vida de Índices
Seja bem vindo a essa série de artigos onde abordaremos vários dos conceitos por trás de uma das ferramentas mais adoradas pela comunidade e também utilizada por vários players de mercado como Uber, Tinder, Blizzard, Ebay, sendo ela o Elasticsearch.
Esse é o sexto capítulo dessa série, onde nesse artigo falaremos sobre ciclo de vida dos índices.
Por se tratar de uma série sequencial, recomendo fortemente que dê uma passada nas partes anteriores a esse artigo!
Link do Guia: https://medium.com/@fqueirooz80/o-guia-completo-da-elastic-stack-5a3ba9a84a85
Ciclo de Vida dos Índices
Nesse capítulo, vamos entender com detalhes como funciona a gestão de vida dos índices, e daremos uma breve introdução ao conceito de Hot-Warm-Cold, não entraremos tanto no detalhe desse conceito pois nele deve ser abordado conceitos de Hardware para desenhar uma arquitetura que o suporte devidamente, então, por hora, entenderemos apenas as API’s e suas ações.
O ciclo de vida dos índices é administrado pela API ILM (Index Lifecycle Management), que permite que você automatize as ações dentro do seu índice conforme algumas regras que você mesmo determina.
Vamos supor que você precisa deletar um determinado índice após 30 dias, e hoje trabalha com alguma rotina ou até mesmo ação manual para isso, uma possível implementação para automatizar esse caso seria:
PUT _ilm/policy/expurgo30dias
{
"policy": {
"phases": {
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
}E então, teríamos o índice abaixo como exemplo:
PUT indicequeseraexpurgado
{
"settings": {
"index.lifecycle.name" : "expurgo30dias"
}
}PUT indicequeseraexpurgado/_doc/1
{
"campo1" : "teste"
}
Podemos verificar que nas configurações do índice, ele já conterá a nossa política:
GET indicequeseraexpurgado/_settingsRESULTADO ESPERADO:
{
"indicequeseraexpurgado" : {
"settings" : {
"index" : {
"lifecycle" : {
"name" : "expurgo30dias"
},
"number_of_shards" : "1",
"provided_name" : "indicequeseraexpurgado",
"creation_date" : "1581275822926",
"number_of_replicas" : "0",
"uuid" : "_ZdAICmdSySKzsUJQxevrg",
"version" : {
"created" : "7020099"
}
}
}
}
}
Show, vimos um exemplo prático de implementação de uma política que removerá o índice após os 30 dias, vamos agora descer mais nos detalhes dessa API.
Fases do ILM
Além de deletar o índice, podemos aplicar outras fases na nossa política onde as descrevo abaixo:
HOT — Busca e indexação latente, dedicada a índices que estão em constante uso e atualização. PERFORMANCE MÁXIMA, BAIXA RETENÇÃO.
Exemplo: Para índices que rotacionam diariamente, esse caso seria o do dia vigente.
WARM — Dedicada a índices que não possuem mais indexação, mas ainda assim recebem busca. MÉDIA PERFORMANCE, MÉDIA RETENÇÃO.
Exemplo: Índices já rotacionados, como dados da semana anterior que serão ainda consumidos diariamente.
COLD — Dedicada a índices que não são mais indexados e não são mais buscados com tanta frequência. Naturalmente, a performance de queries deixa de ser necessária. BAIXA PERFORMANCE, ALTA RETENÇÃO.
Exemplo: Dados históricos e relatórios esporádicos
DELETE — Como já vimos, cuida do expurgo dos nossos dados.
Algumas observações:
- As regras de fases dos índices podem ser aplicadas a datas, tamanho das shards, ou requisitos de performance.
- As políticas podem ser implementadas em templates.
- As políticas podem ser implementados a índices que já existem no cluster. (Importante caso esteja migrando de uma versão que ainda não tenha o ILM)
- Necessário privilégio de manage_ilm dentro do seu cluster para trabalhar com o ILM.
Estágios e ações
Dentro de cada fase, podemos especificar os estágios e ações que a nossa política pode realizar, onde descrevo algumas abaixo:
- O máximo de “idade” ou tamanho das shards do nosso índice.
- Ponto onde não há mais indexação de dados, podendo reduzir a quantidade de shards primárias do índice.
- Deletar os dados.
- Mover um índice para outro estado. Exemplo:
HOT -> WARM -> COLD -> DELETE.
- Reduzir a disponibilidade diminuindo a quantidade de répllicas.
- Realizar o merge dos índices e agrupa-los em apenas um único índice.
Vamos ao exemplo prático da nossa teoria:
Exercício:
Queremos uma política de ciclo de vida de índice que atenda os seguintes requisitos:
- Quando índice bater 50GB, realizar o rollover para um novo índice..
- Mover o índice antigo para o estado warm depois de 1 dia, marca-lo como leitura apenas e diminuir a quantidade de shards primárias para apenas 1.
- Após 7 dias, mover o índice para o estado cold, movendo-o para um hardware menos custoso.
- Deletar o índice após 30 dias de retenção.
Vamos resolver uma regra de cada vez, para a primeira, manteremos o estado hot do índice mas precisaremos que ele realize o rollover em um novo índice após bater 50GB, para isso temos a implementação abaixo:
PUT _ilm/policy/exercicio1
{
"policy": {
"phases": {
"hot": {
"rollover": {
"max_size": "50gb"
}
}
}
}
}Mover o índice antigo para o estado WARM e deixa-lo como apenas leitura com 1 única shard, para isso, utilizaremos a ação shrink.
PUT _ilm/policy/exercicio1
{
"policy": {
"phases": {
"hot": {
"rollover": {
"max_size": "50gb"
}
},
"warm": {
"min_age": "1d",
"actions": {
"shrink": {
"number_of_shards": 1
}
}
}
}
}
}Para as fase cold, utilizaremos a ação de alocar em nós que possuam o atributo “hardware” e o valor “cold”, e por fim, a nossa fase de delete que vimos no primeiro exemplo, temos então:
PUT _ilm/policy/exercicio1
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "50gb"
}
}
},
"warm": {
"min_age": "1d",
"actions": {
"shrink": {
"number_of_shards": 1
}
}
},
"cold": {
"min_age": "7d",
"actions": {
"allocate" : {
"require" : {
"hardware" : "cold"
}
}
}
},
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
}Na mão, nossa política robusta para os nossos índices.
Conclusão
Nesse artigo abordamos como funciona na prática a implementação de políticas de ciclo de vida dos índices.
Veremos mais pra frente como criar um cluster que suporte a arquitetura hot-warm-cold com qualidade.
Muito obrigado!
Referência:
