Mise en cache Solr avec EHCache/BigMemory

Question

Nous implémentons une grande configuration Lucene/Solr avec des documents de plus de 150 millions. Nous aurons également une quantité modérée de mises à jour de documents chaque jour.

Ma question est vraiment en deux parties l'une:

Quelles sont les conséquences de l'utilisation de la mise en cache une autre mise en œuvre au sein Solr, à savoir EHCache au lieu du natif Solr LRUCache/FastLRUCache? Terracotta a annoncé BigMemory destiné à être utilisé conjointement avec EHCache en tant que mémoire cache en mémoire cache. Selon TC, cela vous permet de stocker de grandes quantités de données sans le surcoût GC de la JVM. Est-ce une bonne idée à utiliser avec Solr? Cela va-t-il réellement aider?

Je voudrais esp. Vous aimeriez entendre des personnes ayant une réelle expérience de production avec EHCache/BigMemory et/ou Solr Cache Tuning.

Answer 1

Je ne suis pas sûr que quelqu'un l'ait déjà essayé. Nous aimerions certainement nous associer aux gars de Solr pour savoir à quel point cela serait utile. Nous pourrions même être en mesure de l'optimiser pour le cas d'utilisation.

Answer 2

Beaucoup de réflexions sur ce sujet. Bien que ma réponse n'utilise pas EhCache de quelque façon que ce soit. Tout d'abord, je ne crois pas que les documents devraient être stockés dans votre index de recherche. Le contenu de la recherche devrait y être stocké, pas le document entier. Ce que je veux dire par là, ce qui est retourné de votre requête de recherche devrait être des ID de document. Pas le contenu des documents eux-mêmes. Les documents eux-mêmes doivent être stockés et récupérés à partir d'un second système, probablement le magasin de fichiers original à partir duquel ils sont indexés. Cela réduira la taille de l'index, diminuera la taille du cache de documents, diminuera le temps de réplication de l'esclave maître (cela peut devenir un goulot d'étranglement si vous effectuez souvent des mises à jour) et diminuera le temps de réponse.

Ensuite, pensez à mettre un proxy HTTP inversé devant Solr. Bien que les caches de requête permettent à Solr de répondre rapidement, un cache comme Varnish assis devant Solr est encore plus rapide. Cela décharge Solr, lui permettant de passer du temps à répondre à des requêtes qu'il n'avait pas vues auparavant. Le deuxième effet est que vous pouvez maintenant jeter la plus grande partie de votre mémoire sur des caches de documents au lieu de caches de requêtes. Si vous avez suivi ma première suggestion, vos documents seront incroyablement petits, ce qui vous permettra de garder la plupart, sinon la totalité, en mémoire.

Retour rapide du calcul de l'enveloppe pour les tailles de document. Je peux facilement fournir un int de 32 bits comme ID pour 150 millions de documents. J'ai toujours une marge de 10x pour la croissance du document. 150 millions d'identifiants prennent 600MB. Ajouter un facteur de fudge pour les documents d'emballage Solr, et vous pouvez probablement avoir tous vos documents Solr en mémoire cache 1-2 Go. Considérer obtenir 12 Go-24 Go ou RAM est facile de nos jours, et je dirais que vous pourriez faire tout cela sur une boîte et obtenir des performances incroyables. Pas besoin de quoi que ce soit d'étranger comme EhCache. Assurez-vous d'utiliser votre index de recherche le plus efficacement possible.

En ce qui concerne GC: Je n'ai pas vu beaucoup de temps de GC passé sur mes serveurs Solr. La plupart de ce qui devait être collecté était les objets de très courte durée impliqués dans le cycle de requête et de réponse HTTP, qui ne sort jamais de l'espace d'Eden. Les caches n'ont pas un chiffre d'affaires élevé lorsqu'ils sont réglés correctement. Les seuls grands changements étaient quand un nouvel index a été chargé et les caches ont été vidés, mais cela ne se produisait pas constamment.

EDIT: Pour l'arrière-plan, j'ai passé beaucoup de temps à régler la mise en cache Solr pour une grande entreprise qui vend des consoles et qui sert des millions de recherches par jour à partir de ses serveurs Solr.