Comment gérer les index lucene dans l'application cloud azure

Question

Je viens de commencer à jouer avec la bibliothèque Azure pour Lucene.NET (http://code.msdn.microsoft.com/AzureDirectory). Jusqu'à présent, j'utilisais mon propre code personnalisé pour écrire des index lucene sur le blob azur. Donc, je copiais le blob sur localstorage du rôle web azur/worker et lisais/écrivais des docs dans l'index. J'utilisais mon mécanisme de verrouillage personnalisé pour m'assurer que nous n'avions pas de conflits entre les lectures et les écritures sur le blob. J'espère que la bibliothèque Azure s'occupera de ces problèmes pour moi.

Cependant, lors de l'essai de l'application de test, j'ai modifié le code pour utiliser l'option compound-file, et cela créait un nouveau fichier chaque fois que j'écrivais dans l'index. Maintenant, ma question est, si je dois maintenir l'index - c'est-à-dire garder un instantané du fichier d'index et l'utiliser si l'index principal est corrompu, alors comment je vais faire ceci. Devrais-je garder une sauvegarde de tous les fichiers .cfs qui sont créés ou manipuler seulement le dernier est bien. Y at-il des appels api pour nettoyer le blob pour conserver le dernier fichier après chaque écriture dans l'index?

Merci Kapil

Answer 1

Après avoir répondu à cette question, nous avons fini par changer notre infrastructure de recherche et utilisé Windows Azure Drive. Nous avions un rôle de travailleur, qui monterait un disque dur virtuel en utilisant le stockage de bloc, et hébergerait l'index Lucene.NET dessus. Le code vérifié pour s'assurer que le VHD a été monté en premier et que le répertoire d'index existait. Si le rôle de l'ouvrier est tombé, le VHD démonterait automatiquement après 60 secondes, et un deuxième rôle de travail pourrait le ramasser.

Nous avons de nouveau modifié notre infrastructure et nous sommes passés à Amazon avec une instance Solr pour la recherche, mais l'option VHD a bien fonctionné pendant le développement. cela aurait pu bien fonctionner en test et en production, mais les exigences signifiaient que nous devions passer à EC2.

Answer 2

J'utilise AzureDirectory pour l'indexation de texte intégral sur Azure, et je reçois des résultats bizarres aussi ... mais nous espérons que cette réponse sera d'une certaine utilité pour vous ...

premièrement, l'option compound-file: d'après ce que je lis et découvre, le fichier composé est un seul gros fichier contenant toutes les données d'index. l'allitératif de ceci est d'avoir beaucoup de petits fichiers (configurés en utilisant la fonction SetMaxMergeDocs (int) d'IndexWriter) écrits dans le stockage. le problème avec ceci est une fois que vous arrivez à beaucoup de fichiers (j'ai bêtement réglé cela à environ 5000) il faut un certain temps pour télécharger les index (sur le serveur Azure ça prend environ une minute, fonctionnait depuis 20 minutes maintenant et toujours pas fini ...). Pour ce qui est de la sauvegarde des index, je ne me suis pas encore attaqué à cela, mais étant donné que nous avons environ 5 millions d'enregistrements actuellement, et que cela va augmenter, je m'interroge également à ce sujet. Si vous utilisez un seul fichier composé, peut-être télécharger les fichiers à un rôle de travailleur, les compresser et les télécharger avec la date d'aujourd'hui fonctionnerait ... si vous avez un plus petit ensemble de documents, vous risquez de réindexer les données si quelque chose ne va pas ... mais encore une fois, dépend du nombre ....