Verstehen von Transaktionsprotokollen, Soft Commit und Commit in SolrCloud

Lucidworks hat sich über Solr hinaus entwickelt und bietet die Lucidworks Platform, unsere KI-gestützte Suchlösung für Unternehmen. Entdecken Sie, wie wir Ihnen helfen können, Ihre Such- und Entdeckungserfahrungen zu verbessern.

Hard Commits, Soft Commits und Transaktionsprotokolle

Seit Apache Solr 4.0 verfügt Solr über eine „Soft Commit“-Funktion und einen neuen Parameter für Hard Commits – openSearcher. Gegenwärtig herrscht ziemliche Verwirrung über das Zusammenspiel zwischen Soft- und Hard-Commit-Aktionen und insbesondere darüber, was das alles für das Transaktionsprotokoll bedeutet. Die Datei solrconfig.xml erklärt die Optionen, aber mit der üblichen Dokumentation-im-Beispiel-Beschränkung würde die Beispieldatei, wenn es eine vollständige Erklärung für alles gäbe, etwa 10M groß sein und niemand würde sich das Ganze jemals durchlesen.

Dieser Artikel beschreibt die Folgen von Hard- und Soft-Commits und die neue openSearcher-Option für Hard-Commits. Die Release-Dokumentation finden Sie im Solr-Referenzhandbuch, dieser Beitrag ist ein eher gemächlicher Überblick über dieses Thema. Ich habe ein paar der Committer dazu überredet, mir einige Details zu geben. Ich bin sicher, dass ich die richtigen Informationen erhalten habe, eventuelle Schreibfehler sind meine!

Das Mantra

Sprechen Sie mir nach:„Bei Hard Commits geht es um Haltbarkeit, bei Soft Commits um Sichtbarkeit.“

Hard- und Soft-Commits sind verwandte Konzepte, dienen aber unterschiedlichen Zwecken. Hinter dieser einfachen Aussage verbergen sich viele Details. Wir werden versuchen, einige von ihnen zu beleuchten. Zunächst einige Definitionen:

• Transaktionsprotokoll (tlog): Eine Datei, in die die Rohdokumente für Wiederherstellungszwecke geschrieben werden. In SolrCloud hat jeder Knoten sein eigenes tlog. Bei einer Aktualisierung wird das gesamte Dokument in das tlog geschrieben. Bei Atomic Updates ist es immer noch das gesamte Dokument, einschließlich der Daten, die aus der alten Version des Dokuments gelesen wurden. Mit anderen Worten: Das in das Tlog geschriebene Dokument ist nicht das „Delta“ für atomare Aktualisierungen. Tlogs sind entscheidend für die Konsistenz. Sie werden verwendet, um einen Index auf den neuesten Stand zu bringen, wenn die JVM angehalten wird, bevor Segmente geschlossen werden.
  • HINWEIS: Das Transaktionsprotokoll wird beim Neustart des Servers erneut abgespielt, wenn der Server nicht ordnungsgemäß heruntergefahren wurde! Wenn Ihr Transaktionsprotokoll also riesig ist (und wir haben es im Gigabyte-Bereich gesehen), kann der Neustart Ihres Servers sehr, sehr langsam sein. Und zwar stundenlang.
• Harte Übergabe: Dies wird durch die Option <autoCommit> in solrconfig.xml oder durch explizite Aufrufe von einem Client (SolrJ oder HTTP über den Browser, cURL o.ä.) gesteuert. Hard Commits schneiden das aktuelle Segment ab und öffnen ein neues Segment in Ihrem Index.
• openSearcher: Eine boolesche Untereigenschaft von <autoCommit>, die festlegt, ob die neu gebundenen Daten für nachfolgende Suchen sichtbar gemacht werden. Voreinstellung „true“.
• Soft-Commit: Eine weniger kostspielige Operation als Hard-Commit (openSearcher=true), die auch Dokumente für die Suche sichtbar macht. Bei Soft-Commits wird das Transaktionsprotokoll nicht abgeschnitten.
  • Wichtig: Soft Commits sind „günstiger“, aber immer noch nicht kostenlos. Sie sollten das Intervall für Soft-Commits so lang machen, wie es für eine optimale Leistung sinnvoll ist!
• fsynch: E/A-Fachsprache auf niedriger Ebene. Wenn ein fsynch-Aufruf zurückkehrt, sind die Bits tatsächlich auf der Festplatte gesetzt worden. Der Unterschied zum einfachen Schreiben von Daten durch ein Java-Programm besteht darin, dass die Rückkehr eines Java-Schreibvorgangs nur garantiert, dass die neuen Daten an das Betriebssystem übergeben wurden, das die Bits auf der Festplatte zu gegebener Zeit ändern wird.
• flush: Die Java-Operation, die die Daten an das Op-System übergibt. Bei der Rückkehr sind die Bits auf der Festplatte nicht verändert worden und die Daten gehen verloren, wenn das Op-System zum falschen Zeitpunkt abstürzt.
  • Beachten Sie, dass insbesondere in SolrCloud, wo es mehr als eine Replik pro Shard gibt, der Verlust von Daten voraussetzt, dass beide Knoten gleichzeitig ausfallen, so dass keiner von beiden es schafft, den Schreibvorgang auf die Festplatte abzuschließen, was sehr unwahrscheinlich ist.
  • Das Op-System setzt die Bits nach einem Flush innerhalb weniger Millisekunden (etwa 10-50 ms). Wenn die JVM abstürzt, ändert das Op-System die Bits auf der Festplatte nach einem Flush trotzdem. Wenn das Op-System jedoch abstürzt, nachdem Java die Datei „geschrieben“ hat, aber bevor das E/A-Subsystem die Bits auf der Festplatte tatsächlich ändern kann, können die Daten verloren gehen. Dies ist in der Regel kein Grund zur Sorge, sondern nur dann wichtig, wenn Sie absolut sicher sein müssen, dass keine Daten verloren gehen.

Transaktionsprotokolle

Transaktionsprotokolle sind ein wesentlicher Bestandteil der Datengarantien von Apache Solr, beginnend mit Solr 4.0, und auch ein Ort, an dem Menschen in Schwierigkeiten geraten, also lassen Sie uns ein wenig darüber sprechen. Der Indizierungsablauf in SolrCloud ist wie folgt:

• Eingehende Dokumente werden von einem Knoten empfangen und an den zuständigen Shard Leader weitergeleitet.
• Vom Scherbenführer werden sie an alle Repliken für die Scherbe geschickt.
• Die Replikate reagieren auf ihren Anführer.
• Der Leader antwortet dem sendenden Knoten.
• Nachdem alle Leader geantwortet haben, antwortet der Ursprungsknoten dem Client. Zu diesem Zeitpunkt sind alle Dokumente für alle Knoten des Clusters in das tlog gespült worden!
• Wenn die JVM abstürzt, werden die Dokumente trotzdem sicher auf die Festplatte geschrieben. Wenn das Op-System abstürzt, dann nicht.
  • Wenn die JVM abstürzt (oder z.B. mit -9 beendet wird), wird das tlog beim Neustart erneut abgespielt.
  • Sie können die Konfiguration in solrconfig.xml dahingehend ändern, dass fsynch statt flush vor der Rückkehr ausgeführt wird, aber das ist nur selten notwendig. Bei Leadern und Replikaten ist die Wahrscheinlichkeit, dass alle Replikate gleichzeitig einen Hardware-Absturz erleiden, bei dem die Daten aller Replikate verloren gehen, gering. Einige Anwendungsfälle können nicht einmal dieses winzige Risiko tolerieren und nehmen daher den Preis eines geringeren Durchsatzes in Kauf.

Hinweis: tlogs werden bei einem Hard-Commit (openSearcher true oder false) automatisch „überrollt“. Das alte wird geschlossen und ein neues wird geöffnet. Es werden so viele tlogs aufbewahrt, dass sie 100 Dokumente enthalten [1], und ältere tlogs werden gelöscht. Stellen Sie sich vor, Sie indizieren in Stapeln von 25 Dokumenten und führen nach jedem Stapel ein hartes Commit durch (nicht, dass Sie so oft Commits durchführen sollten, aber ich sage das nur). Sie sollten zu jedem Zeitpunkt 5 Logs haben. Die ältesten vier (geschlossenen) enthalten jeweils 25 Dokumente, insgesamt also 100 plus die aktuelle Logdatei. Wenn das aktuelle tlog geschlossen wird, wird das älteste tlog gelöscht und ein neues geöffnet. Beachten Sie insbesondere, dass Solr nicht versucht, nur 100 Dokumente in ein bestimmtes tlog legen. Tlogs werden nur überschrieben, wenn Sie Solr dazu auffordern, d.h. einen Hard Commit durchführen (oder autoCommit passiert, konfiguriert in solrconfig.xml). Wenn Sie also 1.000 Dokumente pro Sekunde laden und eine Stunde lang keinen Hard Commit durchführen, enthält Ihr einziges Tlog 3.600.000 Dokumente. Und ein unvorhergesehenes Herunterfahren kann dazu führen, dass es komplett neu abgespielt wird, bevor der Solr-Knoten wieder zur Verfügung steht. Das kann Stunden dauern. Und da ich nicht die Geduld habe, einfach zu warten, denke ich, dass etwas nicht stimmt und starte Solr neu. Damit beginnt die Wiedergabe des Protokolls von vorne. Sie sehen, worauf das hinausläuft. Wenn Sie sehr große Tlogs haben, ist das eine schlechte Sache und Sie sollten Ihre Hard-Commit-Einstellungen ändern! Dies ist vor allem für diejenigen ein Problem, die aus den 3.x-Tagen kommen, als Hard Commits oft sehr langwierig waren, da sie immer teuer waren und es keine openSearcher=false Option gab.

