Solr performances de pagination

Question

J'ai lu (http://old.nabble.com/using-q%3D--,-adding-fq%3D-to26753938.html#a26805204):

FWIW: limiter le nombre de lignes par demande à 50, mais pas limiter le début ne fait pas beaucoup de sens - le même montant de travail est nécessaire pour poignée début = 0 & lignes = 5050 et début = 5000 & lignes = 50.

qu'il complète:

Il y a très peu de cas d'utilisation pour permettre aux gens de itérer toutes les lignes qui nécessitent également le tri.

Est-ce exact? Est-ce vrai pour les résultats triés?

Combien de pages de 10 lignes chacune recommandez-vous à l'utilisateur de parcourir?

Est-ce que Solr 1.4 souffre de la même limitation?

Answer 1

Oui c'est vrai, même pour Solr 1.4. Cela ne pas signifie que start=0&rows=5050 a les mêmes performances que start=5000&rows=50, puisque le premier doit retourner 5050 documents tandis que le dernier seulement 50. Moins de données à transférer -> plus rapide.

Solr n'a aucun moyen d'obtenir TOUS les résultats dans une seule page, car cela n'a pas beaucoup de sens. À titre de comparaison, vous ne pouvez pas extraire l'intégralité de l'index Google dans une seule requête. Personne n'a vraiment besoin de faire ça.

Le format de page de votre application doit pouvoir être défini par l'utilisateur (c'est-à-dire que l'utilisateur peut choisir de voir 10, 25, 50 ou 100 résultats à la fois).

Le format de page par défaut dépend du type de données que vous recherchez et de la pertinence des résultats. Par exemple, lorsque vous effectuez une recherche sur Google, vous ne regardez généralement pas au-delà des premiers résultats, donc 10 éléments suffisent. eBay, d'autre part, est plus sur en parcourant les résultats, de sorte qu'il montre 50 résultats par page par défaut, et il n'offre même pas 10 résultats par page.

Vous devez également prendre en compte le défilement. Les utilisateurs seraient probablement perdus en essayant de naviguer à travers un 200-result page, sans compter que cela prend beaucoup plus de temps à charger.

Answer 2

start = 0 & rangs = 5050 et start = 5000 & rows = 50

dépend du point de sauter pour commencer = 5000. Si vous faites défiler tous les résultats de 0 à 4999 en les ignorant tous et en continuant à défiler de 5000 à 5050 alors oui, la même quantité de travail est faite ici. La meilleure chose à faire est de limiter les lignes récupérées à partir de la base de données en utilisant quelque chose comme ROWNUM dans Oracle.

.

itérer à travers toutes les lignes qui nécessitent également le tri

Peu mais oui il y a des cas d'utilisation qui ont cette exigence. Des exemples seraient des exportations CSV/Excel/PDF.