目前商户索引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保存,但是编码是否紧凑,是否占用很多硬盘也需要考虑。