Soft Commit

Bei Soft Commits geht es um die Sichtbarkeit, bei Hard Commits um die Dauerhaftigkeit. Das Wichtigste bei Soft Commits ist, dass sie Dokumente sichtbar machen, allerdings zu einem gewissen Preis. Insbesondere die „Top-Level“-Caches, die das enthalten, was Sie in solrconfig.xml konfigurieren (filterCache, queryResultCache usw.) , werden ungültig gemacht! Das Autowarming wird für Ihre Caches der obersten Ebene (z.B. filterCache, queryResultCache) durchgeführt, und alle newSearcher-Abfragen werden ausgeführt. Auch der FieldValueCache wird ungültig, so dass Facettenabfragen warten müssen, bis der Cache aktualisiert wird. Bei sehr häufigen Soft-Commits werden Ihre Top-Level-Caches oft nur wenig genutzt und können in einigen Fällen sogar ganz entfallen. Die „Segment-Level-Caches“, die für Funktionsabfragen, Sortierungen usw. verwendet werden, sind jedoch „pro Segment“ und werden daher bei einem Soft-Commit nicht ungültig gemacht; sie können weiterhin verwendet werden [2].

Sprechen Sie mir nach:„Bei Hard Commits geht es um Haltbarkeit, bei Soft Commits um Sichtbarkeit„.

Was bedeutet das alles?

Betrachten Sie einen Soft-Commit. Bei der Ausführung haben Sie Folgendes:

• Das tlog wurde NICHT gekürzt. Es wird weiter wachsen.
• Die Dokumente WERDEN sichtbar sein.
• Einige Caches müssen neu geladen werden.
• Ihre Top-Level-Caches werden ungültig gemacht.
• Es wird eine automatische Aufwärmung durchgeführt.

Beachten Sie, dass ich nichts über Indexsegmente gesagt habe! Das ist für Hard Commits. Und noch einmal: Soft Commits sind „weniger teuer“ als Hard Commits (openSearcher=true), aber sie sind nicht kostenlos. Das Motto der Mondkolonie in einem Science-Fiction-Roman („The Moon Is a Harsh Mistress“ von Robert Heinlein) war TANSTAAFL, There Ain’t No Such Thing As A Free Lunch. Soft Commits sind dazu da, Near Real Time zu unterstützen, und das tun sie auch. Aber sie haben ihren Preis. Verwenden Sie daher das längste Soft-Commit-Intervall, das Sie können, um die beste Leistung zu erzielen.

Engagieren Sie sich

Bei Hard Commits geht es um Beständigkeit, bei Soft Commits um Sichtbarkeit. Es gibt hier wirklich zwei Varianten, openSearcher=true und openSearcher=false. Zunächst werden wir darüber sprechen, was in beiden Fällen passiert. Wenn openSearcher=true oder openSearcher=false, sind die folgenden Konsequenzen am wichtigsten:

• Das tlog wird abgeschnitten: Ein neues tlog wird gestartet. Alte tlogs werden gelöscht, wenn sich mehr als 100 Dokumente in neueren, geschlossenen tlogs befinden.
• Das aktuelle Indexsegment wird geschlossen und gespült.
• Die Zusammenführung von Hintergrundsegmenten kann eingeleitet werden.

Dies geschieht bei allen harten Übertragungen. Damit bleibt die openSearcher-Einstellung

