Hi David:
We built bobo-browse specifically for these types of usecases:
http://code.google.com/p/bobo-browse
Let me know if you need any help getting it going.
-John
On Mon, Apr 20, 2009 at 12:59 PM, Karsten F.
<karsten-luc...@fiz-technik.de>wrote:
>
> Hi David,
>
> correct: you should avoid reading the content of a document inside a
> hitcollector.
> Normaly that means to cache all you need in main memory. Very simple and
> fast is a facet with only 255 possible values and exactly one value per
> document. In this case you need only an byte[IndexReader.maxDoc()] array in
> cache and an int[256] array for collecting the results
> (we have 5 GByte to run lucene with a couple of facets).
>
> About "facet". For me a facet corresponds to a field in lucene. So 300
> facets are quite a lot.
> Or did you mean two facets with 150 values each?
>
> To find a good solution for your 100M Document, I have three questions:
> - How many hits per search?
> - More then one value of the facet per document/how many in average?
>
> INDEXORDER means document number.
> MultiSearcher works also fine:
> If you have one index for each year and for each of this indices the
> indexorder in order of date, also the MultiSearcher will have correct
> INDEXORDER:
> Take a look to the variable "int[] starts" in MultiSearcher.
>
>
> David Seltzer wrote:
> >
> >
> > Is INDEXORDER based on the DocumentID within each individual index? If so
> > then the results could be interleaved. Anyone know how this behaves?
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Faceting%2C-Sort-and-DocIDSet-tp23099854p23143797.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>
