# Performance impact of using a string of length 100 characters as \_Id column in Elastic Search **URL:** \ **Category:** Elasticsearch\ **Created:** [January 3, 2016, 3:01pm UTC](https://discuss.elastic.co/t/performance-impact-of-using-a-string-of-length-100-characters-as--id-column-in-elastic-search/38275 "2016-01-03T15:01:50Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Harish\_Kommaraju](https://avatars.discourse-cdn.com/v4/letter/h/b487fb/32.png) [@Harish\_Kommaraju](https://discuss.elastic.co/u/Harish_Kommaraju)\ **Post date:** [January 3, 2016, 3:01pm UTC](https://discuss.elastic.co/t/performance-impact-of-using-a-string-of-length-100-characters-as--id-column-in-elastic-search/38275/1 "2016-01-03T15:01:50Z")
Hi, I am planning to store events in elastic search. It can have around 100 million events at any point time. To de-dupe events, I am planning to create \_id column of length 100 chars by concatenating below fields entity\_id - UUID (37 chars) + event\_creation\_time (30 chars) + event\_type (30 chars) This store will be having normal reads & writes along with aggregate queries (no updates / deletes) Can you please let me know if there would be any performance impact or any other side-effects of using such lengthy string \_id columns instead of default Ids. Thanks, Harish ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [January 3, 2016, 10:37pm UTC](https://discuss.elastic.co/t/performance-impact-of-using-a-string-of-length-100-characters-as--id-column-in-elastic-search/38275/2 "2016-01-03T22:37:13Z")
This will help [http://blog.mikemccandless.com/2014/05/choosing-fast-unique-identifier-uuid.html](http://blog.mikemccandless.com/2014/05/choosing-fast-unique-identifier-uuid.html) ---
**Author:** ![mikemccand](https://avatars.discourse-cdn.com/v4/letter/m/f04885/32.png) [@mikemccand](https://discuss.elastic.co/u/mikemccand)\ **Post date:** [January 4, 2016, 11:36am UTC](https://discuss.elastic.co/t/performance-impact-of-using-a-string-of-length-100-characters-as--id-column-in-elastic-search/38275/3 "2016-01-04T11:36:53Z")
A very long uid field is not great, especially if the uids can share a large common prefix: it will slow down the uid lookup that ES must do for every document you index or delete. ---
**Author:** ![Harish\_Kommaraju](https://avatars.discourse-cdn.com/v4/letter/h/b487fb/32.png) [@Harish\_Kommaraju](https://discuss.elastic.co/u/Harish_Kommaraju)\ **Post date:** [January 5, 2016, 3:10pm UTC](https://discuss.elastic.co/t/performance-impact-of-using-a-string-of-length-100-characters-as--id-column-in-elastic-search/38275/4 "2016-01-05T15:10:14Z")
Thanks for your replies. Then is there any way of handling de-dupes on multiple columns during inserts? ---
**Author:** ![loren](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/loren/32/44942_2.png) [@loren](https://discuss.elastic.co/u/loren)\ **Post date:** [January 5, 2016, 5:48pm UTC](https://discuss.elastic.co/t/performance-impact-of-using-a-string-of-length-100-characters-as--id-column-in-elastic-search/38275/5 "2016-01-05T17:48:36Z")
One alternative that might be worth exploring/benchmarking is to use a hash of `entity_id+event_creation_time+event_type`. Or, if keeping them sequential is helpful, you could do `event_creation_time+hash(entity_id+event_type)`. Also, I'd imagine those 30 chars for the timestamp could be expressed more compactly. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 11:26pm UTC](https://discuss.elastic.co/t/performance-impact-of-using-a-string-of-length-100-characters-as--id-column-in-elastic-search/38275/6 "2017-07-05T23:26:57Z")