RoaringDocIdSet类似于谈谈BitSet的缺点提到的SparseFixedBitSet是一个用于优化整形序列的存储手段,并按照65536个元素进行分段存储即每段中存储的序列最多是65536个,每个分段中的数值都是对65536取模后进行存储的。
每个数据段都有各自的存储格式:
1、当每段中的序列个数小于等于4096个时采用short数组进行存储;
2、当每段中的序列个数等于65536或者大于65536-4096=61440时保存的是序列的差集,序列的差集正好用short数组进行保存;
3、当每段中的序列个数小于等于61440大于4096时采用FixedBitSet进行保存;
问题1:选用65536为分段中元素的最大个数是因为short的最大值为65535;
问题2:为什么当每段中的序列个数小于等于4096个时采用short数组进行存储?
假如该段只有1个数值65535,采用short存储只需2个字节,而采用FixedBitSet就一定是8192个字节,当元素个数大于4096时采用short数值存储占用空间大于8192个字节,然而FixedBitSet最多才占用8192个字节,所以当每段中的序列个数小于等于4096个时采用short数组进行存储。
问题3:在lucene中指出RoaringDocIdSet必须按照顺序对docID进行添加,为什么?
个人认为是为了节省运行时空间与代码复杂度,假设不按照顺序添加,那么在最后一个元素添加完之前就不能像源码中那样一段一段的处理序列了,必须按照123条件那样检查序列。