# Single or multiple types

**URL:** <https://discuss.elastic.co/t/single-or-multiple-types/41447>\
**Category:** Elasticsearch\
**Created:** [February 11, 2016, 2:31am UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447 "2016-02-11T02:31:05Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![jasmine](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@jasmine](https://discuss.elastic.co/u/jasmine)\
**Post date:** [February 11, 2016, 2:31am UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447/1 "2016-02-11T02:31:05Z")

</div>

Hi There,

We are looking into solutions of storing and searching time-series of data and Elasticsearch comes up as one of the candidates. After reading and thinking of our domain, I have a question regarding to the mapping and type managements.

In short is it better to have multiple types with single data point for each search or single type with all the data points?

an example is,  
1\>  
HostCPU {  
name: string; //hostName  
value: float; //cpu usage  
timestamp: date; //collection time  
}

HostMemory{  
name: string; //hostName  
value: float; //memory usage  
timestamp: date; //collection time  
}

.....  
other types of interests  
........

or  
2\>  
Host{  
name: string; //hostName  
cpuUsage: float;  
memoryUsage: float;  
...otherDataOfInterest..  
timestamp: data  
}

With option 1\> we would just retrieve CPU or memory data as needed; with option 2\> you would always get all data even if user is only interested in one of the data points.

With option 2\> the number of documents would be much less and the duplication of data is less, hence less footprints as well but more I/O when not all data is needed. also when multiple data points are needed, one search vs. multiple searches.

There are thousands of hosts to collect and search data for. For each host we have 20 or so datapoints of interets.

I'd appreciate any feedback and any pointers to some design principles to keep in mind in regards to number of indices, number of types, number of documents and any hard limits on those.

Thanks  
Jasmine

---

<div class="post-metadata">

**Author:** ![jasontedor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jasontedor/32/66992_2.png) [@jasontedor](https://discuss.elastic.co/u/jasontedor)\
**Post date:** [February 11, 2016, 2:42am UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447/2 "2016-02-11T02:42:30Z")

</div>

Not directly an answer to your question, but the definitive writing on types is [Index vs. Type](https://www.elastic.co/blog/index-vs-type). I hope that it helps you understand how to think about these sorts of issues.

---

<div class="post-metadata">

**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:** [February 11, 2016, 2:44am UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447/3 "2016-02-11T02:44:17Z")

</div>

> [@jasmine](#):
>
> With option 2\> the number of documents would be much less and the duplication of data is less, hence less footprints as well but more I/O when not all data is needed

Maybe, compression would help with #1

Basically it's going to be a case of try both and see what works 🙂

---

<div class="post-metadata">

**Author:** ![jasmine](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@jasmine](https://discuss.elastic.co/u/jasmine)\
**Post date:** [February 11, 2016, 4:39am UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447/4 "2016-02-11T04:39:27Z")

</div>

Thanks Jason,

We are planning to use one index ( per day) with many types.

We are uncertain with "many" different types, each with fewer data points, so the found documents would only contain the necessary data point; or less types, each with more data points, so the search would return all data and up to the consumer to pick out what data points are needed.

---

<div class="post-metadata">

**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:** [February 11, 2016, 4:53am UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447/5 "2016-02-11T04:53:41Z")

</div>

> [@jasmine](#):
>
> We are planning to use one index ( per day) with many types.

Be careful - [Mapping changes | Elasticsearch Guide [2.2] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/2.2/breaking_20_mapping_changes.html#_conflicting_field_mappings)

---

<div class="post-metadata">

**Author:** ![jasmine](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@jasmine](https://discuss.elastic.co/u/jasmine)\
**Post date:** [February 11, 2016, 5:47am UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447/6 "2016-02-11T05:47:41Z")

</div>

Thanks Mark, it's very useful to be aware of the pitfalls.

My main concern of the multiple types vs. single type catching all is about storage and performance. From what you said previously, both are reasonable approaches pending on usage and can only find out by prototype and benchmarking.. On paper (in theory) it's not black or white with either option 1 or 2 from the expert's point of view.

---

<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 5, 2017, 11:17pm UTC](https://discuss.elastic.co/t/single-or-multiple-types/41447/7 "2017-07-05T23:17:20Z")

</div>