• openSearcher=true: Die Solr/Lucene-Sucher werden wieder geöffnet und alle Caches werden ungültig gemacht. Autowarming wird durchgeführt usw. Früher war dies die einzige Möglichkeit, neu hinzugefügte Dokumente zu sehen.
• openSearcher=false: Außer den vier oben genannten Punkten geschieht nichts weiter. Um die Dokumente zu durchsuchen, ist ein Soft Commit erforderlich.

Erholung

Ich habe oben über die Haltbarkeit gesprochen, also lassen Sie uns das noch ein wenig erweitern. Wenn ein Rechner abstürzt, die JVM beendet wird, was auch immer, ist dies der Zustand Ihres Clusters.

• Der letzte Aktualisierungsaufruf, der erfolgreich zurückgegeben wurde, hat alle Dokumente in die Logs im Cluster geschrieben. Die Standardeinstellung ist, dass das tlog geleert, aber nicht fsynchronisiert wurde. Wie oben beschrieben, können Sie dieses Standardverhalten außer Kraft setzen, aber es wird nicht empfohlen.
• Beim Neustart des betroffenen Rechners kontaktiert er den Leader und entweder
  • Spielt die Dokumente aus seinem eigenen Logbuch ab, wenn < 100 neue Aktualisierungen vom Leader erhalten hat. Beachten Sie, dass während dieser Wiedergabe zusätzliche Aktualisierungen, die eingehen, an das Ende des tlogs geschrieben werden und ebenfalls wiedergegeben werden müssen.
  • Führt eine vollständige Replikation im alten Stil vom Leader aus, um den Rückstand aufzuholen, wenn der Leader > 100 Aktualisierungen erhalten hat, während der Knoten offline war.

Die Wiederherstellung kann einige Zeit dauern. Dies ist eines der versteckten „Probleme“, auf die die Leute bei der Arbeit mit SolrCloud stoßen. Sie experimentieren, d.h. sie schieben die Server überall hin und her, töten Solr mit ‚kill -9‘ usw. Auf der einen Seite ist das großartig, da es den gesamten SolrCloud-Wiederherstellungsprozess trainiert. Auf der anderen Seite ist es aber auch nicht so toll, da es eine sehr künstliche Erfahrung ist. Wenn Knoten mehrmals am Tag verschwinden, haben Sie größere Probleme als die Tatsache, dass Solr beim Start einige Zeit braucht, um sich zu erholen, was behoben werden sollte!

Empfehlungen

Mir graut es immer davor, denn jede Empfehlung wird in manchen Fällen falsch sein. Meine erste Empfehlung wäre, nicht zu viel über das Problem nachzudenken. Einige sehr kluge Leute haben versucht, den gesamten Prozess robust zu gestalten. Probieren Sie zuerst die einfachen Dinge aus und ändern Sie sie nur bei Bedarf. Achten Sie insbesondere auf die Größe Ihrer Transaktionsprotokolle und passen Sie Ihre Hard-Commit-Intervalle so an, dass diese eine „vernünftige Größe“ haben. Denken Sie daran, dass der Nachteil vor allem in der Wiederholungszeit liegt, wenn Sie nach einem JVM-Absturz neu starten. Sind 15 Sekunden akzeptabel? Warum sollten Sie dann kleiner gehen? Wir haben schon Situationen erlebt, in denen das Hard-Commit-Intervall viel kürzer war als das Soft-Commit-Intervall, siehe die Massenindizierung weiter unten.

Anständig herunterfahren. Mit anderen Worten: „kill -9“ während der Indizierung birgt nur Ärger in sich

Dies bedeutet:

• Beenden Sie die Aufnahme von Dokumenten.
• Nehmen Sie eine feste Übergabe vor oder warten Sie, bis das autoCommit-Intervall abgelaufen ist.
• Stoppen Sie die Solr-Server.

Dies sind Einstellungen, mit denen Sie beginnen und die Sie an Ihre Situation anpassen können.

Schwere (Massen-)Indizierung

Wir gehen davon aus, dass Sie daran interessiert sind, viele Daten so schnell wie möglich in den Index zu bekommen, um sie irgendwann in der Zukunft durchsuchen zu können. Ich denke dabei an Originaldaten aus einer Datenquelle usw. [4]

