O tipo de campo aninhado em Elasticsearch e OpenSearch não é tão inocente quanto se poderia pensar. Vejamos o que eles são usados, os desafios com eles e possíveis alternativas.
Elasticsearch é um armazenamento de dados orientado a documentos. Tentando usar modelos relacionais como em uso em sistemas RDBMs como o PostgreSQL e o MySQL, com o Elasticsearch é propenso a falhas.
No entanto, o Elasticsearch permite modelar estruturas de dados complexas usando campos aninhadosque são úteis para preservar relacionamentos dentro de matrizes de objetos. Ao contrário dos campos de objeto padrão, os campos aninhados armazenam cada objeto em uma matriz como um documento oculto separado, permitindo uma consulta precisa. No entanto, essa abordagem vem com desvantagens significativas.
Vamos revisar as questões e desafios comuns com os campos aninhados, depois observe soluções e alternativas, dadas as casos de uso comuns em que estão sendo usados.
O que são campos aninhados?
Os campos aninhados são projetados para permitir a consulta em listas de objetos internalizados no documento (ou objeto) real que podem ser considerados um pai dessa lista. Por exemplo, uma lista de pares de chave / valor que servem como propriedades para um produto em um site de comércio eletrônico:
PUT products/_doc/1
{
"title": "Product 1",
"attributes": ({
"attribute": "color",
"value": "blue"
}, {
"attribute": "size",
"value": "m"
})
}
Em Elasticsearch e OpenSearch, isso é completamente equivalente ao seguinte, porque os índices não têm noção de estrutura ou subdocumentos:
{
"title": "Product 1",
"attributes.attribute": ("color", "size"),
"attributes.value": ("blue", "m")
}
Então, você pode consultar color:blue e obtenha este produto no conjunto de resultados; mas também size:blue Retornaria, o que obviamente não faz sentido. Para resolver esse problema, o tipo de campo aninhado ajuda a manter esse emparelhamento de valor-chave também no nível do índice, não sem algumas compensações.
Campos aninhados deficiências
1. Desrosno de desempenho
Como cada objeto aninhado é tratado como um documento independente internamente, as consultas em campos aninhados exigem Operações de junta caraslevando ao aumento do tempo de execução da consulta e ao maior consumo de memória.
2. Consultas complexas
Usar campos aninhados significa que você deve usar Consultas aninhadasque são mais pesados para escrever e entender. Ao contrário dos campos de objeto simples, que permitem consultas diretas, as estruturas aninhadas exigem uma sintaxe especializada, adicionando complexidade desnecessária.
3. Custos de indexação
Campos aninhados podem inchaço o tamanho do seu índicecomo cada objeto aninhado é armazenado separadamente. Isso leva ao aumento dos requisitos de armazenamento e ao desempenho de indexação mais lento, especialmente ao lidar com grandes conjuntos de dados.
4. Agregações limitadas
A agregação de dados nos campos aninhados é mais complicado. Como os documentos aninhados existem separadamente, as agregações padrão não funcionarão como o esperado, a menos que explicitamente embrulhado em um agregação aninhadaaumentando ainda mais a complexidade da consulta.
Alternativas a campos aninhados
Em muitos casos, os campos aninhados estão sendo usados onde não são realmente necessários. Você deve considerar cuidadosamente o seu caso de uso e se os requisitos de consulta realmente exigem o uso de objetos aninhados.
Se isso acontecer, talvez haja alternativas e, em vez de usar campos aninhados, considere:
- Achatando o modelo de dados sempre que possível.
- Desnormalização Duplicando os dados nos documentos dos pais.
Se os campos aninhados forem usados apenas para looks de valor-chave, considere o seguinte esquema para achatar seu esquema. Mapeamento de índice que é definido assim:
PUT product
{
"mappings": {
"properties": {
"title": {"type": "text"},
"attributes": {"type": "keyword", "doc_values": false}
}
}
}
Permite que os atributos de texto sejam definidos e usados assim:
PUT products/_doc/1
{
"title": "Customer 1",
"attributes": ("color|blue", "size|m")
}
PUT products/_doc/2
{
"title": "Customer 2",
"attributes": ("color|green", "size|s")
}
PUT products/_search
{
"query": {
"term": {
"attributes": "color|blue"
}
}
}
É certo que isso permite apenas pesquisas exatas (sem classificação ou agregações) e apenas valores de texto (sem pesquisas de intervalo numéricas, datas ou outros tipos de dados especializados). Mas, em muitos casos, isso é mais do que suficiente e pode resultar em enormes melhorias de desempenho e custo.
Contate-nos
Leave a Reply