Notas de estudo do ElasticSearch - Capítulo 4 Princípio de fragmentação ES e explicação detalhada do processo de leitura e escrita

4. Explicação detalhada do princípio de fragmentação ES e do processo de leitura e escrita

Antes de aprender os princípios da fragmentação ES e do processo de leitura e gravação, você precisa primeiro aprender alguns conceitos básicos de ES e o conhecimento relacionado ao ambiente de cluster ES.

4.1 Conceitos básicos de ES

4.1.1 Índice

Índice é equivalente ao banco de dados no MySQL. Um índice é uma coleção de documentos com características um tanto semelhantes.

4.1.2 Tipo

Type é equivalente a uma tabela no MySQL. Um tipo é uma classificação/partição lógica de um índice, e sua semântica é completamente determinada pelo usuário. Normalmente, um tipo é definido para documentos que possuem um conjunto comum de campos. Diferentes versões do ES usam tipos de maneira diferente.

Versão	Tipo
5.x	Suporta vários tipos
6.x	Só pode haver um tipo
7.x	O tipo personalizado não é mais suportado por padrão, o padrão é _doc

4.1.3 Documentação

Documento é equivalente a uma linha no MySQL. Um documento é uma unidade básica de informação que pode ser indexada, ou seja, um dado.

4.1.4 Campos

Campo é equivalente a uma coluna no MySQL, ou seja, um campo é um campo de atributo.

4.1.5 Mapeamento

O mapeamento é usado para especificar como o ES trata os dados, como o tipo de dados de um campo, valor padrão, analisador, se pode ser indexado, etc.

Como estabelecer um mapeamento apropriado é o foco do uso do ES

4.1.6 Fragmentação

Quando os dados armazenados em um índice são muito grandes, o tamanho dos dados pode exceder a capacidade do espaço em disco ou a eficiência do processamento de solicitações de pesquisa é bastante reduzida. Para resolver este problema, o Elasticsearch oferece a capacidade de dividir o índice em várias partes, cada parte é chamada de shard . Ao criar um índice, você pode especificar o número desejado de fragmentos. Cada fragmento em si também é um “índice” totalmente funcional e independente que pode ser colocado em qualquer nó do cluster.

As principais funções da fragmentação :

• Permite dividir/expandir a capacidade de conteúdo horizontalmente.
• Permite operações distribuídas e paralelas em fragmentos, melhorando assim o desempenho/rendimento.

Quanto à forma como um shard é distribuído, como seus documentos são agregados e como as solicitações de pesquisa são totalmente gerenciadas pelo Elasticsearch, tudo isso é transparente para os usuários e não precisa ser muito preocupado.

Nota: Mencionamos anteriormente que o Elasticsearch é desenvolvido com base no Lucene, e o Lucene também possui o conceito de indexação. No ES, um índice Lucene é chamado de fragmento, e um índice Elasticsearch é uma coleção de vários fragmentos.

Quando o ES pesquisa no índice, ele envia solicitações de consulta para cada fragmento que pertence ao índice (índice Lucene) e, em seguida, mescla os resultados de cada fragmento em um conjunto de resultados global.

4.1.7 Cópias

ES permite que os usuários criem uma ou mais cópias de um fragmento.Essas cópias são chamadas de fragmentos replicados (réplicas) e os fragmentos copiados são chamados de fragmentos primários .

As principais funções das cópias:

• Fornece alta disponibilidade em caso de falha de fragmento/nó .

  Para obter alta disponibilidade, o ES não colocará fragmentos de réplica e fragmentos primários no mesmo nó .

• Dimensiona o volume/taxa de transferência de pesquisa porque as pesquisas podem ser executadas em paralelo em todas as réplicas.

Em resumo, cada índice pode ser dividido em vários fragmentos. Um índice também pode ser replicado 0 vezes (ou seja, sem replicação) ou múltiplas vezes. Depois de replicado, cada índice possui um fragmento primário (o fragmento original usado como origem de replicação) e um fragmento de réplica (uma cópia do fragmento primário). O número de fragmentos e replicação pode ser especificado no momento da criação do índice. Após a criação do índice, o usuário pode alterar dinamicamente o número de replicações a qualquer momento, mas não pode alterar o número de fragmentos . Por padrão, cada índice no ES é fragmentado em 1 fragmento primário e 1 fragmento de réplica , o que significa que se houver pelo menos dois nós no cluster ES, o índice terá 1 fragmento primário e outro fragmento replicado (1 cópia completa). Neste caso, cada índice tem um total de 2 fragmentos. Precisamos determinar o número de fragmentos com base nas necessidades do índice.

4.1.8 Alocação

O processo de alocação de fragmentos para um nó, incluindo a alocação de fragmentos primários ou réplicas. Se for uma réplica, também inclui o processo de cópia de dados do fragmento primário. Este processo é concluído pelo nó mestre .

O ambiente de cluster será explicado no próximo capítulo.

4.2 Ambiente de cluster

4.2.1 Arquitetura do sistema

• nó

  Cada instância do ElasticSearch em execução é chamada de nó

• conjunto

  Um cluster consiste em um ou mais nós com o mesmo cluster.name, que compartilham a pressão de dados e carga. Quando um nó é adicionado ou removido do cluster, o cluster redistribuirá todos os dados uniformemente.

• nó mestre

  Quando um nó é eleito como nó mestre, ele será responsável por gerenciar todas as alterações em todo o cluster, como adicionar e excluir índices ou adicionar e excluir nós, etc., e geralmente não envolve o nó mestre no nível do documento. mudanças e pesquisas.A operação, quando configurada desta forma, mesmo que o cluster tenha apenas um nó mestre, o aumento do tráfego não o tornará um gargalo, e qualquer nó pode se tornar o nó mestre.

Os usuários podem enviar solicitações para qualquer nó do cluster, incluindo o nó mestre. Cada nó conhece a localização de qualquer documento e pode encaminhar as solicitações do usuário diretamente para o nó que armazena o documento de que o usuário precisa. Não importa para qual nó o usuário envie a solicitação, ele é responsável por coletar os dados de cada nó que contém o documento que precisamos e devolver o resultado final ao cliente. O Elasticsearch gerencia tudo isso de forma transparente.

4.2.2 Implantar cluster

Este exemplo é para implantar um cluster de máquina única em um ambiente Windows.

As etapas específicas são as seguintes:

1. Em um espaço em disco adequado, crie a pasta ElasticSearch-cluster

2. Na pasta ElasticSearch-cluster, copie três cópias da versão descompactada es-7.8.0

