Deep Paging auf Facette Ergebnisse

Question

Nach https://cwiki.apache.org/confluence/display/solr/Faceting kann ich facet.offset und facet.limit zu paginieren.

Ich denke, diese sind analog zu start und rows für normale Abfrageergebnisse.

Aber wäre das nicht sehr langsam, wenn ich zu viele Facettenergebnisse habe? Nach https://cwiki.apache.org/confluence/display/solr/Pagination+of+Results:

Wenn Sie wünschen eine sehr große Anzahl von sortierten Ergebnisse von Solr zu holen in einem externen System zu füttern, kann sehr ineffizient mit sehr großen Werten für die Start- oder Zeilen Parameter sein. Die Paginierung mit Start und Zeilen erfordert nicht nur Solr zu berechnen (und sortieren) im Speicher alle die übereinstimmenden Dokumente, die für die aktuelle Seite, abgerufen werden sollen, sondern auch alle Dokumente, die auf vorherigen Seiten erschienen wären.

Also für tiefe Paging bei normalen Abfragen, würde ich stattdessen eine cursorMark verwenden.

So

1) Bin ich richtig, dass tief Paging auf Ergebnisse Facette mit facet.offset hat die gleiche Leistung conerns wie das Zitat oben?

2) Gibt es etwas wie cursorMark oder andere effizientere tiefe Paging für Facettenergebnisse statt ?

@Override 
    public boolean collect(BytesRef term, int count) { 
    if (count > min) { 
     // NOTE: we use c>min rather than c>=min as an optimization because we are going in 
     // index order, so we already know that the keys are ordered. This can be very 
     // important if a lot of the counts are repeated (like zero counts would be). 
     spare.copyUTF8Bytes(term); 
     queue.add(new SimpleFacets.CountPair<>(spare.toString(), count)); 
     if (queue.size()>=maxsize) min=queue.last().val; 
    } 
    return false; 
    } 

und ein wenig über:

maxsize = limit>0 ? offset+limit : Integer.MAX_VALUE-1; 

die im Grunde zu führt

Answer 1

Ja, wenn Sie einen Blick in eine der FacetCollector Umsetzung stattfinden wird, werden Sie etwas sehen das gleiche Problem wie beim tiefen Paging. Der Code wird eine riesige BoundedTreeSet (Ursache maxsize wird durch die Summe aus Offset und Limit bestimmt), und die Komplexität wird etwa so wie im tiefen Paging-Szenario sein.

Die meiste Zeit erwarte ich jedoch nicht, dass irgendjemand eine Array mit Facettenwerten größer als 10_000 hat (von oben, wahrscheinlich sogar weniger), was keine Probleme verursachen sollte (bis Sie Millionen Facettenwerte erhalten).

Normalerweise kommen Facetten aus Feldern mit begrenzter Semantik (Marke, Farbe, Bundesland, Abteilung usw.) und normalerweise sind diese Werte begrenzt.

Zusammenfassend: Der Algorithmus ist der gleiche wie beim Sammeln übereinstimmender Dokumente, aber die Art der Facettenwerte sollte uns vor dem Problem bewahren.