2017-10-06 4 views
0

J'ai une table MySQL dans laquelle tous les utilisateurs peuvent INSERT. L'un des champs de la table est le nombre total de documents solr que la ligne correspond, appelez-le total results.Consistance MySQL et Solr, sur insertion à

Dans le code API REST, lors de l'insertion, j'utilise un client solr pour trouver le nombre total de documents correspondant à la nouvelle ligne. Je mets à jour le champ, puis je renvoie la ressource complétée. Assez simple, bien que je préférerais déclencher cette mise à jour automatiquement via MySQL. Le plus gros problème est, lors de l'insertion de nouveaux documents ou de la suppression de vieux documents de solr, je n'ai pas de meilleur plan que d'exécuter un script shell qui a la même logique que le code API REST, et exécutez la mise à jour total results sur chaque rangée.

Mes options, comme je le vois, sont les suivants:

1.) mettre à jour toutes les lignes après un data_import à Solr, un par un. Cette table a environ 1.5M lignes, donc cela prend du temps. 2.) Renoncer complètement au champ dans la base de données, et obtenir chaque somme total results de solr chaque fois que les ressources sont récupérées. (C'est une très mauvaise idée dans mon cas car un utilisateur récupère 20k lignes de cette table lors de la connexion avec GET/API/ressource comme une liste)

3.) Trouver un moyen de déterminer quelles tables MySQL spécifiques un nouveau Le document solr affecte et limite la mise à jour de ces lignes. Cela impliquerait essentiellement d'inverser le processus de recherche.

Les solutions 1 et 3 nécessitent essentiellement que j'écrive un script qui gère le solr data_import et la mise à jour du champ total results des lignes MySQL en un seul processus. Je peux le faire, mais je suis au point où je pourrais avoir un aperçu de la meilleure façon de gérer ces problèmes.

Alors, comment maintenez-vous la cohérence?

+0

Regardez comment Alfresco gère le problème, la cohérence "éventuelle" et "transactionnelle", peut-être que cela vous aidera. – Lista

Répondre

0

Luwak a été conçu pour résoudre ce problème (c'est-à-dire avoir stocké des requêtes et les déclencher lorsque les documents indexés correspondent). Vous devez mettre à jour le nombre de résultats lorsqu'un document correspond à une requête stockée. Lorsque vous supprimez un document, faites de même, mais décrémentez le nombre réel à la place.

Il s'agit toutefois d'une solution spécifique basée sur Lucene. Elle ne connecte donc pas directement à votre infrastructure existante.

Une autre option consiste à faire la même chose manuellement; Pour chaque recherche stockée - si la recherche est un simple booléen correspondent à ces termes-type de recherche, décomposer la recherche en jetons via la fonction d'analyse de Solr pour le type de champ, puis faire de même avec le document lors de l'indexation. Recherchez chaque requête qui correspond à l'un des jetons générés par Solr (dans un magasin différent, dans Solr ou dans une table SQL distincte), puis mettez à jour les comptages. Selon la taille de vos documents, cela peut être difficile, mais pas impossible, à mettre en œuvre.

Elasticsearch a ceci comme une caractéristique sous percolation, mais cela pourrait aussi être en cause lorsque vous parlez de requêtes stockées de 1,5M. Pour Solr vous indexez le document dans un index de mémoire uniquement, puis exécutez toutes les requêtes par rapport à cela pour trouver les requêtes qui correspondent.