3. Altere a configuração de cada es. O caminho do arquivo de configuração é: seu caminho de instalação do es/config/elasticsearch.yml

   Configuração chave do nó-9201

   #集群名称，同一个集群中的各个节点的这个配置项需要保持一致
   cluster.name: my-es
   #节点名称，同一个集群中的各个节点的这个配置项需要保证唯一
   node.name: node-9201
   #是否是主节点
   node.master: true
   #是否是数据节点，为false则表示不存储数据
   node.data: true
   #ip地址，由于是本机测试，所以指定为localhost
   network.host: localhost
   #http端口号
   http.port: 9201
   #tcp监听端口，同一个集群中的各个节点之间通过tcp协议进行相互通信
   transport.tcp.port: 9301
   #集群内可以发现的其他节点的tcp路径
   discovery.seed_hosts: ["localhost:9302","localhost:9303"]
   discovery.zen.fd.ping_timeout: 1m
   discovery.zen.fd.ping_retries: 5
   #初始化时被指定的主节点
   cluster.initial_master_nodes: ["node-9201"]
   #跨域配置
   http.cors.enabled: true
   http.cors.allow-origin: "*"
   

   Configuração chave do nó-9202

   #集群名称，同一个集群中的各个节点的这个配置项需要保持一致
   cluster.name: my-es
   #节点名称，同一个集群中的各个节点的这个配置项需要保证唯一
   node.name: node-9202
   #是否是主节点
   node.master: true
   #是否是数据节点，为false则表示不存储数据
   node.data: true
   #ip地址，由于是本机测试，所以指定为localhost
   network.host: localhost
   #http端口号
   http.port: 9202
   #tcp监听端口，同一个集群中的各个节点之间通过tcp协议进行相互通信
   transport.tcp.port: 9302
   #集群内可以发现的其他节点的tcp路径
   discovery.seed_hosts: ["localhost:9301", "localhost:9303"]
   discovery.zen.fd.ping_timeout: 1m
   discovery.zen.fd.ping_retries: 5
   #初始化时被指定的主节点
   cluster.initial_master_nodes: ["node-9201"]
   #跨域配置
   http.cors.enabled: true
   http.cors.allow-origin: "*"
   

   Configuração chave do nó-9203

   #集群名称，同一个集群中的各个节点的这个配置项需要保持一致
   cluster.name: my-es
   #节点名称，同一个集群中的各个节点的这个配置项需要保证唯一
   node.name: node-9203
   #是否是主节点
   node.master: true
   #是否是数据节点，为false则表示不存储数据
   node.data: true
   #ip地址，由于是本机测试，所以指定为localhost
   network.host: localhost
   #http端口号
   http.port: 9203
   #tcp监听端口，同一个集群中的各个节点之间通过tcp协议进行相互通信
   transport.tcp.port: 9303
   #集群内可以发现的其他节点的tcp路径
   discovery.seed_hosts: ["localhost:9301", "localhost:9302"]
   discovery.zen.fd.ping_timeout: 1m
   discovery.zen.fd.ping_retries: 5
   #初始化时被指定的主节点
   cluster.initial_master_nodes: ["node-9201"]
   #跨域配置
   http.cors.enabled: true
   http.cors.allow-origin: "*"
   

4.2.3 Iniciar o cluster

• comece

  Consulte a Seção 2.1 e inicie o nó-9201, o nó-9202 e o nó-9203 em sequência.

• teste (http)

{
    
    
    "cluster_name": "my-es", // 集群名称
    "status": "green",       // 当前节点的状态
    "timed_out": false,      // 是否超时
    "number_of_nodes": 3,    // 节点总数  
    "number_of_data_nodes": 3, // 数据节点总数
    "active_primary_shards": 0,
    "active_shards": 0,
    "relocating_shards": 0,
    "initializing_shards": 0,
    "unassigned_shards": 0,
    "delayed_unassigned_shards": 0,
    "number_of_pending_tasks": 0,
    "number_of_in_flight_fetch": 0,
    "task_max_waiting_in_queue_millis": 0,
    "active_shards_percent_as_number": 100.0
}

4.2.4 Failover

• Crie o seguinte índice no cluster para facilitar o aprendizado subsequente

  Crie um índice de usuários e aloque três fragmentos primários e uma réplica (uma réplica para cada fragmento primário).

  {
        
        
   "settings" : {
        
        
   "number_of_shards" : 3,
   "number_of_replicas" : 1
   }
  }
  

• Use o plug-in do navegador para visualizar o status geral do cluster

  Iniciamos apenas o nó node-9201 e o nó node-9202

  Use o plug-in elasticsearch-head para visualizar o status do cluster especificado diretamente por meio do navegador.

  

  Como pode ser visto na figura acima, o valor de integridade do cluster está verde neste momento, o que significa que no cluster atual, os três fragmentos primários e três réplicas estão alocados corretamente em nós diferentes (observe que apresentamos isso anteriormente, não é seguro se o fragmento primário e sua réplica estiverem no mesmo nó).

  Isso significa que se houver algum problema com algum nó do cluster, nossos dados permanecerão intactos. Todos os documentos indexados recentemente serão armazenados no fragmento primário e depois copiados para os fragmentos de réplica correspondentes em paralelo. Isso garante que possamos obter documentos do fragmento primário e do fragmento de réplica.

  Ou seja, se o nó acima, nó-9201, cair, isso não afetará a função de consulta do ES, e ainda poderemos obter os dados do documento a partir da cópia.

4.2.5 Expansão horizontal

Quando o aplicativo estiver em execução por um período de tempo e a quantidade de dados no ES aumentar gradualmente, podemos obter expansão horizontal adicionando novos nós ao cluster ES. Quando o terceiro nó for iniciado, o cluster terá três nós e realocará os fragmentos para distribuir a carga.

Neste momento, inicie o nó node-9203 e verifique novamente a alocação de fragmentos do cluster.

Como você pode ver na figura acima, quando um novo nó ingressa no cluster, o cluster redistribui os fragmentos. Neste momento, os recursos de hardware (CPU, RAM, E/S) de cada nó serão compartilhados por menos fragmentos e o desempenho de cada fragmento será melhorado.

Sharding é um mecanismo de pesquisa totalmente funcional que tem a capacidade de usar todos os recursos de um nó. Nosso índice com 6 shards (3 shards primários e 3 shards de réplica) pode ser expandido para no máximo 6 nós . Existe um shard em cada nó, e cada shard possui todos os recursos do nó onde está localizado.

Então, e se quisermos expandir além de 6 nós?

O número de fragmentos primários é determinado quando o índice é criado . Com efeito, este número define a quantidade máxima de dados que este índice pode armazenar. (O tamanho real depende dos seus dados, hardware e cenários de uso.) No entanto, as operações de leitura (pesquisa e retorno de dados podem ser processadas pelos fragmentos primários ou de réplica ao mesmo tempo, portanto, quanto mais fragmentos de réplica você tiver, melhor terá maior rendimento.

Portanto, o ES permite que os usuários ajustem dinamicamente o número de fragmentos de réplica em um cluster em execução.Os usuários podem ajustar o número de réplicas para dimensionar o cluster sob demanda.

• Ajuste o número de réplicas para 2 (dois fragmentos de réplica para cada fragmento primário)

  Envie uma solicitação PUT para o cluster ES, http/localhost:9201/index name/_settings, e adicione o seguinte conteúdo no corpo da solicitação

  {
        
        
      "number_of_replicas":2
  }
  

  

• Ver o status do cluster

  

  O índice de usuários agora tem 9 fragmentos: 3 fragmentos primários e 6 fragmentos de réplica. Isso significa que podemos dimensionar o cluster para 9 nós, com um fragmento em cada nó. Comparado com os 3 nós originais, o desempenho da pesquisa de cluster pode ser melhorado 3 vezes. É claro que apenas adicionar mais fragmentos de réplica a um cluster com o mesmo número de nós não melhorará o desempenho, porque cada fragmento obterá menos recursos dos nós. Neste momento, mais recursos de hardware precisam ser adicionados para melhorar o rendimento. Porém, mais fragmentos de réplica aumentam a quantidade de redundância de dados: de acordo com a configuração de nó acima, podemos perder 2 nós sem perder nenhum dado.

4.2.6 Lidando com falhas

Quando o nó mestre no cluster ES fica inativo (o nó-9201 é desligado), o cluster ES elege um novo nó (esses nós alternativos são aqueles nós com o item de configuração node.master no arquivo de configuração sendo verdadeiro. Como nós Ao configurar o ambiente de cluster anteriormente, este item de configuração dos três nós é verdadeiro, portanto, neste momento, o cluster ES selecionará um nó do nó-9202 e do nó-9203 como o novo nó mestre).

Você pode ver o status do ambiente de cluster ES neste momento por meio do plug-in da seguinte forma:

Como pode ser visto na figura acima, o nó primário é o nó 9203 neste momento. Os fragmentos originais 0 e 1 no nó 9201 são ambos fragmentos primários. O novo nó primário copiará imediatamente as cópias correspondentes desses fragmentos no nó -9202. O fragmento é promovido para o fragmento principal e o status do cluster será amarelo neste momento. **Este processo de promoção do fragmento primário ocorre instantaneamente, como pressionar um botão. **Embora tenhamos todos os três fragmentos primários, também configuramos que cada fragmento primário precisa corresponder a dois fragmentos de réplica. No momento, há apenas um fragmento de réplica, portanto, o cluster está no estado amarelo, embora seja no status amarelo, mas as funções do cluster ES podem ser usadas normalmente.

Se reiniciarmos o nó-9201, o cluster poderá alocar os fragmentos de réplica ausentes novamente e o status do cluster será restaurado ao estado anterior. Se o nó-9201 ainda possuir os fragmentos anteriores, ele tentará reutilizá-los e copiar apenas os arquivos de dados modificados do fragmento primário. Comparado com o cluster anterior, apenas o nó mestre foi trocado.

A figura acima mostra o status do cluster após iniciar o nó-9201 novamente.

Nota: Os leitores devem tentar o seu melhor para operar manualmente estes capítulos sobre failover, expansão horizontal e resposta a falhas para compreender o conceito de design do cluster ES.

4.2.7 Cálculo de rota

• algoritmo de roteamento

  Ao adicionar um documento a um cluster ES, o documento será armazenado em um shard primário. Como haverá vários shards primários em um ambiente de cluster, como o Elasticsearch sabe em qual shard primário este documento deve ser colocado?

  Para resolver os problemas acima, o Elasticsearch usa um algoritmo para realizar cálculos de roteamento para determinar em qual shard o documento deve ser colocado, e também usa esse algoritmo para obter o shard que armazena o documento durante a consulta.

  O algoritmo é o seguinte:

  shard = hash(routing) % number_of_primary_shards
  

  roteamento é um valor variável, o padrão é o _id do documento, e também pode ser definido pelo usuário.

  O significado deste algoritmo é: pegue o valor hash do roteamento e divida-o pelo número de fragmentos primários para obter o restante. O valor resultante é um número entre 0 (número de fragmentos primários - 1) _{(a contagem começa em 0, tal como 3 fragmentos primários) Fragmentação, então o intervalo é 0} 2), que é o local de fragmentação onde o documento está armazenado.

  Isso explica por que é importante determinar o número de shards primários ao criar o índice e nunca alterar esse número: porque se o número mudar, todos os valores de roteamento anteriores serão inválidos e o documento não será mais encontrado.

• Roteamento personalizado

  Todas as APIs de documentos (get, index, delete, bulk, update e mget) aceitam um parâmetro de roteamento chamado roteamento, por meio do qual podemos customizar o mapeamento de documentos para shards. Um parâmetro de roteamento personalizado pode ser usado para garantir que todos os documentos relacionados (como todos os documentos pertencentes ao mesmo usuário) sejam armazenados no mesmo fragmento.

  Esta parte será explicada em detalhes nos capítulos subsequentes.

4.3 Controle de fragmentação

Ao descrever esta seção, use o seguinte índice de teste de cluster em um ambiente de cluster, que possui três fragmentos primários e uma réplica .

Neste cluster, cada nó tem a capacidade de lidar com qualquer solicitação. Cada nó conhece a localização de qualquer documento no cluster, portanto as solicitações podem ser encaminhadas diretamente para o nó necessário. Nos exemplos a seguir, enviarei todas as solicitações para o nó-9201, que é chamado de nó coordenador.

Nota: No trabalho, para obter balanceamento de carga, todos os nós do cluster geralmente são pesquisados ​​para que possam transportar solicitações em conjunto, em vez de enviar todas as solicitações para o mesmo nó.

4.3.1 Processo de escrita (processo aproximado)

No Elasticsearch, as solicitações para adicionar, excluir e modificar documentos (completos) pertencem ao processo de gravação. O processo de gravação deve ser concluído no fragmento primário antes de ser sincronizado com o fragmento de réplica.

Por exemplo, solicitação:

COLOQUE/EXCLUIR http://localhost:9200/cluster-test/_doc/1001

Adicione, atualize totalmente ou exclua um documento específico

Se a chave primária não for especificada ao adicionar um documento, o ES irá gerar automaticamente a chave primária e realizar cálculos de roteamento com base na chave primária gerada automaticamente.

A seguir, utilizamos um exemplo para aprender como o processo de escrita no Elasticsearch é realizado no cluster ES.

Suponha que enviamos solicitações para adicionar, excluir e modificar documentos (completos) para o nó-9201, então o ES fará o seguinte processamento:

1. node-9201 usa o _id do documento (se o parâmetro de roteamento for especificado, o parâmetro correspondente será usado) para realizar o cálculo da rota e obter o fragmento ao qual o documento pertence. Por exemplo, se pertencer ao fragmento 0, então o nó O nó -9201 encaminhará a solicitação para o nó-9202 (porque o fragmento primário 0 está no nó-9202).
2. node-9202 lida com a solicitação no fragmento primário 0. Se for bem-sucedido, ele encaminhará a solicitação para o nó 9203 e permitirá que o fragmento de réplica 0 faça o mesmo processamento. Quando o fragmento de réplica 0 for processado com sucesso, o nó 9202 será notificado e, em seguida, o nó 9202 notificará o resultado bem-sucedido do processamento .nó-9201.
3. node-9201 retorna o resultado da solicitação do cliente.

O diagrama específico é o seguinte:

Quando o cliente recebe uma resposta bem-sucedida, as alterações do documento foram executadas no fragmento primário e em todos os fragmentos de réplica, e as alterações são seguras. Claro, o Elasticsearch também fornece alguns parâmetros para os usuários intervirem neste processo (o que pode melhorar ainda mais o desempenho em detrimento da segurança dos dados).É claro que esses parâmetros raramente são usados ​​porque o Elasticsearch já é rápido o suficiente.

A tabela a seguir lista alguns parâmetros e seus significados que podem intervir neste processo.

parâmetro	significado
consistência	consistência, isto é, consistência . O valor do parâmetro de consistência pode ser definido como um (desde que o status do fragmento primário seja normal, a operação de gravação é executada), todos (o status de todos os fragmentos primários e fragmentos de réplica deve ser normal antes que a operação de gravação seja executada) e quorum (grande A maioria dos shards está em estado normal e operações de gravação são permitidas), o valor padrão é quorum, o que significa que nas configurações padrão, mesmo antes de tentar executar uma operação de gravação, o shard primário exigirá um número especificado ( quorum) A operação de gravação será executada somente quando a cópia fragmentada estiver em um estado ativo e disponível. Isso evita operações de gravação quando ocorre uma falha na rede, o que pode levar à inconsistência de dados. A fórmula de cálculo para a quantidade especificada (quorum) é int((primary + number_of_replicas) / 2) + 1 . Entre eles, number_of_replicas refere-se ao número de réplicas definidas nas configurações do índice, não ao número de réplicas atualmente ativas.
tempo esgotado	O que acontece se não houver fragmentos de réplica suficientes? O Elasticsearch aguardará o aparecimento de mais fragmentos; por padrão, aguardará até 1 minuto. Os usuários podem ajustar o tempo de espera usando o parâmetro timeout.

Nota: Ao criar um novo índice, o número de réplicas de índice é padronizado como 1, o que significa que duas réplicas de fragmentos ativas devem ser necessárias para atender ao número especificado . Essas configurações padrão nos impedirão de realizar qualquer operação de gravação em um único nó. Portanto, o ES estipula que a quantidade especificada só terá efeito quando number_of_replicas for maior que 1 .

4.3.2 Processo de leitura (processo aproximado)

Processo de leitura, o que é discutido aqui é o processo de leitura de documentos específicos com base no roteamento ou ID. (Nota para distingui-lo do processo de pesquisa de dados).

Por exemplo, a solicitação é GET http://localhost:9201/cluster-test/_doc/1001

A seguir, utilizamos um exemplo para aprender como é realizado o processo de leitura no Elasticsearch no cluster ES.

Suponha que enviamos uma solicitação de leitura de dados para o nó-9201, então o ES fará o seguinte processamento:

1. node-9201 executa cálculo de roteamento no documento e obtém o fragmento ao qual o documento pertence.Por exemplo, ele pertence ao fragmento 0 e usará o algoritmo de pesquisa aleatória round-robin para selecionar aleatoriamente um entre o fragmento primário 0 e todos os seus fragmentos de réplica. , deixe a solicitação de leitura balancear a carga e o nó node-9201 encaminhará a solicitação para um nó específico, como o node-9203.

   Use o parâmetro de roteamento ou use diretamente o id para calcular a rota e ler os dados.

2. O nó-9203 processa a solicitação no fragmento de réplica 0 e retorna os resultados da consulta para o nó-9201.

3. node-9201 retorna os resultados da consulta ao cliente.

O diagrama específico é o seguinte:

4.3.3 Processo de atualização (processo aproximado)

A atualização parcial de um documento combina os processos de leitura e escrita explicados anteriormente.

A seguir, utilizamos um exemplo para aprender como o processo de atualização no Elasticsearch é realizado no cluster ES.

Suponha que enviamos uma solicitação para atualizar dados para o nó-9201, então o ES fará o seguinte processamento:

1. O nó node-9201 realiza cálculo de rota no documento e obtém o fragmento ao qual o documento pertence, por exemplo, pertence ao fragmento 0.

2. O nó node-9201 encaminha a solicitação para o nó node-9202 (o fragmento primário 0 está neste nó).

3. O nó node-9202 processa a solicitação de atualização, lê o documento, modifica os dados JSON no campo _source e tenta reindexar o documento (se outro processo estiver modificando o documento neste momento, a etapa 3 será repetida após o retry_on_conflict o número de vezes foi excedido) desistir).

   Reindexar o documento mencionado acima significa, na verdade, marcar a versão antiga do documento para exclusão (ou seja, marcar a versão antiga do documento no arquivo .del), gerar uma nova versão do documento e escrever esta nova versão do documento.

4. Se o nó node-9202 atualizar o documento com sucesso, ele encaminhará a nova versão do documento para o nó node-9203, e o nó node-9203 reconstruirá o índice (índice invertido) para a nova versão do documento.

   Nesta etapa, o nó secundário fará a mesma coisa que o nó primário. (Marque a versão antiga do documento como excluída e escreva a nova versão do documento)

5. Depois que o nó node-9203 for atualizado com êxito, uma resposta será retornada ao nó node-9202.

6. O nó node-9202 retornará o resultado da atualização bem-sucedida para o nó node-9201.

7. O nó node-9201 retorna os resultados ao cliente.

O diagrama específico é o seguinte:

Nota :

Quando o fragmento primário encaminha alterações para o fragmento de réplica, ele não encaminha solicitações de atualização. Em vez disso, encaminha uma nova versão do documento completo. Lembre-se de que essas alterações serão encaminhadas para os fragmentos de réplica de forma assíncrona e não há garantia de que chegarão na mesma ordem em que foram enviadas. Se o Elasticsearch apenas encaminhar solicitações de alteração, as alterações poderão ser aplicadas na ordem errada, resultando em documentos corrompidos.

4.3.4 Processo de operação multidocumento (processo bruto)

O processo de operação de vários documentos aqui se refere a solicitações mget e em massa.

Fluxo de processamento da solicitação mget:

1. O cliente envia uma solicitação mget para o nó node-9201.

2. O nó node-9201 cria solicitações de busca de vários documentos para cada nó e, em seguida, encaminha essas solicitações para todos os nós em paralelo, como node-9202 e node-9203.

3. Depois que o nó node-9202 e o nó node-9203 processarem a solicitação, o resultado será respondido ao nó node-9201.

4. O nó node-9201 responde ao cliente com o resultado da solicitação.

   Todo o processo equivale a um lote de solicitações get. Para o processamento das solicitações por cada nó, consulte o processo de leitura apresentado anteriormente.

Fluxo de processamento de solicitação em massa:

1. O cliente envia uma solicitação em massa para o nó node-9201.

2. O nó node-9201 cria solicitações em lote para cada nó e encaminha essas solicitações em paralelo para cada nó que contém o fragmento primário.

3. Depois que todos os nós tiverem processado a solicitação, os resultados serão respondidos ao nó node-9201.

4. O nó node-9201 responde ao cliente com o resultado da solicitação.

   Todo o processo equivale a um lote de solicitações novas, excluídas e atualizadas. Para o processamento das solicitações por cada nó, consulte o processo de escrita apresentado anteriormente.

4.4 Princípio de fragmentação

4.4.1 Pesquisa documental (pesquisa por parágrafo)

• Índice invertido imutável

  A recuperação antecipada de texto completo criaria um grande índice invertido para toda a coleção de documentos e o gravaria no disco.Uma vez que um índice invertido precisa ser criado para um novo documento, todo o índice invertido precisa ser substituído, ou seja, o índice invertido é substituído. Uma vez gravado no disco, ele não pode ser alterado e só pode ser totalmente substituído.

  As vantagens disso são:

  1. Não é necessário bloqueio. Se você nunca atualizar o índice, não precisará se preocupar com vários processos modificando dados ao mesmo tempo.

  2. Depois que o índice é lido no cache do sistema de arquivos do kernel, ele permanece lá devido à sua imutabilidade . Contanto que haja o suficiente no cache do sistema de arquivos

     espaço, a maioria das solicitações de leitura solicitará memória diretamente sem atingir o disco. Isso proporciona um grande aumento de desempenho.

  3. Escrever um único índice invertido grande permite que os dados sejam compactados, reduzindo a quantidade de E/S de disco e o uso do índice que precisa ser armazenado em cache na memória.

  As desvantagens disso também são muito óbvias: se você precisar tornar um novo documento pesquisável, será necessário reconstruir todo o índice invertido, o que impõe um grande limite à quantidade de dados que um índice invertido pode conter, ou o índice existe. limitações significativas sobre a frequência com que pode ser atualizado.

• Atualizar dinamicamente o índice invertido

  Para atualizar o índice invertido e ao mesmo tempo manter a imutabilidade do índice invertido, o Elasticsearch adota o método de complementar o índice invertido para refletir as modificações recentes, adicionando novos índices suplementares em vez de reescrever diretamente todo o índice invertido . Durante a recuperação, cada índice invertido será consultado por vez e os resultados serão mesclados após a conclusão da primeira consulta. Isso pode evitar a perda de desempenho causada pela reconstrução frequente do índice invertido.

• Pesquisar por segmento

  Elasticsaerch é desenvolvido baseado em Lucene. Tem o conceito de busca por segmento . Cada segmento em si é um índice invertido. Além dos segmentos, existe também o conceito de ponto de compromisso , que registra todos os segmentos atualmente disponíveis.O novo índice invertido suplementar mencionado acima é na verdade um novo segmento.

  A relação entre segmentos e pontos de envio é mostrada na figura abaixo

• Escrevendo dados sob pensamento de segmentação

  Quando um novo documento é adicionado ao índice, ele passará pelo seguinte processo ( aqui nos concentramos apenas no uso de segmentos e pontos de submissão )

  1. Novos documentos são adicionados ao cache de memória.

     O diagrama esquemático do ponto de envio, segmento e cache de memória neste momento é o seguinte

     

  2. De tempos em tempos [por padrão, após um determinado período de tempo, ou quando a quantidade de dados na memória atingir um determinado estágio, os dados serão enviados ao disco em lotes. ( Os detalhes específicos serão explicados posteriormente no princípio subjacente do processo de escrita )], o cache é enviado

     • Um novo segmento (índice invertido suplementar) é gravado no disco

     • Um novo ponto de confirmação contendo o novo segmento é gerado e gravado no disco

       Uma vez que um segmento tem um ponto de commit, significa que o segmento só tem permissão de leitura e perdeu a permissão de gravação; pelo contrário, quando o segmento está na memória, ele só tem permissão para escrever dados, mas não tem permissão para ler dados , então não pode ser recuperado.

     • O disco está sincronizado - todas as gravações que aguardam no cache do sistema de arquivos são liberadas para o disco para garantir que sejam gravadas em arquivos físicos

  3. Um novo segmento é aberto para que os documentos nele contidos possam ser recuperados

  4. O cache de memória está limpo, aguardando o recebimento de novos documentos

     O diagrama esquemático do ponto de envio, segmento e cache de memória neste momento é o seguinte

     

• Excluindo/atualizando dados sob pensamento de segmentação

  Quando os dados precisam ser excluídos, como o segmento onde os dados estão localizados é imutável, o documento não pode ser removido diretamente do segmento antigo.Neste momento, cada ponto de envio conterá um arquivo .del, que armazena o ID dos dados excluídos. ( exclusão lógica )

  Quando os dados precisarem ser atualizados, a operação de exclusão será realizada primeiro e depois a nova operação será realizada, ou seja, os dados antigos serão registrados primeiro no arquivo .del e, em seguida, um dado atualizado será adicionado para o novo segmento.

• Consultar dados com base no pensamento de segmentação

  Consulte os dados que atendem às condições de consulta em todos os segmentos, depois mescle os conjuntos de resultados da consulta em cada segmento para obter um grande conjunto de resultados e, em seguida, remova os dados excluídos registrados no arquivo .del e devolva-os ao cliente.

4.4.2 Pesquisa quase em tempo real

Pode-se observar no novo processo de dados sob a ideia de segmentação introduzida na seção anterior que quando um novo documento é gravado, os dados ainda estão no cache de memória.Neste momento, esses dados não podem ser consultados, então a consulta do Elasticsearch Ele é pesquisado quase em tempo real .

Ao confirmar um novo segmento no disco, você precisa usar a chamada de sistema fsync para garantir que os dados sejam gravados fisicamente no disco para que os dados não sejam perdidos após uma queda de energia. No entanto, o fsync é muito caro. Se o fsync for usado para gravar dados fisicamente no disco sempre que dados novos/modificados forem adicionados, isso causará uma enorme perda de desempenho.

Uma abordagem mais leve é ​​usada no Elasticsearch para tornar um documento recuperável, ou seja, fsync é removido do processo desde o momento em que o documento é gravado até quando ele pode ser recuperado, para melhorar o desempenho. Para atingir esse objetivo, entre o Elasticsearch e o disco está o cache do sistema de arquivos do sistema operacional (OS Cache) .

Entre o cache de memória do Elasticsearch (Memória) e o disco rígido (Disco) está o cache do sistema de arquivos do sistema operacional (Cache do SO)

Conforme descrito na seção anterior, o documento no buffer de índice de memória será gravado em um novo segmento, mas aqui o novo segmento será gravado primeiro no cache do sistema de arquivos** (esta etapa será menos dispendiosa) e será liberado para o disco em lotes posteriormente (esta etapa é relativamente cara)**. Desde que o arquivo já esteja no cache do sistema de arquivos, ele pode ser aberto e lido como qualquer outro arquivo, ou seja, pode ser recuperado.

Conforme apresentado acima, o processo de gravação de dados no buffer de memória para o cache do sistema de arquivos é chamado de atualização . Esta operação é executada por padrão a cada segundo ou quando os dados no buffer de memória atingem uma certa quantidade de dados (seção 4.4.1 Como descrito em), é por isso que dizemos que o Elasticsearch é uma pesquisa quase em tempo real (as alterações no documento serão visíveis após um segundo, portanto não é em tempo real, mas quase em tempo real).

Obviamente, o Elasticsearch fornece uma API de atualização para que os usuários executem manualmente operações de atualização, como enviar solicitação/nome do índice/_refresh.

Embora a liberação seja uma operação muito mais leve do que a confirmação, ela ainda apresenta uma sobrecarga de desempenho. As atualizações manuais são úteis ao escrever testes, mas não faça isso sempre que indexar um documento em um ambiente de produção. Em vez disso, nossos aplicativos precisam estar cientes da natureza quase em tempo real do Elasticsearch e aceitar suas deficiências.

Alguns cenários não exigem atualização a cada segundo (como adicionar um grande número de arquivos de log ao ES), como atender às necessidades dos cenários acima?

Podemos ajustar o intervalo de tempo para realizar operações de atualização definindo o update_interval do índice.

{
    
    
 "settings": {
    
    
 "refresh_interval": "30s" 
 }
}

refresh_interval pode atualizar dinamicamente os índices existentes. Em um ambiente de produção, ao criar um novo índice grande, você pode desativar as atualizações automáticas e desligá-las quando começar a usar o índice.

# 关闭自动刷新
PUT /索引名/_settings
{
    
     "refresh_interval": -1 } 
# 每一秒刷新
PUT /索引名/_settings
{
    
     "refresh_interval": "1s" }

Neste momento, o processo de escrita do Elasticsearch é mostrado na figura abaixo. ( O objetivo deste fluxograma é apresentar a você as ideias de design do processo de escrita do Elasticsearch passo a passo. O fluxograma aqui não está completo )

4.4.3 Mudanças persistentes

Na seção anterior, apresentamos o mecanismo de consulta leve do Elasticsearch que grava dados de documentos do cache de memória no cache do sistema de arquivos por meio da operação de atualização. Nesse processo, a chamada do sistema fsync é removida. Se fsync não for usado para gravar os dados de Quando o cache do sistema de arquivos é gravado no disco rígido (chamamos a operação de gravação dos dados no cache do sistema de arquivos no disco rígido flush ), não há garantia de que ele ainda existirá após uma queda de energia ou mesmo a saída do programa normalmente (ou seja, não há persistência) .

Para garantir a confiabilidade, o Elasticsearch precisa garantir que as alterações de dados sejam persistidas no disco. Para atender a esse requisito, o Elasticsearch adiciona um translog (log de transações) como mecanismo de compensação para evitar perda de dados. Todas as alterações que não foram feitas são registrado no translog. Os dados persistiram no disco.

Em relação ao translog , você precisa entender as três questões a seguir.

• Quando os dados são gravados no translog?

  Quando os dados são gravados no cache de memória, uma cópia dos dados será anexada ao translog. ( Esta parte será apresentada em detalhes posteriormente )

• Quando usar dados do translog?

  Quando o Elasticsearch é iniciado, ele não apenas carrega os segmentos persistentes com base no ponto de envio mais recente, mas também persiste novamente os dados não persistentes no disco com base nos dados do translog.

• Quando os dados no translog devem ser apagados?

  Quando os dados no cache do sistema de arquivos são descarregados no disco, o translog antigo é excluído e um novo translog em branco é gerado.

  **Por padrão, uma operação de liberação será executada a cada 30 minutos ou quando o translog for muito grande (o padrão é 512 MB). **Normalmente, a atualização automática é suficiente. Quando o Elasticsearch tenta restaurar ou reabrir um índice, ele precisa reproduzir todas as operações no translog, portanto a recuperação será mais rápida se o log for mais curto.

  A capacidade máxima do translog pode ser especificada por meio do parâmetro de configuração index.translog.flush_threshold_size .

Depois de adicionar translog, o processo de escrita do Elasticsearch é mostrado na figura abaixo (o processo detalhado será explicado em detalhes na seção sobre os princípios subjacentes do processo de escrita)

Embora o translog seja usado para evitar a perda de dados, também existe o risco de perda de dados .

