Solr 如何在Lucene 7+；中通过文档ID获取DocValue；？

我正在使用向文档添加DocValue

doc.add(new BinaryDocValuesField("foo",new BytesRef("bar")));

要为ID为

docId

的特定文档检索该值，我调用

DocValues.getBinary(reader,"foo").get(docId).utf8ToString();

BinaryDocValues中的

get

函数支持到，但对于和更高版本，它似乎不再可用

那么，如何在Lucene 7+中通过文档ID获取DocValue（无需迭代

二进制DocValues

/

DocIdSetIterator

，也无需每次重新获取

二进制DocValues

并使用

advanceExact

）

理论 文档值是Lucene的列字段值存储。文档值旨在在查询时非常快速地进行随机访问，以便进行面处理和排序。 下面的问题将访问模式从随机访问切换到迭代器。由于迭代器API的访问模式比任意随机访问API的限制性大得多，因此此更改为Lucene提供了更大的自由度和能力来使用积极的压缩和其他优化：

• 在数据稀疏的情况下减少磁盘空间的使用
• 更好的压缩比和doc值解码速度，即使在非稀疏情况下
• 删除缺失值的特殊列（getDocsWithField）和线程本地编解码器读取器

您可以在以下博客中阅读有关此更改的信息：

实践 在实践中，这种变化在某些情况下会导致性能下降，例如。在大多数情况下（刻面和排序），迭代API可以正常使用，甚至可以执行一些优化。 事实上，在很多情况下，这个API并不是一个好的解决方案。所有这些情况都被视为不正确的用法而丢弃（与我们在java word中使用sun.misc.Unsafe时遇到的问题相同）

---

事实上，

org.apache.lucene.index.DocValuesIterator#advanceExact

速度非常快，在某些实现中具有类似的性能和复杂性。

另一个很好的答案-非常感谢您的澄清。我们遇到了上述性能下降（随着段大小的增加，性能会越来越差），这提示-它不会更改API，因此仍然需要请求迭代器，但速度不会因较大的段而降低。