• Legen Sie das Intervall für Soft Commits recht lang fest. Zum Beispiel 10 Minuten oder noch länger [3] (-1 für gar keine Soft Commits). Bei Soft Commits geht es um die Sichtbarkeit und ich gehe davon aus, dass es bei der Massenindizierung nicht um eine Suche in Echtzeit geht, so dass Sie sich nicht die zusätzliche Arbeit machen, irgendeine Art von Sucher zu öffnen.
• Setzen Sie Ihre festen Übergabe-Intervalle auf 15 Sekunden, openSearcher=false. Auch hier gehen wir davon aus, dass Sie Solr einfach mit Daten überschwemmen werden. Im schlimmsten Fall starten Sie Ihr System neu und müssen etwa 15 Sekunden lang Daten aus Ihrem tlog wiedergeben. Wenn Ihr System häufiger auf und ab springt, sollten Sie zuerst die Ursache dafür beheben.
• Erst wenn Sie die einfachen Dinge ausprobiert haben, sollten Sie über Verfeinerungen nachdenken, die in der Regel nur unter ungewöhnlichen Umständen erforderlich sind. Aber sie umfassen:
  • Vollständiges Ausschalten des tlog für die Bulk-Load-Operation
  • Offline-Indizierung mit einer Art Map-Reduce-Prozess
  • Nur ein Leader pro Shard, keine Replikate für die Last, dann schalten Sie die Replikate später ein und lassen sie eine Replikation im alten Stil durchführen, um aufzuholen. Beachten Sie, dass dies automatisch geschieht. Wenn der Knoten feststellt, dass er „zu weit“ vom Leader entfernt ist, startet er eine Replikation im alten Stil. Nachdem er den Rückstand aufgeholt hat, erhält er die Dokumente, sobald sie an den Leader indiziert werden, und führt sein eigenes tlog.
  • usw.

Index-Schwer, Query-Leicht

Damit meine ich zum Beispiel das Durchsuchen von Protokolldateien. Dies ist der Fall, wenn das System fast ständig mit einer großen Menge an Daten versorgt wird. Der Abfrageaufwand ist jedoch relativ gering, oft zur Fehlersuche oder Nutzungsanalyse. [4]

• Setzen Sie Ihr Soft-Commit-Intervall recht lang an, bis zu der maximalen Latenzzeit, die Sie für die Sichtbarkeit von Dokumenten ertragen können [3]. Das können nur ein paar Minuten oder auch viel länger sein. Vielleicht sogar Stunden mit der Möglichkeit, eine harte Übergabe (openSearcher=true) oder eine weiche Übergabe bei Bedarf durchzuführen.
• Setzen Sie Ihre feste Übergabe auf 15 Sekunden, openSearcher=false

Index-Leicht, Query-Leicht oder Schwer

Dies ist ein relativ statischer Index, der manchmal einen kleinen Schub an Indizierungen erhält. Sagen wir, alle 5-10 Minuten (oder länger) machen Sie eine Aktualisierung

• Sofern keine NRT-Funktionalität erforderlich ist, würde ich in dieser Situation auf Soft-Commits verzichten und alle 5-10 Minuten Hard-Commits mit openSearcher=true [3] durchführen. Wenn Sie die Indizierung mit einem einzigen externen Indizierungsprozess durchführen, kann es in dieser Situation sinnvoll sein, den Client den Hard Commit durchführen zu lassen.

Index-schwer, Query-schwer

Dies ist der Fall der Beinahe-Echtzeit (NRT), und er ist wirklich der schwierigste von allen. Hier ist Experimentieren angesagt, aber ich würde folgendermaßen beginnen

• Setzen Sie Ihr Soft-Commit-Intervall so lang an, wie Sie es aushalten können. Hören Sie nicht auf Ihren Produktmanager, der sagt: „Wir brauchen nicht mehr als 1 Sekunde Latenzzeit“. Wirklich. Ziehen Sie die Verzögerung stark zurück und sehen Sie, ob der Benutzer damit besser bedient ist oder es überhaupt bemerkt. Soft Commits und NRT sind ziemlich toll, aber sie sind nicht kostenlos.
• Stellen Sie das Intervall für die feste Übergabe auf 15 Sekunden ein.

SolrJ und HTTP und Client-Indizierung

