# Types and Indices. One to one?

**URL:** <https://discuss.elastic.co/t/types-and-indices-one-to-one/1190>\
**Category:** Elasticsearch\
**Created:** [May 22, 2015, 7:06pm UTC](https://discuss.elastic.co/t/types-and-indices-one-to-one/1190 "2015-05-22T19:06:43Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![totallymike](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/totallymike/32/44815_2.png) [@totallymike](https://discuss.elastic.co/u/totallymike)\
**Post date:** [May 22, 2015, 7:06pm UTC](https://discuss.elastic.co/t/types-and-indices-one-to-one/1190/1 "2015-05-22T19:06:43Z")

</div>

Hi there. I've been digging deeper into Elasticsearch lately, and I'm wondering about the ramifications of multiple types in a single index.

For some background, I got into Elasticsearch because a number of Ruby on Rails projects I've worked on use it. It seems to be idiomatic for the various Ruby gems to split up each document type into its own index.

However, that limits the ability to do parent-child queries and so on.

What's the story behind indices and types? Should they stay split up unless one needs to reason about the relationships between documents? Should they all go in a single index just for fun? Does it matter tremendously one way or another?

My instinct tells me to keep them separated. I would suspect (without any data to back it up) that ES has an easier time of just about everything (searching, indexing, storage, partitioning) when document types are broken out into different indices.

---

<div class="post-metadata">

**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:** [May 23, 2015, 6:47pm UTC](https://discuss.elastic.co/t/types-and-indices-one-to-one/1190/2 "2015-05-23T18:47:07Z")

</div>

I think your instincts are correct. As someone who has blown up a production site because I did not split two types into two indexes, my default thinking is 1:1 unless there is some good reason to do otherwise. This is especially true if it makes sense for fields to have the same name across types.

Calculations like IDF apply to a field across the entire index, regardless of type or other filtered fields that you may be using to logically partition your data.

Example: I had a reasonable sized (~1M) index with one type `type1` with a field called `my_text`. Queries, aggregations, and so on were super fast and lots of end users hit pages that relied on these queries.

Then I added about a billion documents of type `type2`, also containing a field called `my_text` with the same mapping. I thought that was clever because I could then do some reasoning about `my_text` across the types.

What happened instead was that my original queries involving `my_text` on `type1` got slow enough to back up the application server layer. Then I ran out of heap.

From a relevancy point of view, you can inadvertently change `my_text` search results on `type1` by adding documents of `type2`, as the IDF across the index for that field changes. Ditto for suggestions.

Finally, for time-based indexes like you'd get with Logstash, it's easier to maintain different storage/replica/retention policies when you have the types split into separate physical indexes.

---

<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:** [May 24, 2015, 2:04am UTC](https://discuss.elastic.co/t/types-and-indices-one-to-one/1190/3 "2015-05-24T02:04:00Z")

</div>

If an index is analogous to a DB, then a type is analogous to a table. Keeping things separate is good data hygiene.  
However if you have lots of different types it may make sense to normalise them and group similar things.

---

<div class="post-metadata">

**Author:** ![totallymike](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/totallymike/32/44815_2.png) [@totallymike](https://discuss.elastic.co/u/totallymike)\
**Post date:** [May 24, 2015, 7:43pm UTC](https://discuss.elastic.co/t/types-and-indices-one-to-one/1190/4 "2015-05-24T19:43:54Z")

</div>

Thank you both. That's more or less how I felt. I appreciate having a little more weight behind those instincts.

---

<div class="post-metadata">

**Author:** ![roytmana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/roytmana/32/44855_2.png) [@roytmana](https://discuss.elastic.co/u/roytmana)\
**Post date:** [May 29, 2015, 7:54pm UTC](https://discuss.elastic.co/t/types-and-indices-one-to-one/1190/5 "2015-05-29T19:54:50Z")

</div>

i thought that at some point (when naming of fields was refactored for multifield and other scenarios) lucene field names was made to include type name so no collisions would occur across types. I guess I was wrong. Could anyone comment on it?

---

<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 6, 2017, 12:10am UTC](https://discuss.elastic.co/t/types-and-indices-one-to-one/1190/6 "2017-07-06T00:10:43Z")

</div>


