# 70MB csv file becomes 32GB index

**URL:** <https://discuss.elastic.co/t/70mb-csv-file-becomes-32gb-index/99859>\
**Category:** Elasticsearch\
**Created:** [September 8, 2017, 2:01pm UTC](https://discuss.elastic.co/t/70mb-csv-file-becomes-32gb-index/99859 "2017-09-08T14:01:22Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [September 8, 2017, 4:55pm UTC](https://discuss.elastic.co/t/70mb-csv-file-becomes-32gb-index/99859/2 "2017-09-08T16:55:42Z")

</div>

My guess is the indexing of the geo field is costing you the disk space here.

See [Huge difference in index size when bulk indexing geoshapes across ES versions](https://discuss.elastic.co/t/huge-difference-in-index-size-when-bulk-indexing-geoshapes-across-es-versions/97137/4?u=mark_harwood) for some detail on indexing options and their costs.

Putting spatial indexing settings aside - if you have very many weather records for the same place it may not be terribly efficient for each of them to describe the exact coordinates of that area with each observation of a day's rainfall. Denormalization may be costing you dearly here.  
It may prove better to make your application first geo-query a `places` index with the shape information indexed in order to then retrieve a list of names/ids that you can then use to query the `weather` index where place names not coordinates are indexed.

---

_[View the full topic](https://discuss.elastic.co/t/70mb-csv-file-becomes-32gb-index/99859)._