Allow reading binary doc values as a RandomAccessInput

[iverase]

Following up this suggestion from @jpountz, here I propose to add a new method to the BinaryDocValues API that returns the content of the doc values as a RandomAccessInput. This will allow to have an off-heap version of the binary doc value whenever possible.

The main two changes here are:

1. Lucene90DocValuesProducer allocates the BytesRef for binary doc values lazily.

2. To make transparent when the binary doc value is already on heap, BytesRef implements RandomAccessInput so we can just return the result from binaryValue() in those cases. If that's not ok, we can create a RandomAccessInput wrapper for BytesRef instead.

relates #12459

[jpountz]

Using RandomAccessInput addresses problems with multiple callers wanting to consume the value, that helps.

In my opinion, we should not have both a binaryValue() and a randomAccessValue() getters in the long term. Can we remove the binaryValue() getter on the main branch and make it deprecated when we backport to 10.x?

we can create a RandomAccessInput wrapper for BytesRef instead.

I would like it better this way.

[jpountz]

In my experience, binary doc values are more often used to encode structured data, such as maps that help build scoring signals, geo shapes, etc. than actual binary content, so this change makes sense to me. I'm interested in having more opinions though.

Would be nice to extend AssertingBinaryDocValues to make sure that all reads in the input are within bounds.

[iverase]

I have a second iteration and I have realised that this change can be easily done if we introduce a new abstraction. I have called it RandomAccessInputRef and it is the equivalent to BytesRef but backed by a RandomAccessInput instead of a byte array. I am thinking of it as the off-heap version of BytesRef.

Using this abstraction makes the changes almost mechanical. The big difference between BytesRef and RandomAccessInputRef is that the latter cannot implement efficiently the compare interface so it cannot be use for comparisons and equality. In that case we need to read bytes on-heap.

With this new abstraction, we just need to add three new methods:

• BytesRefBuilder#copyBytes(RandomAccessInputRef in) throws IOException
• BytesRefArray#append(RandomAccessInputRef bytes) throws IOException
• ByteBlockPool#append(final RandomAccessInput bytes, long offset, int length) throws IOException: for supporting the method above)

And two helper classes:

• ByteArrayRandomAccessInput: To represent and byte array as a RandomAccessInput
• RandomAccessInputDataInput: to wrap a RandomAccessInput as a DataInput so we can use DataOutput#copyBytes(DataInput input, long numBytes)

There are few places that still needs to be adapted to take full advantage of the new API but they can be done in a follow up as they require a bit of work :

• MatchingFacetSetsCounts FacetSetDecoder
• BaseShapeDocValuesQuery
• SerializedDVStrategy
• MonitorQuerySerializer f5117e6

And there are two places that we will need to put the data on-heap as they are using equality:

• TermValComparator : Use for sorting, it assumes that binary data can be sorted, e.g they are strings.
• BinaryDocValueSelector - misc module

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution!

[jpountz]

The general direction makes sense to me. Using RandomAccessInput vs. DataInput helps since the former is stateless. I first didn't like that it's a RandomAccessInputRef as opposed to a plain RandomAccessInput but I have come to like it when looking deeper at the PR.

I ran the sorting tasks on wikibigall and saw no regression to HighTermTitleBDVSort (but no speedup either):

                            TaskQPS baseline      StdDevQPS my_modified_version      StdDev                Pct diff p-value
                      TermDTSort      259.60      (5.7%)      258.98      (6.8%)   -0.2% ( -12% -   13%) 0.904
            HighTermTitleBDVSort       14.52      (3.1%)       14.51      (3.0%)   -0.1% (  -5% -    6%) 0.944
           HighTermDayOfYearSort      476.39      (3.4%)      478.38      (5.7%)    0.4% (  -8% -    9%) 0.780
                        PKLookup      233.90      (3.4%)      235.06      (3.3%)    0.5% (  -5% -    7%) 0.636
               HighTermMonthSort     1661.20      (3.6%)     1677.10      (4.4%)    1.0% (  -6% -    9%) 0.449

[jpountz]

Nit: it's a bit sad to load all bytes on top heap, when in many cases we could identify that the value is not competitive after reading a few bytes only?

[iverase]

agree, it will require a bit of rework here but should be doable. Maybe as a follow up?