# Do I need a nested query or foreach or a create a new index?

**URL:** <https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968>\
**Category:** Kibana\
**Created:** [February 1, 2022, 5:57pm UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968 "2022-02-01T17:57:10Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![clearbluelou](https://avatars.discourse-cdn.com/v4/letter/c/e68b1a/32.png) [@clearbluelou](https://discuss.elastic.co/u/clearbluelou)\
**Post date:** [February 1, 2022, 5:57pm UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968/1 "2022-02-01T17:57:10Z")

</div>

I'm new to Elasticsearch and Kibana. I haven't really gotten to a point of understanding of the JSON-like syntax. I've just been using the filters and some Lucene queries. Please be gentle. 😊 This is hard to explain.

I'm dealing with voice call records that are indexed by a call identifier. The fields I'm interested in are named 'messageKey' and 'message'. I need to find all call IDs with (messageKey : ReportKey) AND (message : [9837 TO 9839]) and then find the record with (message : waitDurationInQueueUntilAccepted) for each of those call IDs.

I read about nested and foreach queries but I'm out of my depth. I know this is probably not enough information to answer my question. I'm not sure how best to ask. I hope someone will be patient enough to help me talk through it. I'm open to consider that I'm asking the wrong question entirely.

---

<div class="post-metadata">

**Author:** ![majagrubic](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/majagrubic/32/74459_2.png) [@majagrubic](https://discuss.elastic.co/u/majagrubic)\
**Post date:** [February 2, 2022, 11:40am UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968/2 "2022-02-02T11:40:14Z")

</div>

You definitely don't need a new index. In Kibana Discover, you can type a query with what you have just described:  
` messageKey : ReportKey AND message >= 9837 AND message <= 9839`

and then add a filter for the additional message parameter.

Here's an example of how it might look like for sample data:

 ![Screenshot 2022-02-02 at 12.39.22](https://us1.discourse-cdn.com/elastic/original/3X/a/f/af830168efa51fd5acbea7ccd63c881c9bbdff44.png)

---

<div class="post-metadata">

**Author:** ![clearbluelou](https://avatars.discourse-cdn.com/v4/letter/c/e68b1a/32.png) [@clearbluelou](https://discuss.elastic.co/u/clearbluelou)\
**Post date:** [February 2, 2022, 4:59pm UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968/3 "2022-02-02T16:59:38Z")

</div>

Maja,

Thank you very much for you kind reply. Unfortunately, doing as you suggested causes no results to be found. My conclusion is that since the query causes the results to only include records in which message is between 9837 and 9839, filtering those results for records in which message = waitDurationInQueueUntilAccepted is meaningless. The problem, as I see it, is that both the 9837-9839 and the waitDurationInQueueUntilAccepted records are in the same 'message' field.

---

<div class="post-metadata">

**Author:** ![Tomo\_M](https://avatars.discourse-cdn.com/v4/letter/t/848f3c/32.png) [@Tomo\_M](https://discuss.elastic.co/u/Tomo_M)\
**Post date:** [February 3, 2022, 3:59am UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968/4 "2022-02-03T03:59:07Z")

</div>

So you have data structure something like "entity attribute value" table of SQL?

```auto
{"callID":"001", "messageKey": "ReportKey", "message":9838}
{"callID":"001", "messageKey": "ReportEvent", "message":waitDurationInQueueUntilAccepted}
{"callID":"002", "messageKey": "ReportKey", "message":9901}
{"callID":"002", "messageKey": "ReportEvent", "message":waitDurationInQueueUntilAccepted}

```

To query what you need, you need JOIN function, though Elasticsearch doesn't support it. It is because of performance issue to implement JOIN in highly distributed system.

I truly recommend to have flattened data structure as one document per one callID, such that:

```auto
{"callID":"001", "ReportKey":9838, "ReportEvent": "waitDurationInQueueUntilAccepted"}
{"callID":"002", "ReportKey":9901, "ReportEvent": "waitDurationInQueueUntilAccepted"}

```

---

<div class="post-metadata">

**Author:** ![clearbluelou](https://avatars.discourse-cdn.com/v4/letter/c/e68b1a/32.png) [@clearbluelou](https://discuss.elastic.co/u/clearbluelou)\
**Post date:** [February 3, 2022, 5:19pm UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968/5 "2022-02-03T17:19:10Z")

</div>

Tomo,

Thank you for your reply. Yes, you have identified the basic structure of our data. However, we also have thousands, if not tens of thousands, of other data in the "message" field. As such, it is not possible to flatten it. We have an extremely complex environment.

---

<div class="post-metadata">

**Author:** ![Tomo\_M](https://avatars.discourse-cdn.com/v4/letter/t/848f3c/32.png) [@Tomo\_M](https://discuss.elastic.co/u/Tomo_M)\
**Post date:** [February 3, 2022, 8:52pm UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968/6 "2022-02-03T20:52:06Z")

</div>

I see. Then you may use terms aggregation on call ID and bucket selector aggregation to select call IIDs meeting the condition what you want.

If there are performance issue or exeeding max bucket limitation, using transform function could a solution.

---

<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:** [March 4, 2022, 4:45pm UTC](https://discuss.elastic.co/t/do-i-need-a-nested-query-or-foreach-or-a-create-a-new-index/295968/8 "2022-03-04T16:45:03Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
