O Elasticsearch permite que você indexe dados de maneira rápida e flexível. Experimente gratuitamente na nuvem ou execute-o localmente para ver como a indexação pode ser fácil.
Um índice do Elasticsearch pode ser configurado por meio de mapeamento, configurações e aliases:
- As definições de mapeamento especificam o esquema de dados.
- As configurações definem o tamanho dos fragmentos e as taxas de atualização.
- Os aliases são usados para dar nomes alternativos ao índice.
Ao indexar um documento pela primeira vez ou criar um índice vazio usando a API Criar Índice, o índice será criado com as configurações padrão, sem esquema de dados e sem aliases. Essas configurações padrão funcionam muito bem em ambientes de desenvolvimento e teste, mas talvez seja necessário personalizar nossos índices para ambientes de produção.
Trabalhar com os mapeamentos e configurações padrão em produção pode resultar em indexação e desempenho de pesquisa deficientes. A criação manual de índices é um processo tedioso e demorado. Recriar esses índices em todos os ambientes é especialmente impraticável se tivermos um esquema de mapeamento complexo, além de configurações e aliases personalizados.
Felizmente, o Elasticsearch nos fornece uma ferramenta para aplicar automaticamente uma configuração predefinida ao criar índices na forma de modelos de índice .
Modelos de índice
Os modelos de índice permitem criar índices com configurações definidas pelo usuário. Um índice pode obter a configuração desses modelos, por exemplo, um número definido de shards e réplicas ou mapeamentos de campos, durante sua instanciação. Um modelo será definido com um padrão de nome e algumas configurações. Se o nome do índice corresponder ao padrão de nomenclatura do modelo, o novo índice será criado com a configuração definida no modelo.
O Elasticsearch atualizou sua funcionalidade de modelos na versão 7.8 com modelos compostos. Esta versão mais recente oferece muito mais modelos de índice reutilizáveis, como demonstrado neste artigo.
Tipos de modelos
Os modelos de índice podem ser classificados em duas categorias:
- Modelos de índice (ou modelos de índice componíveis): Os modelos de índice componíveis podem existir por si só ou podem ser compostos por nenhum ou mais modelos componentes (consulte a segunda categoria).
- Modelos de componentes: O modelo de componente é um modelo reutilizável que define a configuração necessária. Normalmente, espera-se que o modelo de componente esteja associado a um modelo de índice. Cada um dos modelos de componentes pode ser associado a um ou mais modelos de índice.
Como você pode ver na imagem abaixo, os modelos de índice A e B compartilham modelos de componentes (neste caso, apenas um – o Modelo 3) entre si. Um modelo de índice pode não conter nenhum ou vários modelos de componentes, e cada um dos modelos de componentes pode não estar associado a nenhum ou a vários modelos de índice. Ambos os tipos de modelos podem existir por si só, porém os modelos de componentes são inúteis a menos que estejam anexados a um modelo de índice.

