lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-5914) More options for stored fields compression
Date Sun, 30 Nov 2014 17:23:12 GMT

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

Robert Muir commented on LUCENE-5914:
-------------------------------------

I will think more on the header check logic. On one hand it would be nice if we could figure
out an idiom for {{CodecUtil.checkFooter(Throwable, Input...)}} that would be safe, but every
option I think of is crazier than the current stuff.

Its also a bit wierd to be slurping in 3 read-once metadata files here. This adds complexity
at read... the current format is simpler here with just a single file. Can we avoid this?

> More options for stored fields compression
> ------------------------------------------
>
>                 Key: LUCENE-5914
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5914
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>             Fix For: 5.0
>
>         Attachments: LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch
>
>
> Since we added codec-level compression in Lucene 4.1 I think I got about the same amount
of users complaining that compression was too aggressive and that compression was too light.
> I think it is due to the fact that we have users that are doing very different things
with Lucene. For example if you have a small index that fits in the filesystem cache (or is
close to), then you might never pay for actual disk seeks and in such a case the fact that
the current stored fields format needs to over-decompress data can sensibly slow search down
on cheap queries.
> On the other hand, it is more and more common to use Lucene for things like log analytics,
and in that case you have huge amounts of data for which you don't care much about stored
fields performance. However it is very frustrating to notice that the data that you store
takes several times less space when you gzip it compared to your index although Lucene claims
to compress stored fields.
> For that reason, I think it would be nice to have some kind of options that would allow
to trade speed for compression in the default codec.



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

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


Mime
View raw message