# Index design question

**URL:** <https://discuss.elastic.co/t/index-design-question/12574>\
**Category:** Elasticsearch\
**Created:** [June 28, 2013, 7:20am UTC](https://discuss.elastic.co/t/index-design-question/12574 "2013-06-28T07:20:40Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dennis\_Lee](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@Dennis\_Lee](https://discuss.elastic.co/u/Dennis_Lee)\
**Post date:** [June 28, 2013, 7:20am UTC](https://discuss.elastic.co/t/index-design-question/12574/1 "2013-06-28T07:20:40Z")

</div>

Hi. I'm dennis in korea.

These days. I've been testing elasticsearch with our company's application.  
I felt like it's really enjoying impressive performance, rock-solid stability and easily.

I have a design question what would be the most efficient way to index large sets.

For example.

2012.1 average rows : 6,000,000, sql data size : about 160GB  
2012.2 average rows : 5,000,000, sql data size : about 170GB  
.  
.  
.  
2013.6 ~

Would it be more efficient to store the archived documents into a separate type  
or into a separate index(a day or a month)?

If it store the archived documents into a separate index. then 365 indices. has it too many indices? (for a day : about 5GB)

Our H/W spec : Intel(R) Xeon(R) CPU E7-4850 2.00Ghz 2EA, 64GB, Disk Raid 5.

and our application use only reading and analysis on work.

Thanks so much for your help !!!

---

<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, 2:29am UTC](https://discuss.elastic.co/t/index-design-question/12574/2 "2017-07-06T02:29:06Z")

</div>