本文详细分析了在处理大量数据时，DocValues加载过程中遇到的性能瓶颈，特别是与Stringdocvalues相关的问题。通过将Stringdocvalues替换为BytesRef，显著减少了加载时间。此外，文章还探讨了使用Intern和BytesRef进行字符串优化的可能性，以及直接使用UTF16保存数据的考虑因素。
目前商户索引DocValues非常大,warmup时花费70-80秒(在beta环境),有62秒在加载DocValues,发现其中有54秒时间在加载string docvalues,string docvalues涉及的总数达到138M,平均一个字符串13字节,但如果只是读,只要花费大约2秒时间(之前已经通过cat加入page cache),为什么花这么多时间?大部分时间花在String(bytearray,off,len,charset)上（如果只是一个StringBuilder生成的字符串最多也只需要10秒,因此就是这个原因)，排除了byte array拷贝的问题(我消除为一次io,没有发现性能提升),我原来以为是jdk那个bug导致的，可是经测试并非如此，刚好在网上看到Thrift中也提到String Constructor编解码慢的bugzilla,其中交的Utf8Helper说是参考lucene UnicodeUtil写的，于是果断换成BytesRef.utf8ToString,速度果然快了一些，String docvalues现在加载大约需要37秒 ， 虽然不算大幅，但也不错哈哈。
目前看到大部分时间是花在byte array转string,就是decode慢，如果docvalues只使用byteref就可以减少到大约两秒, 但bytesref虽有compare接口，却没有indexOf等常用字符串接口，而且返回的需要交给业务层，恐怕短时间内并不好换，但如果可以换，绝对飙了!
另外结合intern是个不错的思路,如果重复的字符串较多,可以以bytesref做哈希进行查找，这样对于重复的字符串就可以不用做转码操作，非常好的思路!
另外一种简单做法是直接用utf16保存，但是编码是否紧凑，是否占用很多硬盘也需要考虑。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
