Requête ou concept Lucene/MySQL mixte

Question

Notre projet nécessite des recherches en temps quasi réel et une mise à jour constante. Les données sont actuellement stockées dans une base de données MySQL et l'index Lucene est mis à jour lorsque la base de données est modifiée.

Nous avons la capacité de recherche actuellement où nous le voulons. Cependant, nous essayons d'ajouter la possibilité de "marquer" les documents dans l'index/base de données. Comme les pots de données peuvent contenir des millions d'enregistrements, nous ne souhaitons pas mettre à jour l'index Lucene pour le marquage (ou s'il existe un moyen de mettre à jour en masse Lucene qui pourrait fonctionner aussi). Nous avons plutôt une table d'identifiants de documents dans MySQL que nous aimerions utiliser pour déterminer les ensembles de tags. La meilleure option que j'ai trouvée jusqu'ici est de récupérer la liste des ID sous la forme d'un tableau d'entiers, de les trier (donc je n'ai besoin que de faire une boucle), de faire une boucle et de rechercher des correspondances entre les deux. ce n'est pas idéal car on risque de perdre le tri).

La tentative d'utilisation de la liste des ID Lucene dans la requête "IN" dans MySQL échoue car le nombre de documents peut être dans les millions et les chokes MySQL sur celui-ci.

Un aperçu de la façon dont nous pourrions optimiser cela ou le faire? Une autre suggestion était un 2ème index et l'utilisation d'un MutliSearcher, mais je ne suis pas entièrement sûr de savoir comment procéder en raison de la nécessité de mettre à jour l'index avec un million de lignes possible lors de la mise à jour ou de la suppression d'un ensemble de tags.

Answer 1

Pour vos "mises à jour de masse", ne pouvez-vous pas effectuer une mise à jour delta de l'index Lucene en fonction d'un horodatage ou similaire dans votre table MySql? Je l'ai fait dans solr, plutôt que directement dans Lucene, mais comme Solr est un wrapper autour de la fonctionnalité Lucene, c'est essentiellement la même chose (ou du moins je suppose ...).

.

Relevant question, (perhaps).

Answer 2

Pour tout ce qui suit, l'hypothèse est que vous n'avez pas assez de RAM pour contenir complètement toute une collection.

La technologie d'indexation est conçue en particulier pour une situation où vous avez beaucoup plus de lectures que d'écritures. Il serait bon d'analyser d'abord les fréquences correspondantes et de quantifier ainsi la "mise à jour constante".

Si la fréquence des mises à jour est trop élevée, vous pouvez essayer de gérer cette partie de la recherche directement avec votre système de base de données (si MySQL ne fait pas le travail, il y a aussi PostgreSQL dépend des mécanismes d'indexation dans la base de données et de la mémoire disponible pour les mettre en mémoire cache).

Sinon, vous pouvez vouloir regarder dans Solr (qui est un peu plus qu'un simple wrapper autour de Lucene, car il fournit des fonctionnalités supplémentaires qui peuvent être basées, mais n'est pas disponible par lui-même en utilisant Lucene).

En particulier:

• Solr performance factors
• Multi Core approach (c.-à-swapping de base)
• StreamingUpdateSolrServer

Peut-être que vous pouvez utiliser différentes stratégies en fonction de la taille du lot de la mise à jour et la performance off-trade pour les commits/optimisation.Pour les énormes mises à jour par lots, il peut être plus facile de copier un noyau de secours, de mettre à jour par lots, de valider/optimiser et d'échanger le cœur. Cependant, il ne s'agira plus de "temps quasi-réel" (NRT); l'idée de NRT in Lucene est locale et dépend directement de la RAM disponible et des tailles de collection.