# Issue storing binary fields in 6.2.2 **URL:** https://discuss.elastic.co/t/issue-storing-binary-fields-in-6-2-2/128290 **Category:** Elasticsearch **Created:** [April 17, 2018, 6:08am UTC](https://discuss.elastic.co/t/issue-storing-binary-fields-in-6-2-2/128290 "2018-04-17T06:08:39Z") **Posts on this page:** 1 **Showing post:** 7
### Author: ![Vinayak\_Sapre](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vinayak_sapre/32/45939_2.png) [@Vinayak\_Sapre](https://discuss.elastic.co/u/Vinayak_Sapre) #### Post date: [April 17, 2018, 4:00pm UTC](https://discuss.elastic.co/t/issue-storing-binary-fields-in-6-2-2/128290/7 "2018-04-17T16:00:40Z")
Thanks David. > > TBH I'm not sure it's a very good thing to store binaries in elasticsearch. It's not binary like a jpg. Raw value is actually string longer than 32K. We perform text analysis on this value. Since it's longer than 32K and I need to retrive complete string back, I wasn't able to store it as keyword. I use two fields one of type text (used for searching) and one binary (for retrieving). Coming back to your solution, store:true worked with a small test. I also tried storing text string larger than 32K. It worked too. I feel store:true is better option compared to enabling \_source. I will try with the real data. I understand stored fields are slower to retrieve than docvalue fields ([What's the difference between "store" and "doc\_values" in field properties?](https://discuss.elastic.co/t/whats-the-difference-between-store-and-doc-values-in-field-properties/70045)). That should be okay. But does it have any implications on heap utilization compared to doc\_values? I don't search, sort, aggregate on binary field. Thanks Vinayak --- _[View the full topic](https://discuss.elastic.co/t/issue-storing-binary-fields-in-6-2-2/128290)._