# Elasticsearch 6.0 \_id and size\_in\_bytes
**URL:** https://discuss.elastic.co/t/elasticsearch-6-0-id-and-size-in-bytes/110072
**Category:** Elasticsearch
**Created:** [December 3, 2017, 7:48pm UTC](https://discuss.elastic.co/t/elasticsearch-6-0-id-and-size-in-bytes/110072 "2017-12-03T19:48:25Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@bCast](https://discuss.elastic.co/u/bCast)
#### Post date: [December 3, 2017, 7:48pm UTC](https://discuss.elastic.co/t/elasticsearch-6-0-id-and-size-in-bytes/110072/1 "2017-12-03T19:48:26Z")
I upgraded to 6.0 because of sequental ids. I expected that after switching to sequental \_id it will saves memory.
In my case I have per day index with lots of events with small amount of fields (like ip\_src, ip\_dst, port\_dst). I noticed that \_id cosumes lots of memory. Is it possible to optimese \_id field or somehow disable it ? If id is sequental I expect that it some sort of memoty offset could be calculated per search request and it is not requred to store it in memory
This is part of statistics:
{
"description" : "field '\_id' [BlockTreeTerms(seg=\_32b terms=531218720,postings=531218720,positions=-1,docs=531218720)]",
"size\_in\_bytes" : 78714997,
"children" : [
{
"description" : "term index [FST(input=BYTE1,output=ByteSequenceOutputs]",
"size\_in\_bytes" : 78714837
}
]
},
{
"description" : "field 'ip\_dst' [BlockTreeTerms(seg=\_32b terms=255005,postings=519813549,positions=-1,docs=519813549)]",
"size\_in\_bytes" : 68845,
"children" : [
{
"description" : "term index [FST(input=BYTE1,output=ByteSequenceOutputs]",
"size\_in\_bytes" : 68685
}
]
},
---
### Author:  [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [December 4, 2017, 9:13am UTC](https://discuss.elastic.co/t/elasticsearch-6-0-id-and-size-in-bytes/110072/2 "2017-12-04T09:13:01Z")
In Elasticsearch 6.0 [all operations get a sequence id](https://www.elastic.co/blog/elasticsearch-sequence-ids-6-0), which can help speed up recovery. The logic for generating document ids is not affected by this (they are not sequential).
---
### Author:  [@bCast](https://discuss.elastic.co/u/bCast)
#### Post date: [December 4, 2017, 4:15pm UTC](https://discuss.elastic.co/t/elasticsearch-6-0-id-and-size-in-bytes/110072/3 "2017-12-04T16:15:32Z")
How do you think if \_id were sequental were memory consumption lower? What is a reason why \_id are not numeric?
---
### Author:  [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [December 4, 2017, 4:19pm UTC](https://discuss.elastic.co/t/elasticsearch-6-0-id-and-size-in-bytes/110072/4 "2017-12-04T16:19:07Z")
Trying to assign sequential numeric ids automatically, does generally not scale or perform in a distributed, highly concurrent system. If you want to, you can however assign your own id at the application layer.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [January 1, 2018, 4:19pm UTC](https://discuss.elastic.co/t/elasticsearch-6-0-id-and-size-in-bytes/110072/5 "2018-01-01T16:19:17Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.