Im Allgemeinen sind alle automatisch verfügbaren Optionen auch über SolrJ oder HTTP verfügbar. Die HTTP-Befehle sind hier dokumentiert. Die SolrJ-Befehle finden Sie in den Javadocs, Klasse SolrServer. Späte Bearbeitung (Jun, 2014) Seien Sie sehr vorsichtig bei der Beauftragung durch den Kunden! Tun Sie es auf keinen Fall. Im Großen und Ganzen sollten Sie keine Übertragungen von einem Client, der Solr indiziert, vornehmen, das ist fast immer ein Fehler. Und besonders in den Fällen, in denen mehrere Clients gleichzeitig indizieren, ist das eine schlechte Sache. Was passiert, ist, dass die Commits unvorhersehbar nahe beieinander liegen und die oben beschriebene Arbeit verursachen. Möglicherweise sehen Sie in Ihrem Protokoll Warnungen über „zu viele wärmende Sucher“. Oder Sie sehen eine Zillion kleiner Segmente. Oder… Überlassen Sie die Häufigkeit der Übertragungen Ihren Autocommit-Einstellungen (sowohl soft als auch hard) in solrconfig.xml. Wenn Sie die Sichtbarkeit unbedingt kontrollieren müssen, z.B. wenn Sie die Dokumente direkt nach der Indizierung durchsuchen wollen und es sich nicht leisten können, auf das Einsetzen Ihrer Autocommit-Einstellungen zu warten, dann führen Sie die Übergabe einmal am Ende durch. Ich würde das nur tun, wenn ich nur einen Indizierungsclient hätte. Andernfalls würde ich warten, bis alle Clients fertig sind, und eine „manuelle“ Übergabe durchführen, etwa so:

http://host:port/solr/collection/update?commit=true

es tun sollte, cURL es ein, senden Sie es von einem Browser aus, usw. In der SolrJ-Welt können Sie auch Dokumente zu Solr hinzufügen und ein „commitWithin“-Intervall, gemessen in Millisekunden, angeben. Das können Sie von so vielen SolrJ-Clients aus tun, wie Sie wollen, denn für Solr ist das alles dasselbe. Auf dem Server wird der Timer gestartet, wenn die erste Aktualisierung mit der Angabe commitWithin empfangen wird. Nach Ablauf der Millisekunden werden alle Dokumente, die von einem beliebigen Client empfangen wurden, ebenfalls committed, unabhängig davon, ob commitWithin angegeben wurde oder nicht. Mit der nächsten Aktualisierung, für die commitWithin angegeben wurde, wird ein neuer Timer gestartet. Und denken Sie daran: Die Optimierung eines Index ist nur selten notwendig! Viel Spaß beim Indizieren!

[1] Ich habe in allen Beispielen 100 für die Größe des tlog verwendet. Dies ist der Standardwert und war die einzige Wahl in der ursprünglichen Implementierung. Seit Solr 5.2 ist dies in solrconfig.xml konfigurierbar, indem Sie numRecordsToKeep im Abschnitt angeben .

[2] Drei Jahre, nachdem ich diesen Beitrag geschrieben hatte, stellte ein aufmerksamer Leser eine Frage bei der Lucene Revolution 2016 „Stump the chump“ Session. Die Frage lautete in etwa: „Erick Erickson sagt, dass Caches für einzelne Segmente bei einem Soft-Commit NICHT ungültig gemacht werden, bedeutet das, dass Facettenzählungen und ähnliches nach einem Soft-Commit ungenau sind?“. Als ich den Abschnitt noch einmal las, wurde mir die Verwirrung klar. Ich wollte damit sagen, dass sie nicht ungültig gemacht wurden, weil es keinen Grund gab, sie ungültig zu machen. Die Caches für die einzelnen Segmente sind immer noch genau, da sich die Segmente, auf die sie verweisen, nicht geändert haben. Die Verwendung von segmentbezogenen Caches für Facetten usw. ist also weiterhin korrekt, ohne dass sie neu geladen werden müssen. Pedantische Anmerkung: Die Tatsache, dass Dokumente aus diesem Segment gelöscht werden können, wird behandelt. Lucene/Solr „macht das Richtige“ mit gelöschten Dokumenten.

[3] Um Real Time Get zu unterstützen, werden bestimmte On-Heap-Strukturen für Dokumente aufbewahrt, die seit dem letzten Öffnen des Suchers indiziert wurden. Wenn Sie den Soft Commit auf ein sehr langes Intervall einstellen, kann diese Struktur unbegrenzt wachsen. Normalerweise brauchen Sie sich darüber keine Sorgen zu machen, aber Sie sollten sich dessen bewusst sein, wenn Sie ein unerklärliches Speicherwachstum feststellen und ein sehr langes Intervall für das Öffnen eines Suchers festgelegt haben.

[4] In Apache Solr 7.0 gibt es neue TLOG- und PULL-Replikate, die eine Alternative für eine umfangreiche Indizierung darstellen.

---

Dieser Beitrag wurde ursprünglich am 23. August 2013 veröffentlicht.