Pesquisa elástica, vários índices versus um índice e tipos para diferentes conjuntos de dados?

Eu tenho um aplicativo desenvolvido usando o padrão MVC e gostaria de indexar agora vários modelos, isso significa que cada modelo tem uma estrutura de dados diferente.

• É melhor usar índices múltiplos, um para cada modelo ou ter um tipo no mesmo índice para cada modelo? Ambas as formas também exigiriam uma consulta de pesquisa diferente, eu acho. Eu apenas comecei isso.

• Existem diferenças no desempenho entre os dois conceitos se o conjunto de dados for pequeno ou grande?

Eu mesmo testaria a segunda pergunta se alguém pudesse me recomendar alguns bons dados de amostra para esse fim.

Existem implicações diferentes para ambas as abordagens.

Supondo que você esteja usando as configurações padrão do Elasticsearch, ter 1 índice para cada modelo aumentará significativamente o número de seus shards, pois 1 índice usará 5 shards, 5 modelos de dados usarão 25 shards; enquanto ter 5 tipos de objetos em 1 índice ainda usará 5 shards.

Implicações para ter cada modelo de dados como índice:

• Eficiente e rápido para pesquisar no índice, pois a quantidade de dados deve ser menor em cada fragmento, pois é distribuída para diferentes índices.
• A pesquisa de uma combinação de modelos de dados de 2 ou mais índices gerará sobrecarga, porque a consulta precisará ser enviada para mais shards entre os índices, compilada e enviada de volta ao usuário.
• Não recomendado se seu conjunto de dados for pequeno, pois você terá mais armazenamento com cada fragmento adicional sendo criado e o ganho de desempenho é marginal.
• Recomendado se seu conjunto de dados for grande e suas consultas demorarem muito para serem processadas, pois os shards dedicados armazenam dados específicos e será mais fácil para o Elasticsearch processar.

Implicações para ter cada modelo de dados como um tipo de objeto em um índice:

• Mais dados serão armazenados nos 5 shards de um índice, o que significa que há menos problemas de sobrecarga quando você consulta em diferentes modelos de dados, mas o tamanho do shard será significativamente maior.
• Mais dados nos shards levarão mais tempo para a pesquisa do Elastics, pois há mais documentos para filtrar.
• Não recomendado se você sabe que está passando por 1 terabyte de dados e não está distribuindo seus dados por diferentes índices ou vários shards no mapeamento do Elasticsearch.
• Recomendado para pequenos conjuntos de dados, porque você não desperdiçará espaço de armazenamento para obter ganhos marginais de desempenho, pois cada fragmento ocupa espaço em seu hardware.

Se você está perguntando o que são muitos dados versus dados pequenos? Normalmente, depende da velocidade do processador e da RAM do seu hardware, a quantidade de dados que você armazena em cada variável no seu mapeamento para o Elasticsearch e seus requisitos de consulta; o uso de muitas facetas em suas consultas diminuirá significativamente o tempo de resposta. Não há uma resposta direta a isso e você terá que fazer um benchmark de acordo com suas necessidades.

Embora a resposta de Jonathan estivesse correta na época, o mundo seguiu em frente e agora parece que as pessoas por trás do ElasticSearch têm um plano de longo prazo para abandonar o suporte a vários tipos:

Onde queremos chegar: Queremos remover o conceito de tipos do Elasticsearch, enquanto ainda apoiamos pais / filhos.

Portanto, para novos projetos, o uso de apenas um único tipo por índice facilitará a eventual atualização para o ElasticSearch 6.x.

A resposta de Jonathan é ótima. Eu apenas acrescentaria alguns outros pontos a considerar:

• número de shards pode ser personalizado por solução que você selecionar. Você pode ter um índice com 15 shards principais ou dividi-lo em 3 índices para 5 shards - a perspectiva de desempenho não será alterada (supondo que os dados sejam distribuídos igualmente)
• pense sobre o uso de dados. Ou seja. se você usar o kibana para visualizar, é mais fácil incluir / excluir índices específicos, mas os tipos precisam ser filtrados no painel
• retenção de dados: para dados de log / métrica do aplicativo, use índices diferentes se precisar de um período de retenção diferente

Ambas as respostas acima são ótimas!

Estou adicionando um exemplo de vários tipos em um índice. Suponha que você esteja desenvolvendo um aplicativo para procurar livros em uma biblioteca. Há poucas perguntas a serem feitas ao proprietário da biblioteca,

Questões:

1. Quantos livros você planeja armazenar?

2. Que tipo de livros você vai armazenar na biblioteca?

3. Como você vai procurar livros?

Respostas:

1. Estou planejando armazenar de 50 a 70 mil livros (aproximadamente)

2. Terei 15 mil a 20 mil livros relacionados à tecnologia (ciência da computação, engenharia mecânica, engenharia química e assim por diante), 15 mil livros históricos, 10 mil livros de ciências médicas. 10 mil livros relacionados ao idioma (inglês, espanhol e assim por diante)

3. Pesquise por nome do autor, sobrenome do autor, ano de publicação, nome do editor. (Isso fornece uma idéia sobre quais informações você deve armazenar no índice)

A partir das respostas acima, podemos dizer que o esquema em nosso índice deve se parecer com isso.

// Este não é o mapeamento exato, apenas para o exemplo

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Para alcançar o que precede, podemos criar um índice chamado Livros e podemos ter vários tipos.

Índice: Livro

Tipos: Ciência, Artes

(Ou você pode criar muitos tipos, como Tecnologia, Ciência Médica, História, Idioma, se você tiver muito mais livros)

O importante a observar aqui é que o esquema é semelhante, mas os dados não são idênticos. E a outra coisa importante é o total de dados que você está armazenando.

Espero que o exposto acima ajude a escolher tipos diferentes em um Índice, se você tiver um esquema diferente, considere um índice diferente. Índice pequeno para menos dados. grande índice para big data :-)