lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (LUCENE-1997) Explore performance of multi-PQ vs single-PQ sorting API
Date Tue, 03 Nov 2009 01:08:59 GMT

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

Mark Miller edited comment on LUCENE-1997 at 11/3/09 1:07 AM:
--------------------------------------------------------------

Actually - while I cannot share any current info I have, I'll share an example from my last
job. I worked on a system that librarians used to maintain a newspaper archive. The feed for
the paper would come in daily and the librarians would "enhance" the data - adding keywords,
breaking up stories, etc. Then reporters or end users could search this data. Librarians,
who I learned are odd in there requirements by nature, insisted on bringing in thousands of
results that they could scroll through at a time. This was demanded at paper after paper.
So we regularly fed back up to 5000 thousand results at a time with our software (though they'd
have preferred no limit - "what are you talking about ! I want them all!" - we made them click
more buttons for that :) ). Thats just one small example, but I know for a fact there are
many, many more.

*edit* 

We also actually ran into many situations were there were lots of segments in this scenario
as well - before I knew better, I'd regularly build the indexes with a high merge factor for
speed - and then be stuck, unable to optimize because it killed performance and newspapers
need to be up pretty much 24/7 - without bringing there server to a crawl - so I would be
unable to optimize (this was before you could optimize down to n segments and work slowly
over time). Not the greatest example, but a situation I found myself in.

      was (Author: markrmiller@gmail.com):
    Actually - while I cannot share any current info I have, I'll share an example from my
last job. I worked on a system that librarians used to maintain a newspaper archive. The feed
for the paper would come in daily and the librarians would "enhance" the data - adding keywords,
breaking up stories, etc. Then reporters or end users could search this data. Librarians,
who I learned are odd in there requirements by nature, insisted on bringing in thousands of
results that they could scroll through at a time. This was demanded at paper after paper.
So we regularly fed back up to 5000 thousand results at a time with our software (though they'd
have preferred no limit - "what are you talking about ! I want them all!" - we made them click
more buttons for that :) ). Thats just one small example, but I know for a fact there are
many, many more.
  
> Explore performance of multi-PQ vs single-PQ sorting API
> --------------------------------------------------------
>
>                 Key: LUCENE-1997
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1997
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.9
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>         Attachments: LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch,
LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch
>
>
> Spinoff from recent "lucene 2.9 sorting algorithm" thread on java-dev,
> where a simpler (non-segment-based) comparator API is proposed that
> gathers results into multiple PQs (one per segment) and then merges
> them in the end.
> I started from John's multi-PQ code and worked it into
> contrib/benchmark so that we could run perf tests.  Then I generified
> the Python script I use for running search benchmarks (in
> contrib/benchmark/sortBench.py).
> The script first creates indexes with 1M docs (based on
> SortableSingleDocSource, and based on wikipedia, if available).  Then
> it runs various combinations:
>   * Index with 20 balanced segments vs index with the "normal" log
>     segment size
>   * Queries with different numbers of hits (only for wikipedia index)
>   * Different top N
>   * Different sorts (by title, for wikipedia, and by random string,
>     random int, and country for the random index)
> For each test, 7 search rounds are run and the best QPS is kept.  The
> script runs singlePQ then multiPQ, and records the resulting best QPS
> for each and produces table (in Jira format) as output.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message