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

David Smiley commented on LUCENE-6863:
--------------------------------------

bq. For instance, if you look at the cc2 field, about 320k documents have a 
value for this field and yet it only takes 1680 bytes of memory for the entire 
index, so about 0.005 byte per document. With a hastable, you would either put 
data into memory and you could hardly avoid using one or more bytes per 
documents, or on disk but then the random-access pattern could be a problem if 
not everything fits into your filesystem cache.

If it's sparse (thus small) and the user has chosen to use docValues because 
it's going to be sorted/faceted/etc (thus it's likely 'hot'  i.e. used) then I 
think it's reasonable to expect it'll be in the filesystem cache?  

Nonetheless what you've done here is good.  I think that an in-memory hash 
would be a nice _alternative_ for those that elect for the trade-off.  On a 
semi-related note, I wonder how well a 4-byte int FST -> long would perform.

bq. Here are the times it take to run these queries on trunk (in milliseconds).

Ah; looks like a fair trade-off to me.  Thanks for these details.

> Store sparse doc values more efficiently
> ----------------------------------------
>
>                 Key: LUCENE-6863
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6863
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>         Attachments: LUCENE-6863.patch, LUCENE-6863.patch
>
>
> For both NUMERIC fields and ordinals of SORTED fields, we store data in a 
> dense way. As a consequence, if you have only 1000 documents out of 1B that 
> have a value, and 8 bits are required to store those 1000 numbers, we will 
> not require 1KB of storage, but 1GB.
> I suspect this mostly happens in abuse cases, but still it's a pity that we 
> explode storage requirements. We could try to detect sparsity and compress 
> accordingly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to