SOLR autoCommit vs autoSoftCommit
je suis très confus à propos de et . Voici ce que je comprends!--2-->
autoSoftCommit - après un autoSoftCommit, si le serveur SOLR tombe en panne, les documents autoSoftCommit seront perdus.
validation - s'engage sur le disque dur et s'assure que tous les commits d'autoSoftCommit sont écrits sur le disque et propagent tout autre document.
Ma configuration suivante semble être seulement avec avec autoSoftCommit. autoCommit seul ne semble pas faire de commits. Est-il quelque chose que je suis absent ?
<updateHandler class="solr.DirectUpdateHandler2">
<updateLog>
<str name="dir">${solr.ulog.dir:}</str>
</updateLog>
<autoSoftCommit>
<maxDocs>1000</maxDocs>
<maxTime>1200000</maxTime>
</autoSoftCommit>
<autoCommit>
<maxDocs>10000</maxDocs>
<maxTime>120000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
</updateHandler>
pourquoi autoCommit fonctionne-t-il tout seul ?
3 réponses
Vous avez openSearcher=false pour dur s'engage. Ce qui signifie que même si la propagation a eu lieu, le chercheur n'a pas été relancé et ne peut pas voir les changements. Essayez de changer ce paramètre et vous n'aurez pas besoin de commit doux.
SoftCommit réouvre le chercheur. Donc, si vous avez les deux sections, soft commit affiche les nouvelles modifications (même si elles ne sont pas hard-committed) et - tel que configuré - hard commit les sauve sur le disque, mais ne change pas la visibilité.
Cela permet pour mettre soft commit à 1 seconde et faire apparaître les documents rapidement et avoir hard commit se produire moins fréquemment.
je pense que c' article sera utile pour vous. Il explique en détail comment dur commit et soft commit fonctionnent, et les compromis qui doivent être pris en compte lors de l'ajustement de votre système.
je frémis toujours à ce sujet, parce que toute recommandation sera erronée dans certains cas. Ma première recommandation serait de ne pas trop réfléchir au problème. Certaines personnes très intelligentes ont essayé de rendre l'ensemble du processus robuste. Essayez les choses simples d'abord et seulement modifier les choses en tant que de besoin. En particulier, examinez la taille de vos journaux de transactions et ajustez vos intervalles de commit afin de conserver ces "dimensions raisonnables". Rappelez-vous que la pénalité est surtout le temps de replay impliqué si vous redémarrez après un crash JVM. 15 secondes, c'est supportable? Pourquoi être plus petit alors?
nous avons vu des situations dans lesquelles l'intervalle de propagation dur est beaucoup plus court que l'intervalle de propagation mou, voir le bit d'indexation en vrac ci-dessous.
ce sont des lieux de départ.
INDEXATION LOURDE (EN VRAC)
L'hypothèse ici est que vous êtes intéressés à obtenir beaucoup de données à l'indice le plus rapidement possible pour la recherche dans l'avenir. Je pense à des charges originales d'une source de données, etc.
Réglez votre intervalle de propagation assez long. Comme dans 10 minutes. Soft commit est une question de visibilité, et mon hypothèse ici est que l'indexation en masse n'est pas une question de recherche en temps quasi réel donc ne faites pas le travail supplémentaire d'ouvrir toute sorte de chercheur. Réglez vos intervalles de commit dur à 15 secondes, openSearcher=false. Encore une fois, l'hypothèse est que vous allez juste faire sauter des données au Solr. Le pire, c'est que vous redémarrez votre système et que vous devez rejouer une quinzaine de secondes de données de votre tlog. Si votre système rebondit de haut en bas plus souvent que cela, fixer la raison pour cela d'abord. Seulement après que vous avez essayé les choses simples si vous envisagez des raffinements, ils sont généralement nécessaires que dans des circonstances inhabituelles. Mais ils comprennent: Désactiver complètement le tlog pour l'opération de chargement en vrac Indexation hors ligne avec une sorte de map-processus de réduction Il suffit d'avoir un chef par fragment, pas de répliques pour la charge, puis d'allumer les répliques plus tard et de les laisser faire une réplication à l'ancienne pour rattraper leur retard. Notez que c'est automatique, si le noeud découvre qu'il est "trop éloigné" de la synchronisation avec le leader, il initie une réplication à l'ancienne. Après qu'il a rattrapé, il obtiendra des documents car ils sont indexés au chef et garder son propre tlog. etc.
INDEX-HEAVY, QUERY-LIGHT
par ceci je veux dire, disons, rechercher des fichiers journaux. C'est le cas où vous avez beaucoup de données provenant du système à peu près tout le temps. Mais la charge de requête est assez légère, souvent pour dépanner ou analyser l'utilisation.
Réglez votre intervalle de propagation assez long, jusqu'à la latence maximale que vous pouvez supporter pour que les documents soient visibles. Cela pourrait prendre quelques minutes ou beaucoup plus. Peut-être même heures avec la capacité d'émettre un commit dur (openSearcher=true) ou un commit doux sur demande. Réglez votre engagement dur à 15 secondes, openSearcher=false INDEX-LIGHT, QUERY-LIGHT OR HEAVY
il s'agit d'un indice relativement statique qui obtient parfois une petite rafale d'indexation. Dire que toutes les 5-10 minutes (ou plus) vous faites une mise à jour
à moins que la fonctionnalité NRT ne soit requise, j'omettrais les commits doux dans cette situation et je ferais des commits durs toutes les 5-10 minutes avec openSearcher=true. Il s'agit d'une situation dans laquelle, si vous indexez avec un seul processus d'indexation externe, il pourrait être logique que le client émette le "hard commit".
INDEX-HEAVY, QUERY-HEAVY
il s'agit de L'affaire en temps quasi réel (TRN), et c'est vraiment la plus délicate du lot. Celui-ci va nécessiter une expérimentation, mais voici où je commencerais
Réglez votre intervalle de propagation aussi longtemps que vous le pouvez. N'écoutez pas votre produit gestionnaire qui dit "nous n'avons pas besoin de plus d'une seconde de latence". Vraiment. Poussez fort en arrière et voyez si l'utilisateur est mieux servi ou même remarquera. Les mèches molles et les TRN sont assez incroyables, mais elles ne sont pas gratuites. Réglez votre intervalle de propagation dur à 15 secondes.
dans mon cas (index lourd, requête lourde), la réplication maître-esclave prenait trop de temps, ralentissant don les requêtes vers l'esclave. En augmentant le softCommit à 15min et en augmentant le hardCommit à 1min, la performance l'amélioration a été grande. Maintenant, la réplication fonctionne sans problème, et les serveurs peuvent gérer beaucoup plus de requêtes par seconde.
C'est mon cas d'utilisation cependant, je me suis rendu compte que j'ai vraiment besoin que les éléments soient disponibles sur le master en temps réel, puisque le master n'est utilisé que pour indexer les éléments, et que de nouveaux éléments sont disponibles dans les esclaves à chaque cycle de réplication (5min), ce qui est totalement correct pour mon cas. vous devriez ajuster ces paramètres pour votre cas.
les commits Soft concernent la visibilité. dur commits sont sur la durabilité. optimiser est une question de performance.
commits Soft sont très rapides, il y a des changements visibles mais ces changements ne sont pas persistants (ils ne sont que dans la mémoire) .Donc, pendant le crash, ces changements pourraient être les derniers.
Dur valide les modifications sont persistants sur le disque.
Optimiser, c'est comme s'engager dur, mais c'est aussi fusionner des segments d'indice solr en un seul segment pour améliorer les performances .Mais il est très coûteux.
une opération de commit (hard commit) rend les changements d'index visibles pour les nouvelles requêtes de recherche. Un dur commettre utilise la transaction journal pour obtenir l'id de la dernière modification du document, et également les appels fsync sur les fichiers d'index pour s'assurer qu'ils ont une panne de courant ne provoquera aucune perte de données.
un commit soft est beaucoup plus rapide car il rend seulement les changements d'index visibles et n'écrit pas les fichiers d'index de fsync un nouveau descripteur d'index. Si la JVM se bloque ou il y a une perte de puissance, les changements qui ont eu lieu après le dernier dur commit sera perdu. Rechercher des collections qui ont des besoins NRT (qui veulent des changements d'index pour être rapidement visible pour les recherches) vont vouloir des commit soft souvent mais des commit hard moins fréquemment. Une commissioncomplète peut être "moins cher" en termes de temps, mais pas gratuite, car il peut ralentir le débit.
une optimisation est comme un hard commit sauf qu'elle force tous les segments d'index à être fusionnés dans un seul segment de la première. Selon l'utilisation, cette opération devrait être effectuée peu souvent (par exemple, la nuit), si tant est qu'elle le soit, car il s'agit de lire et de réécrire l'ensemble de l'index. Les Segments sont normalement fusionnés au fil du temps de toute façon (comme déterminé par la Politique de fusion), et d'optimiser juste forces ces fusions à se produire immédiatement.
auto commit properties we can manage from sorlconfig.xml files.
<autoCommit>
<maxTime>1000</maxTime>
</autoCommit>
<!-- SoftAutoCommit
Perform a 'soft' commit automatically under certain conditions.
This commit avoids ensuring that data is synched to disk.
maxDocs - Maximum number of documents to add since the last
soft commit before automaticly triggering a new soft commit.
maxTime - Maximum amount of time in ms that is allowed to pass
since a document was added before automaticly
triggering a new soft commit.
-->
<autoSoftCommit>
<maxTime>1000</maxTime>
</autoSoftCommit>
Références: