Query em um datastream

Elastic In Your Native Tongue Elastic em Português - Brasil
1

Srs, bom dia.

Atualmente usamos uma convenção na construção dos índices para conter uma quebra mensal dos documentos.
Dessa forma, por convenção, consigo orientar em uma aplicação QUAL o indice deve conter o documento com base em dois parametros de datas (startDate, endDate). Isso otimiza a consulta, evitando de fazer uma query que bata em todos os indices/shards.

A dúvida é: é possível fazer algo do genero com datastream? Não queria me preocupar em ter mais a responsabilidade de quebrar indices mensalmente, logo, o datastream é uma feature que vem ajudar nesse aspecto, mas tenho dúvidas quando a forma de busca otimizada.

É possível orientar uma consulta a um datastream para bater em menos shards com base em um critério de data?

1 Like
2

Olá Abenas,

O Elasticsearch já vai fazer este tipo de otimização. Assumindo que os índices possuem um @timestamp do tipo date ou date_nanos (o que é obrigatório no caso de data streams), a query será otimizada para buscar apenas nos índices que possivelmente pode conter a data sendo buscada (assumindo que a query inclua um filtro no campo @timestamp).

Espero ter respondido!

Abs!

2 Likes
3

Thiago,

Segui exatamente o exemplo da doc (o my-data-stream) para reproduzir este cenário de teste. Criamos um app que faz varios bulks para o ES para popular os dados, incrementando o @timestamp progressivamente, logo, temos um data stream com vários indices (36 shards) com ranges de data diferentes.

Ao realizar a query abaixo, no response sempre vem no response que estou atingindo todos os shards.

{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2019-09-22T06:23:40.000",
        "lte": "2019-09-22T06:23:50.000"
      }
    }
  }
}

Estou fazendo algo errado?

Fiz outra query usando filtro de range no timestamp e especificando o _id, tive o mesmo resultado:

{
  "query": { 
    "bool": { 
      "must": [
        { "match": { "_id": "1oCVInQBmc8AWu9kk_P9"        }}
      ],
      "filter": [ 
        { "range":  { "@timestamp": {"gte": "2019-09-22T06:23:40.000","lt": "2019-09-22T06:25:40.000"}}}
      ]
    }
  }
}

Em ambos os casos, tive no response (fragmento):

"took": 6,
  "timed_out": false,
  "_shards": { - 
    "total": 36,
    "successful": 36,
    "skipped": 0,
    "failed": 0
  }
1 Like
5

Olá Abenas,

A questão aqui é que a otimização, por padrão, só acontece quando a query atinge 128 ou mais shards. Você pode mudar esse comportamento passando o parâmetro pre_filter_shard_size na busca (veja mais sobre o parâmetro aqui)

Você pode fazer um teste e passar o parâmetro como pre_filter_shard_size=1, desta forma o Elasticsearch sempre vai tentar otimizar se atingir mais de um shard. Neste caso, veja que no resultado o campo skipped será maior que 0.

Abs!

6

Obrigado pelo retorno Thiago.

Fizemos alguns testes para nosso case, o impacto de bater em todos os índices associados ao datastream não trouxe um resultado negativo no cluster, dessa forma, vamos seguir com esse padrão mesmo.