# Question about the sparseness **URL:** \ **Category:** Elasticsearch\ **Created:** [May 24, 2017, 8:24pm UTC](https://discuss.elastic.co/t/question-about-the-sparseness/87039 "2017-05-24T20:24:03Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![YuWatanabe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yuwatanabe/32/13259_2.png) [@YuWatanabe](https://discuss.elastic.co/u/YuWatanabe)\ **Post date:** [May 24, 2017, 8:24pm UTC](https://discuss.elastic.co/t/question-about-the-sparseness/87039/1 "2017-05-24T20:24:03Z")
Hello. My environment is _elasticsearch 5.4.0_ . I have done some studying about types by reading below two articles. > **[Type Takeaways - Types and Mappings | Elasticsearch: The Definitive Guide \[2.x\]...](https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html#_type_takeaways)** > [@Guidance on Using Multiple Indexes vs One Index for Time Series Data from Multiple Sources](https://discuss.elastic.co/t/guidance-on-using-multiple-indexes-vs-one-index-for-time-series-data-from-multiple-sources/32729/4): > > Like @otisg says, types might be the right thing here. Its what they are for. Each has a fixed cost in heap and cluster state maintenance time for types can help here. The drawbacks come around scoring (IDF information is shared), aggregations (types can hide sparseness and make the doc values less efficient), and types (if two devices send data with the same name but a different type then you'll have a bad time). If you can live with these things then I think you should look at types. Sparsen… and thought using _1 type / index_ rather than _n types / index_ has more benefits in terms of less downside. So in my environment I am thinking of creating index with flat mapping definition and consolidate the fields for various log types. Splitting every type of logs into multiple index costs too many shards per node for me. But I came up with a question will the search and aggregation performance same in below cases? Flattening the mapping breaks the context of a log but I would like to get advice if setting field value explicitly saves sparseness. For example, ## Case1 ( having type 1 and type 2 in a index) Index : A Logs include below fields log A F1 : a F2 : b log B F1 : a F3 : c Index A will be docA (type1) F1 : a F2 : b F3 : nil docB (type2) F1 : a F2 : nil F3 : c ## Case2 (type1 only) Index : A Logs include below fields logA F1 : a F2 : b logB F1 : a F3 : c Index A will be docA (type1) F1 : a F2 : b F3 : "Not Defined" **\<-Explicitly set a string** docB(type1) F1 : a F2 : "Not Defined" **\<-Explicitly set a string** F3 : c Thank you for reading. ---
**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 25, 2017, 9:12am UTC](https://discuss.elastic.co/t/question-about-the-sparseness/87039/2 "2017-05-25T09:12:32Z")
> [@YuWatanabe](#): > > But I came up with a question will the search and aggregation performance same in below cases? It's the same as 1 index with 50 shards versus 50 indices with 1 shard each. ES does the same amount of work. > [@YuWatanabe](#): > > Flattening the mapping breaks the context of a log but I would like to get advice if setting field value explicitly saves sparseness. Why does it break the context? Ultimately sparseness doesn't apply to field mappings, it applies to the values in those fields. Splitting things out into their own index may or may not increase sparseness, it's hard to say. However we have done a lot of work in lucene and ES to improve handling of sparse values so I am not sure if this type change is really going to cause a negative impact. ---
**Author:** ![YuWatanabe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yuwatanabe/32/13259_2.png) [@YuWatanabe](https://discuss.elastic.co/u/YuWatanabe)\ **Post date:** [May 26, 2017, 8:04am UTC](https://discuss.elastic.co/t/question-about-the-sparseness/87039/3 "2017-05-26T08:04:41Z")
@warkolm Thank you for the reply. You are right it does not break the context. However, I also found the github thread that type will be deprecated in the future release. > I guess this will be another reason I should use 1 type per index. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 23, 2017, 8:04am UTC](https://discuss.elastic.co/t/question-about-the-sparseness/87039/4 "2017-06-23T08:04:52Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.