IndexReader/Writers multiples dans un processus (Lucene)

Question

Nous maintenons un index Lucene qui contient des documents d'environ 20 mm. La nature des requêtes de recherche est telle que l'indexation et la segmentation peuvent être facilement réparties entre différents index.

Pour que nous ayons besoin de garder plusieurs (potentiellement des milliers) IndexWriters ou IndexReaders/Searchers en mémoire pour traiter l'indexation et la suppression de chacun de ces indexies (les requêtes ne couvrent pas plusieurs index).

J'ai besoin de connaître la pression mémoire que cela va causer, et les solutions potentielles que n'importe qui peut suggérer.

Answer 1

Vous pouvez jeter un oeil à Solr, qui prend en charge la création et la gestion de plusieurs indices (appelés cœurs) prêts à l'emploi. Il va également gérer tout le travail de distribution sur plusieurs nœuds si cela devient nécessaire. Cela étant dit, le surdébit de mémoire par index est très faible (par conception). Je pense que c'est quelque chose comme un octet par document, puis le nombre de termes uniques divisés par 256.

Answer 2

Je voudrais savoir à quelle fréquence mettez-vous à jour l'index, y a-t-il une exigence en temps réel? Si vous utilisez le projet java lucene alors vous pouvez probablement regarder dans ce projet open source que Linked-In a engendré un peu de travail interne. Dans la mesure où la recherche de la pression de la mémoire dépend du fait que vous triez les résultats par la valeur des champs indexés. Dans ce cas, le cache de champ, qui est une fonctionnalité interne de lucene, génère une pression de mémoire dans certaines situations.

J'espère que cela aide.