A ideia geral é desenvolver um catálogo de modelos de componentes para uma organização usar em diversas necessidades (por exemplo, especificar os vários modelos de componentes para ambientes individuais) e associá-los a vários índices por meio de modelos de índice componíveis.
Como criar modelos (de índice) componíveis
O Elasticsearch fornece um endpoint _index_template para gerenciar modelos de índice. Neste modelo, o usuário fornece todos os mapeamentos, configurações e aliases necessários, juntamente com um padrão de nome de índice. Vamos analisar um exemplo de criação de um modelo para um aplicativo de microsserviços chamado customer-order-service , responsável pela lógica de geração de pedidos.
Digamos que nossa necessidade seja criar um modelo para pedidos de clientes, representado por um padrão com caracteres curinga: *pedidos. Espera-se que este modelo tenha determinados mapeamentos e configurações, como o campo order_date, bem como números de shards e réplicas.
Qualquer índice que corresponda a este modelo durante a sua criação herdará as configurações definidas neste modelo. Por exemplo, um índice black_friday_orders terá o campo order_date, o número de shards será definido como 5 e o número de réplicas como 2. Além disso, todos os índices criados a partir deste modelo também herdarão um único nome de alias ! Vamos criar este modelo de pedidos (orders_template) com um padrão de índice definido como *orders e com um esquema de mapeamento que consiste em um único campo order_date com um formato de data predefinido dd-MM-yyyy. O código abaixo mostra como criar esse modelo de índice.
Ao executar essa consulta nas DevTools do Kibana, o modelo é criado com o padrão de índice *orders, juntamente com o mapeamento predefinido, as configurações e um alias. O `index_patterns` é uma matriz de padrões de correspondência; qualquer índice que corresponda a esse padrão derivará a configuração do modelo. Você pode executar o seguinte comando para recuperar o modelo persistido, que deverá reiterar o que fizemos:
Existe também uma prioridade, um número positivo, definida ao criar o atributo de modelo definido no modelo: cada modelo é definido com uma prioridade, de forma que quaisquer alterações conflitantes de modelos diferentes sejam resolvidas usando esse valor, com precedência dada ao valor de prioridade mais alto. A seguir, analisaremos a prioridade dos modelos com mais detalhes.
Criando um índice com o modelo
Agora que temos um modelo – um projeto para criar índices – o próximo passo é criar um índice. Quando o nome do índice corresponde ao padrão fornecido, as configurações do modelo são aplicadas automaticamente. Para comprovar esse ponto, como mostra o código abaixo, vamos criar um novo índice chamado: blackfriday_orders:
Como o nome do índice (blackfriday_orders) corresponde ao padrão de nomenclatura definido no modelo (ou seja, *pedidos), o índice deve obter toda a configuração derivada do modelo. Vamos recuperar esse índice recém-criado e verificar se isso é realmente verdade executando o seguinte código:
Isso deve retornar:
Conforme indicado na resposta, a configuração do blackfriday_orders foi herdada do modelo. Podemos tentar várias combinações de índices que herdarão com sucesso a configuração do modelo:
No entanto, os seguintes índices não herdarão a configuração, pois o nome não corresponderá ao padrão:
Um ponto importante a lembrar é que todos os índices derivados de um modelo têm o mesmo alias – all_orders – neste caso. Existe uma vantagem em ter um alias desse tipo: podemos simplesmente consultar esse único alias em vez de vários índices.
Embora criemos um modelo para *pedidos, espera-se que qualquer índice correspondente adote a configuração do modelo. Normalmente, consciente ou inconscientemente, as equipes podem criar alguns modelos adicionais por diversos motivos. Isso significa que, às vezes, o nome do índice pode corresponder a dois padrões de modelo diferentes! O Elasticsearch precisa decidir qual das configurações desses modelos deve ser aplicada. Felizmente, esse dilema pode ser resolvido usando a prioridade do modelo.
Criação de modelos de componentes
Aprendemos sobre modelos de índice na parte anterior deste artigo. Existem algumas desvantagens em criar modelos com a configuração já integrada – uma delas é que a configuração não pode ser exportada para outros modelos. Se desejarmos ter uma configuração semelhante, por exemplo, para modelos relacionados a clientes (*clientes), talvez tenhamos que recriar todo o modelo. Isso significa que podemos estar criando dezenas deles em uma organização típica (e você pode ter alguns outros dependendo do ambiente).
Como sempre buscamos a reutilização, o Elasticsearch redesenhou os modelos levando isso em consideração. Os modelos de componentes atendem a essa necessidade. Se você tem experiência em DevOps, provavelmente precisará criar índices com uma configuração predefinida para cada um dos ambientes. Em vez de aplicar manualmente cada uma dessas configurações de forma tediosa, você pode criar um modelo de componente para cada um dos ambientes.
Um modelo de componente nada mais é do que um bloco reutilizável de configurações que podemos usar para criar mais modelos de índice. Note que os modelos de componentes não têm utilidade a menos que sejam combinados com modelos de índice. Eles são expostos através de um endpoint _component_template. Vamos ver como tudo isso se encaixa.
Modelo de configurações
Vamos extrair as configurações que definimos anteriormente em nosso modelo de índice e criar um modelo de componente a partir delas. Espera-se que o settings_component_template tenha cinco shards primários com duas réplicas por shard primário. O primeiro passo, como mostra o código abaixo, é declarar e executar um modelo de componente com essa configuração.
Como mostra o código acima, usamos o endpoint _component_template para criar um modelo de componente. O corpo da solicitação contém as informações do modelo em um objeto de modelo. O modelo settings_component_template agora está disponível para uso em outros locais nos modelos de índice. Uma diferença notável é que este modelo não define nenhum padrão de índice; é simplesmente um bloco de código que configura algumas propriedades para nós.
Modelo de mapeamento
Da mesma forma, vamos criar outro modelo. Desta vez, vamos extrair o esquema de mapeamento que definimos anteriormente nos modelos de índice independentes. O código abaixo mostra o script:
Modelo de aliases
Seguindo a mesma linha de raciocínio, também podemos ter um modelo de componente com os aliases – dois aliases (all_orders e sales_orders):
Modelo de índice componível
Agora que temos esses três modelos de componentes, o próximo passo é colocá-los em uso. Podemos fazer isso permitindo que um modelo de índice, digamos, para pedidos de Natal, o utilize:
A tag `composed_of` é uma coleção de todos os modelos de componentes que compõem este modelo. Neste caso, estamos escolhendo as configurações, os mapeamentos e os modelos de componentes de aliases. Também estamos aumentando a prioridade, então este modelo terá precedência sobre qualquer outro. Assim que o modelo estiver pronto, quaisquer índices que correspondam ao padrão *orders herdarão a configuração desses três modelos de componentes.
Dito isso, caso desejemos criar um novo modelo, digamos, para clientes, utilizando apenas um dos modelos existentes (settings_component_template) e um modelo de aliases recém-criado (aliases_component_template – veja abaixo), podemos fazê-lo da seguinte forma:
O modelo de índice é o seguinte:
Você percebeu que o settings_component_template foi (re)utilizado em dois templates diferentes? Esse é o poder dos modelos de componentes.
Prioridade do modelo
Existe a possibilidade de os desenvolvedores criarem vários modelos de índice sem analisar o estoque existente. É importante definir uma prioridade para cada um desses modelos, de forma que aquele com maior prioridade seja utilizado. Por exemplo, o modelo `my_orders_template_1` sobrescreve o modelo `my_orders_template_2` no seguinte trecho de código:
Quando você tem vários modelos que correspondem aos índices que estão sendo criados, o Elasticsearch aplica todas as configurações de todos os modelos correspondentes, mas sobrescreve qualquer configuração que tenha prioridade mais alta.
Precedência dos modelos
Por fim, você pode estar se perguntando sobre a precedência dos modelos – a configuração definida no modelo do componente substitui a definida no próprio modelo do índice principal? Ou vice-versa? Bem, existem algumas regras:
- Um índice criado com configurações explícitas tem precedência sobre tudo – isso significa que, se você criar um índice com configuração explícita, não espere que ela seja substituída pelos modelos.
- Os modelos legados (modelos criados antes da versão 7.8) têm uma prioridade menor do que os modelos componíveis.
Resumo
- Um índice contém mapeamentos, configurações e aliases: os mapeamentos definem o esquema dos campos, as configurações definem os parâmetros do índice, como o número de shards e réplicas, e os aliases fornecem nomes alternativos ao índice.
- Os modelos permitem criar índices com configurações predefinidas. Ao atribuir um nome a um índice que corresponda ao padrão de índice definido em um modelo específico, esse índice será configurado automaticamente de acordo com o modelo.
- O Elasticsearch introduziu modelos de índice componíveis na versão 7.8. Os modelos de índice combináveis permitem modularidade e versionamento dos modelos.
- Os modelos componíveis consistem em nenhum ou mais modelos de componentes.
- Um modelo de índice também pode ter sua própria configuração definida.
- Um modelo de componente é um modelo reutilizável com configuração predefinida, assim como um modelo de índice composto.
- No entanto, espera-se que os modelos de componentes façam parte de um modelo de índice; eles são inúteis se não forem "compostos" em um modelo de índice.
- Os modelos de componentes não têm um padrão de índice definido neles – o que é mais um motivo pelo qual "se espera" que façam parte de um modelo de índice.
- Cada um dos modelos tem uma prioridade – um número positivo. Quanto maior o número, maior a prioridade para a aplicação desse modelo.




