You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Julie Tibshirani (Jira)" <ji...@apache.org> on 2020/09/15 21:39:00 UTC

[jira] [Commented] (LUCENE-9378) Configurable compression for BinaryDocValues

    [ https://issues.apache.org/jira/browse/LUCENE-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196567#comment-17196567 ] 

Julie Tibshirani commented on LUCENE-9378:
------------------------------------------

Adding another datapoint in case it’s helpful: Elasticsearch uses binary doc values to store high-dimensional float vectors (the `dense_vector` type). The vectors are typically used to score documents. This is a very similar use case to the one [~alexklibisz] describes.

In a best case scenario where we index random 100-dimensional float vectors (so they don’t compress well), and scan over all documents (so we don’t decompress data that’s not needed), we see a QPS drop of ~10%:

{{Algorithm       QPS}}
{{Old version      66.989}}
{{New version      60.906}}

I would guess [~nicot]'s example also falls under the general category of "storing/ loading numeric feature vectors"? For this type of data, it’s common to take a specialized approach instead of applying a general compression algorithm (like using a sparse vector representation, using fewer bytes for each vector element, etc.)

> Configurable compression for BinaryDocValues
> --------------------------------------------
>
>                 Key: LUCENE-9378
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9378
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Viral Gandhi
>            Priority: Minor
>         Attachments: hotspots-v76x.png, hotspots-v76x.png, hotspots-v76x.png, hotspots-v76x.png, hotspots-v76x.png, hotspots-v77x.png, hotspots-v77x.png, hotspots-v77x.png, hotspots-v77x.png, image-2020-06-12-22-17-30-339.png, image-2020-06-12-22-17-53-961.png, image-2020-06-12-22-18-24-527.png, image-2020-06-12-22-18-48-919.png, snapshot-v77x.nps, snapshot-v77x.nps, snapshot-v77x.nps, snapshots-v76x.nps, snapshots-v76x.nps, snapshots-v76x.nps
>
>          Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> Lucene 8.5.1 includes a change to always [compress BinaryDocValues|https://issues.apache.org/jira/browse/LUCENE-9211]. This caused (~30%) reduction in our red-line QPS (throughput). 
> We think users should be given some way to opt-in for this compression feature instead of always being enabled which can have a substantial query time cost as we saw during our upgrade. [~mikemccand] suggested one possible approach by introducing a *mode* in Lucene80DocValuesFormat (COMPRESSED and UNCOMPRESSED) and allowing users to create a custom Codec subclassing the default Codec and pick the format they want.
> Idea is similar to Lucene50StoredFieldsFormat which has two modes, Mode.BEST_SPEED and Mode.BEST_COMPRESSION.
> Here's related issues for adding benchmark covering BINARY doc values query-time performance - [https://github.com/mikemccand/luceneutil/issues/61]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org