# Query em um datastream

**URL:** <https://discuss.elastic.co/t/query-em-um-datastream/246123>\
**Category:** Elastic em Português - Brasil\
**Created:** [August 24, 2020, 1:22pm UTC](https://discuss.elastic.co/t/query-em-um-datastream/246123 "2020-08-24T13:22:40Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![abenas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/abenas/32/74406_2.png) [@abenas](https://discuss.elastic.co/u/abenas)\
**Post date:** [August 24, 2020, 1:22pm UTC](https://discuss.elastic.co/t/query-em-um-datastream/246123/1 "2020-08-24T13:22:40Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![thiago](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thiago/32/32096_2.png) [@thiago](https://discuss.elastic.co/u/thiago)\
**Post date:** [August 25, 2020, 3:50pm UTC](https://discuss.elastic.co/t/query-em-um-datastream/246123/2 "2020-08-25T15:50:51Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![abenas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/abenas/32/74406_2.png) [@abenas](https://discuss.elastic.co/u/abenas)\
**Post date:** [August 25, 2020, 7:34pm UTC](https://discuss.elastic.co/t/query-em-um-datastream/246123/3 "2020-08-25T19:34:28Z")

</div>

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.

```auto
{
  "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:

```auto
{
  "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):

```auto
"took": 6,
  "timed_out": false,
  "_shards": { - 
    "total": 36,
    "successful": 36,
    "skipped": 0,
    "failed": 0
  }

```

---

<div class="post-metadata">

**Author:** ![thiago](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thiago/32/32096_2.png) [@thiago](https://discuss.elastic.co/u/thiago)\
**Post date:** [August 31, 2020, 9:54pm UTC](https://discuss.elastic.co/t/query-em-um-datastream/246123/5 "2020-08-31T21:54:20Z")

</div>

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](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html))

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!

---

<div class="post-metadata">

**Author:** ![abenas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/abenas/32/74406_2.png) [@abenas](https://discuss.elastic.co/u/abenas)\
**Post date:** [September 14, 2020, 6:58pm UTC](https://discuss.elastic.co/t/query-em-um-datastream/246123/6 "2020-09-14T18:58:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [November 4, 2022, 8:11am UTC](https://discuss.elastic.co/t/query-em-um-datastream/246123/7 "2022-11-04T08:11:11Z")

</div>