# ES as a long-term storage system inside analytics architecture?

**URL:** https://discuss.elastic.co/t/es-as-a-long-term-storage-system-inside-analytics-architecture/84697
**Category:** Elasticsearch
**Created:** [May 5, 2017, 10:42am UTC](https://discuss.elastic.co/t/es-as-a-long-term-storage-system-inside-analytics-architecture/84697 "2017-05-05T10:42:51Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![rusty](https://avatars.discourse-cdn.com/v4/letter/r/f17d59/32.png) [@rusty](https://discuss.elastic.co/u/rusty)
#### Post date: [May 10, 2017, 8:37am UTC](https://discuss.elastic.co/t/es-as-a-long-term-storage-system-inside-analytics-architecture/84697/3 "2017-05-10T08:37:36Z")

</div>

> [@How can we store large scale data with 32GB RAM / 30TB disk on machine](https://discuss.elastic.co/t/how-can-we-store-large-scale-data-with-32gb-ram-30tb-disk-on-machine/84501/3):
>
> Yeah, I had try some cases to solve my problem, include set each shards to the tens of GB in size. I found that: in my case, one shard with 70GB in size, the shard may cost about 470 MB term\_memory. So if I used all of 32GB RAM, means that I can store about 32GB/470MB=68 shards. 68 shards can only store 70GB\*68=4.7TB cry

Hello, it's really depends. You should make similar estimation to understand is it fits for your purposes (do you need to index data, do you need doc\_values, do you need replication, is best\_compression codec suitable and so on). IMHO for now ES is too memory hungry for petabyte-scale solutions.

---

_[View the full topic](https://discuss.elastic.co/t/es-as-a-long-term-storage-system-inside-analytics-architecture/84697)._