# Question on using my own value as \_id

**URL:** https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470
**Category:** Elasticsearch
**Created:** [June 20, 2021, 11:59pm UTC](https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470 "2021-06-20T23:59:51Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![pk.241011](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pk.241011/32/86285_2.png) [@pk.241011](https://discuss.elastic.co/u/pk.241011)
#### Post date: [June 20, 2021, 11:59pm UTC](https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470/1 "2021-06-20T23:59:51Z")

</div>

Hi As per this [post](https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-indexing-speed.html#_use_auto_generated_ids) it is not advisable to bring your own \_id to elasticsearch.

I have inherited a shared windows (horror of all the horrors) drive as a source of log file and already see re-ingestion happening occasionally when using filebeats. However I have GUID as one of the fields.

I was thinking of using it as \_id so that the event gets overwritten on an accidental re-ingest (Rather than ending up as a duplicate event).

The key thing is that I am not going to do a lookup. It will be a blind overwriting. At least from my point of view. Is there anyway I can instruct Elasticsearch not to try to look up for that document behind the scene and just fire a write command?

---

<div class="post-metadata">

### Author: ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [June 21, 2021, 2:06am UTC](https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470/2 "2021-06-21T02:06:59Z")

</div>

No that is not possible. If you provide your own id Elasticsearch will need to check if it is an update. This is what prevents duplicates, which is the behaviour you are looking for.

---

<div class="post-metadata">

### Author: ![pk.241011](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pk.241011/32/86285_2.png) [@pk.241011](https://discuss.elastic.co/u/pk.241011)
#### Post date: [June 21, 2021, 4:24am UTC](https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470/3 "2021-06-21T04:24:11Z")

</div>

Ok got it. Will have to live with that then.  
Is it a worthy feature to be considered?

---

<div class="post-metadata">

### Author: ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [June 21, 2021, 5:04am UTC](https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470/4 "2021-06-21T05:04:05Z")

</div>

Consider what a feature? The current behaviour is required when using you use your own IDs. Each shard in Elasticsearch is a Lucene intance and Lucene uses immutable segments to store data. These have to be searched when you supply your own ID as you otherwise could get duplicate documents with the same ID. What you are suggesting is therefore impossible.

---

<div class="post-metadata">

### Author: ![pk.241011](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pk.241011/32/86285_2.png) [@pk.241011](https://discuss.elastic.co/u/pk.241011)
#### Post date: [June 21, 2021, 6:15am UTC](https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470/5 "2021-06-21T06:15:18Z")

</div>

Got it. Thanks.

---

<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: [July 19, 2021, 6:15am UTC](https://discuss.elastic.co/t/question-on-using-my-own-value-as-id/276470/6 "2021-07-19T06:15:47Z")

</div>

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