眼下商户索引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保存，可是编码是否紧凑，是否占用非常多硬盘也须要考虑。