• Explicação detalhada de como escrever translog

  Como pode ser visto no fluxograma de gravação acima, o translog tem uma cópia no cache de memória e no disco. Ele é confiável apenas quando o translog na memória é liberado para o disco por meio da chamada do sistema fsync.

  Existem dois modos para executar operações de liberação de translog - assíncrono e síncrono. O padrão é o modo síncrono . Este modo pode ser ajustado através do parâmetro index.translog.durability , e o tempo para execução automática de liberação pode ser controlado através do parâmetro index.translog .sync_interval .intervalo .

  #异步模式
  index.translog.durability=async
  #同步模式
  index.translog.durability=request
  

  Quando estiver no modo síncrono , por padrão, uma operação fsync será executada após cada solicitação de gravação. Esse processo ocorre no fragmento primário e no fragmento de réplica. Isso significa que toda a solicitação é sincronizada com o fragmento primário e o fragmento de réplica. O cliente não obterá uma resposta 200 até que o translog esteja no disco da fatia. (Ou seja, neste modo, se a solicitação de gravação for bem-sucedida, significa que esses dados foram gravados no translog do disco, o que garante a confiabilidade dos dados).

  Quando estiver no modo assíncrono , a operação fsync será executada uma vez a cada 5 segundos por padrão, e esta ação é assíncrona. Isso significa que mesmo que sua solicitação de gravação obtenha uma resposta 200, isso não significa que os dados desta solicitação foram descartados .disk para o translog no disco, ou seja, esta operação não é confiável. (Se a energia for cortada dentro de cinco segundos, esta parte dos dados será perdida).

  Perceber

  A operação de liberação de translog do Elasticsearch é padronizada para o modo síncrono. Embora uma operação de liberação de translog seja executada toda vez que os dados são modificados, o custo é muito menor do que executar uma operação de liberação de segmento toda vez que os dados são modificados. Portanto, o mecanismo de compensação de translog é usado. É uma solução que equilibra desempenho e segurança de dados. A menos que haja requisitos especiais, o modo síncrono é usado por padrão .

4.4.4 Fusão de segmentos

• Introdução e processo

  Na Seção 4.4.2, apresentamos que a operação de atualização executada a cada segundo criará um novo segmento. Após um longo período de acumulação, haverá um grande número de segmentos no índice. Quando o número de segmentos for muito grande, ele não apenas ocupará muitos recursos do servidor, mas também afetará o desempenho da recuperação.

  Conforme mencionado anteriormente, toda vez que você pesquisa, os dados que atendem às condições de consulta em todos os segmentos serão consultados e, em seguida, os conjuntos de resultados consultados em cada segmento serão mesclados, mais lenta será a recuperação.

  Elasticsearch usa fusão de segmentos para resolver o problema de muitos segmentos.Há um processo em segundo plano no Elasticsearch que é especificamente responsável pela fusão de segmentos e executará operações de fusão de segmentos regularmente.

  O processo de operação de fusão de segmentos é o seguinte:

  1. Mesclar vários segmentos pequenos em um novo segmento grande. Durante a mesclagem, documentos excluídos (documentos correspondentes aos IDs de documentos armazenados no arquivo .del) ou versões antigas de documentos atualizados não serão gravados no novo.
  2. Libere o novo arquivo de segmento no disco
  3. Identifique todos os novos arquivos de segmento neste ponto de confirmação e exclua arquivos de segmento antigos e mesclados
  4. Abra um novo arquivo de segmento para uso de pesquisa
  5. Após todas as solicitações de recuperação terem sido transferidas dos arquivos de segmentos pequenos para os arquivos de segmentos grandes, exclua os arquivos de segmentos antigos.

  O processo acima é transparente para os usuários e o Elasticsearch o executará automaticamente ao indexar e pesquisar documentos. Os segmentos a serem mesclados podem ser índices que foram enviados no disco ou segmentos que ainda não foram enviados na memória.Durante o processo de mesclagem, as funções atuais de indexação e pesquisa não serão interrompidas .

• Impacto no desempenho da fusão de segmentos

  A partir da introdução acima ao processo de fusão de segmentos, podemos ver que o processo de fusão de segmentos não envolve apenas a leitura de segmentos e a geração de novos segmentos, mas também envolve a operação de liberação de segmentos.Portanto, se a fusão de segmentos não for controlada, Isso consumirá muitos recursos de E/S e CPU e também afetará o desempenho da pesquisa.

  No Elasticsearch, por padrão, apenas dez segmentos podem ser mesclados por vez. Se a capacidade do segmento for superior a 5 GB, ele não participará da fusão de segmentos e a velocidade padrão do encadeamento de mesclagem é de 20 MB/S.

  Podemos ajustar as regras de mesclagem de segmentos por meio dos seguintes parâmetros.

  #更改配速为100MB/s
  {
        
        
      "persistent" : {
        
        
          "indices.store.throttle.max_bytes_per_sec" : "100mb"
      }
  }
  #设置优先被合并的段的大小，默认为2MB
  index.merge.policy.floor_segment
  #设置一次最多合并的段数量，默认为10个
  index.merge.policy.max_merge_at_once
  #设置可被合并的段的最大容量，默认为5GB
  index.merge.policy.max_merged_segment
  

4.4.5 Explicação detalhada do processo de escrita

Na seção 4.2.8.1, aprendemos o processo geral do processo de gravação. Aprendemos como o Elasticsearch processa solicitações de gravação iniciadas pelo cliente em um ambiente de cluster como um todo. Nesta seção, o blogueiro resumirá o processo de escrita com base no processamento específico de cada nó após receber a solicitação de gravação.

O processo de escrita é resumido da seguinte forma:

1. O cliente envia uma solicitação de gravação para o nó coordenador
2. O nó coordenador executa o cálculo de roteamento (consulte a seção 4.2.7 para detalhes) com base no parâmetro de roteamento (se não for especificado, o padrão é o ID do documento) e calcula a localização do fragmento primário ao qual o documento pertence.
3. O nó coordenador encaminha a solicitação de gravação para o nó onde o fragmento primário está localizado.
4. Após o nó onde o fragmento primário está localizado receber a solicitação de gravação, ele entra no processo de gravação de um único nó.
5. Após o nó onde o shard primário está localizado ter processado a solicitação de gravação, ele encaminhará a solicitação de gravação em paralelo para todos os nós onde seus fragmentos de réplica estão localizados. Após esses nós receberem a solicitação, eles farão o mesmo processamento.
6. Depois que os nós onde todos os fragmentos de réplica estão localizados processarem a solicitação de gravação, os resultados do processamento serão retornados ao nó onde o fragmento primário está localizado, e o nó onde o fragmento primário está localizado retornará os resultados do processamento ao nó coordenador.
7. O nó coordenador retorna os resultados ao cliente.

O processo de gravação detalhado de um único nó no Elasticsearch é mostrado na figura abaixo.

A descrição do texto é a seguinte:

1. Grava dados no cache de memória (**buffer de índice)**

2. Anexar dados ao log de transações ( translog )

3. Por padrão , a operação de atualização é executada uma vez por segundo para atualizar os dados no cache de memória para o **Cache do Sistema de Arquivos (Cache do SO)**, gerar um segmento ( segment ) e abrir o segmento para pesquisa do usuário e, em ao mesmo tempo, o cache de memória ( buffer de índice ).

4. Por padrão, o translog na memória é gravado ( flush ) no disco por meio da chamada do sistema fsync sempre que os dados são gravados .

   O modo síncrono consiste em sincronizar com o disco sempre que os dados são gravados.

   O modo assíncrono é fsync para o disco a cada 5 segundos

