# Mapping with a large number of fields **URL:** \ **Category:** Elasticsearch\ **Created:** [January 27, 2016, 2:34pm UTC](https://discuss.elastic.co/t/mapping-with-a-large-number-of-fields/40245 "2016-01-27T14:34:36Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![bsarkar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bsarkar/32/42967_2.png) [@bsarkar](https://discuss.elastic.co/u/bsarkar)\ **Post date:** [January 27, 2016, 2:34pm UTC](https://discuss.elastic.co/t/mapping-with-a-large-number-of-fields/40245/1 "2016-01-27T14:34:36Z")
I have a use case where the mapping may have around 5-10 thousand fields or even more! I've read about the [mapping explosion problem](https://www.elastic.co/blog/found-crash-elasticsearch#mapping-explosion). I tried to get around this problem by using nested documents for a set of fields that can be dynamically created by the client and a flat list of fields for others. This has resulted in queries becoming very complex as I need to handle both kind of fields (flat + nested) and hence I'm re-thinking my decision to go ahead with nested fields. Rate of addition of new fields to the mapping is very low; not more than once or twice per day. Currently they're indexed as nested fields. I understand the problem of cluster state management but I guess Elasticsearch 2.0 has solved it to a great extent by publishing cluster state diffs instead of the entire cluster state whenever possible. What I want to understand is what impact does a mapping of this size has on indexing and search performance. ---
**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:21pm UTC](https://discuss.elastic.co/t/mapping-with-a-large-number-of-fields/40245/2 "2017-07-05T23:21:03Z")