5. Por padrão, a cada 30 minutos ou após o tamanho do translog exceder 512M , uma liberação será executada para gravar os dados do sistema de arquivos no disco.

   1. Gere novos segmentos e grave no disco
   2. Gere um novo ponto de confirmação contendo o novo segmento e grave-o no disco
   3. Exclua o translog antigo e gere um novo translog

6. O Elasticsearch iniciará o processo de mesclagem , mesclará segmentos pequenos e médios em segundo plano e reduzirá o número de segmentos de índice. Esse processo será executado no cache e no disco do sistema de arquivos.

4.4.6 Explicação detalhada do processo de leitura

O processo de leitura é resumido da seguinte forma:

1. O cliente envia uma solicitação de leitura ao nó de coordenação
2. O nó coordenador executa o cálculo de roteamento (consulte a seção 4.2.7 para detalhes) com base no parâmetro de roteamento (se não for especificado, o padrão é o ID do documento) e calcula o local do fragmento ao qual o documento pertence.
3. Use o algoritmo de pesquisa aleatória round-robin para selecionar aleatoriamente um dos fragmentos aos quais o documento pertence (fragmento primário ou fragmento de réplica) e encaminhar a solicitação para o nó onde o fragmento está localizado.
4. Após o nó receber a solicitação, ele entra no processo de leitura de um único nó.
5. Este nó retorna os resultados da consulta ao nó coordenador.
6. O nó de coordenação retorna os resultados da consulta ao cliente.

O processo de leitura de um único nó do Elasticsearch é mostrado na figura abaixo

A descrição do texto é a seguinte:

1. O nó recebe a solicitação de leitura de dados
2. Consulte os dados do cache translog de acordo com o campo doc id na solicitação. Se os dados forem consultados, o resultado será retornado diretamente.
3. Se nenhum resultado for encontrado na etapa 2, os dados serão consultados a partir do translog no disco. Se os dados forem consultados, o resultado será retornado diretamente.
4. Se nenhum resultado for encontrado na etapa 3, os resultados serão consultados em cada segmento do disco. Se os dados forem encontrados, os resultados serão retornados diretamente.
5. Após as etapas anteriores, se nenhum resultado for encontrado, será retornado nulo.

Observe que quando o Elasticsearch lê os dados, ele primeiro tentará obtê-los do translog e depois obtê-los do segmento . Isso ocorre porque, como mencionamos anteriormente, as operações de escrita/modificação/exclusão de todos os documentos serão registradas no translog primeiro. Em seguida, ele é gravado no segmento por meio de operações de atualização e liberação. Portanto, os dados mais recentes do documento serão registrados no translog. Portanto, se os dados de destino forem encontrados no translog, basta retorná-los diretamente. Caso contrário, tente obter do segmento.

4.4.7 Explicação detalhada do processo de pesquisa

O processo de pesquisa aqui se refere à pesquisa . Tenha cuidado para distingui-lo do processo de leitura apresentado acima. O processo de leitura refere-se a pegar o ID do documento para pesquisar dados por meio do índice de encaminhamento . O processo de pesquisa está relacionado ao processo de pesquisa e ao searchType .

O valor padrão de searchType é Query e depois Fetch

Pode ser brevemente entendido como: primeiro obtenha o ID do documento por meio do índice invertido e, em seguida, encontre os dados por meio do índice direto com base no ID do documento.

Existem quatro searchTypes, como segue:

• Consultar e buscar

  As solicitações de consulta são emitidas para todos os fragmentos do índice e, quando cada fragmento retorna, o documento do elemento (documento) e as informações de classificação calculada são retornados juntos.

  Este método de pesquisa é o mais rápido. Porque, em comparação com os métodos de pesquisa a seguir, esse método de consulta só precisa consultar o fragmento uma vez. No entanto, a soma do número de resultados retornados por cada fragmento pode ser n vezes o tamanho exigido pelo usuário.

• Consultar e buscar (padrão)

  Este modo de pesquisa é um processo de duas etapas.

  1. Faça uma solicitação a todos os fragmentos e cada fragmento retornará apenas informações "suficientes" (estimadas como relacionadas à classificação, classificação e pontuação) (observação: o documento do documento não está incluído) e, em seguida, reordenará e somará de acordo com a pontuação retornado por cada fragmento.Classificação, pegue os documentos de primeiro tamanho.
  2. Vá para o fragmento relevante para obter o documento. O documento retornado desta forma é igual ao tamanho solicitado pelo usuário.

• Consulta e busca DFS

  Este método tem mais uma etapa inicial de frase de dispersão do que o primeiro método. Com esta etapa, a precisão da pontuação pode ser maior.

• Consulta DFS e depois busca

  Este método tem mais uma etapa inicial de frase de dispersão do que o segundo método.

Geralmente, o modo padrão pode ser usado.

A seguir, aprenderemos o processo de pesquisa usando o modo Query Then Fetch .

O processo de pesquisa é dividido em duas etapas, Query (estágio de consulta) e Fetch (estágio de obtenção) .

• Consulta

  1. Depois que o nó de coordenação recebe a solicitação de pesquisa, ele transmite a solicitação para todos os fragmentos (incluindo fragmentos primários e fragmentos de réplica).

  2. Cada fragmento realiza a pesquisa de forma independente, usa o índice invertido para correspondência e cria uma fila de resultados priorizados (incluindo o ID do documento e todos os valores do campo envolvido na classificação, como _score).

     Neste estágio, o cache de segmento no cache do sistema operacional será consultado . Neste momento, alguns dados ainda podem estar na memória, então o Elasticsearch é uma pesquisa quase em tempo real. (Você pode consultar a introdução anterior para entender)

  3. Cada fragmento retorna sua fila de resultados priorizados ao nó de coordenação.

  4. O nó de coordenação cria uma nova fila de resultados de classificação prioritária, classifica os resultados globais e obtém uma lista de resultados de classificação (incluindo todos os valores de campo classificados e IDs de documentos).

  5. Entre no estágio de busca.

• Buscar

  1. O nó coordenador envia várias solicitações GET aos fragmentos relevantes com base na lista de resultados classificada.
  2. Após cada fragmento receber a solicitação GET, ele executa o processo de leitura descrito acima, obtém informações detalhadas do documento com base no ID do documento e as retorna ao nó coordenador.
  3. O nó coordenador retorna os resultados ao cliente.

referência

[Silicon Valley] Tutorial do ElasticSearch desde o início até o domínio (com base nos novos recursos da pilha de tecnologia ELK elasticsearch 7.x + 8.x)