Die sieben Todsünden von Solr

Durch meine Arbeit bei Lucidworks habe ich die Möglichkeit, eine Vielzahl von Solr-Implementierungen zu analysieren und zu bewerten, die sowohl…

Durch meine Arbeit bei Lucidworks habe ich die Möglichkeit, eine Vielzahl von Solr-Implementierungen zu analysieren und zu bewerten, die sowohl in einigen der größten Fortune-500-Unternehmen als auch in einigen der kleinsten Start-ups laufen. Diese Erfahrung hat es mir ermöglicht, viele häufige Fehler und Fallstricke zu erkennen, die auftreten, wenn man mit einer neuen Solr-Implementierung beginnt oder nicht mit den neuesten Verbesserungen und Änderungen Schritt hält. Vielen Dank an meinen Kollegen Simon Rosenthal für den Vorschlag des Titels und an Simon, Lance Norskog und Tom Hill für hilfreiche Anregungen und Vorschläge. Also, ohne weitere Umschweife… die sieben Todsünden von Solr.

Sünde Nummer 1: Faulheit

Lassen Sie uns Faulheit als Faulheit oder Gleichgültigkeit definieren. Das trifft die meisten von uns irgendwann einmal. Wir können dem Impuls nicht widerstehen, eine Abkürzung zu nehmen, oder wir weigern uns einfach, den Aufwand anzuerkennen, der erforderlich ist, um eine Aufgabe richtig zu erledigen. Letztendlich zahlen wir den Preis dafür, meist mit Zinsen. Hier sind einige gängige Beispiele dafür, wie Faulheit oder Gleichgültigkeit zu Solr-Problemen führen.

• Ein allgemeiner Mangel an Engagement entweder für Solr oder für das Suchanwendungsprojekt selbst. Manchmal sieht man das, wenn ein Unternehmen beschlossen hat, von einer kommerziellen Suchanwendung zu Open-Source-Alternativen wie Lucene und Solr zu wechseln. Die an dem Projekt beteiligten Ingenieure sind an die „alten Wege“ gewöhnt und haben keine Lust, eine andere Suchtechnologie zu beherrschen. Ohne sich auch nur die geringste Mühe zu geben, werden sie also behaupten, Solr sei ineffizient, schwer zu erlernen, den Aufwand nicht wert, usw. Wenn Sie hungrig sind, ist es in der Regel nicht produktiv, herumzustehen und darauf zu warten, dass Ihnen ein gebratenes Hähnchen in den Mund fliegt – Ihre Zeit wäre vielleicht besser damit verbracht, sich etwas aktiver um die Beschaffung von Nahrung zu bemühen. Open-Source-Software ist flexibel, anpassungsfähig und leistungsstark, aber die Entwickler, die zu Experten für Open-Source-Lösungen werden, sind diejenigen, die sich nicht scheuen, die Ärmel hochzukrempeln und sich einzulesen, um zu lernen, was sie brauchen. Beteiligen Sie sich an den Mailinglisten. Öffnen Sie den Quellcode. Lesen Sie die Javadocs und das Referenzhandbuch. Ich habe mit Kunden zusammengearbeitet, die sich Solr zu eigen gemacht haben und in relativ kurzer Zeit zu Experten geworden sind, die sogar innerhalb weniger Wochen nach Beginn ihres Projekts Patches beigesteuert haben. Auf der anderen Seite habe ich erlebt, wie sich Probleme verfestigt haben, weil ein Team einfach keine Mühe in seine Solr-Implementierung investiert hat. „Es gibt niemanden, der so blind ist wie der, der nicht sehen will.“
• Kein Überprüfen, Bearbeiten oder Ändern der Standarddateien schema.xml und/oder solrconfig.xml. Wenn ich einen Dollar für jede produktive Solr-Instanz hätte, die die Abfrage „solr rocks“ statisch erwärmt, könnte ich mir ein Jahr Support von einem kommerziellen Suchanbieter leisten. Die Standard-Beispielkonfigurationsdateien sind dazu da, um als, ja, als Beispiele und als Ausgangspunkte verwendet zu werden. Nehmen Sie sich die Zeit, sich mit den Konfigurationseinstellungen und Feldtypen vertraut zu machen, und nutzen Sie sie optimal. Entfernen Sie alles, was nicht verwendet wird (wie oft haben Sie diesen „partitionierten“ Request Handler wirklich abgefragt…) Halten Sie Ihre Konfigurationsdateien schlank und pflegeleicht, und das wird sich langfristig auszahlen.
• Ignorieren des dismax Query Parsers. Ich habe Fälle gesehen, in denen jemand einen eigenen Abfrageparser geschrieben hat, obwohl die Arbeit, die er erledigen musste, leicht mit dem dismax Abfrageparser hätte erledigt werden können. Es gibt zwei verschiedene Extreme, warum die Leute dismax manchmal meiden. Auf der einen Seite hat man das Gefühl, dass es sich um einen „abgespeckten“ Parser handelt. Ich denke, ein Teil des Problems wird durch die erste Zeile in der DismaxRequestHandler-Dokumentation verursacht (übrigens leiden wir immer noch unter dieser unglücklichen Legacy-Nomenklatur – es handelt sich um einen Query Parser, nicht um einen Request Handler), in der es heißt, dass dismax „für die Verarbeitung einfacher, vom Benutzer eingegebener Phrasen konzipiert“ ist. Manchmal hat man den Eindruck, dass es sich lediglich um ein Einsteiger-Tool für diejenigen handelt, die keine Lust haben, sich mit der Ausarbeitung ihrer Abfragen zu beschäftigen. Au contraire! Dismax verfügt über ein enormes Maß an Leistung und Flexibilität. Das führt zur zweiten Seite der „Dismax-Vermeidung“, nämlich dass es „zu kompliziert“ ist. In der Tat ist es etwas kompliziert. Aber es lohnt sich, etwas Zeit zu investieren, um sich mit dem System vertraut zu machen.
• Zu wenig Aufmerksamkeit für JVM-Einstellungen und Garbage Collection. Man muss kein JVM-Jedi werden, um eine gut abgestimmte Solr-Instanz zu betreiben, aber etwas Zeit, um die Grundlagen der verschiedenen Garbage-Collector-Typen zu lernen und die JVM mit Tools wie JConsole zu überwachen, wird sich auszahlen. Ein guter Ausgangspunkt ist ein Blog meines Kollegen Mark Miller von Lucidworks. Eine weitere gute Quelle ist dieses von Sun herausgegebene Dokument.

Sünde Nummer 2: Gier

Pfennigfuchser und Pfundskerle. Das ist eine erstaunlich häufige Falle, in die manche tappen. Natürlich hat nicht jeder ein unbegrenztes Budget, aber manchmal werden schreckliche Entscheidungen getroffen, um die Ressourcen einzuschränken, Entscheidungen, die sich im Laufe der Zeit als teurer erweisen werden. Zum Beispiel:

• Die Weigerung, einem Server die richtige Menge an RAM hinzuzufügen. Es ist schon vorgekommen, dass ich auf meinem Mac-Laptop (4 GB) mehr Arbeitsspeicher hatte als einige der Solr-Produktionsimplementierungen, die ich gesehen habe. Manchmal sind sogar Solr-Projekte in großen Unternehmen unterfinanziert. Es wird geschäftliche Anforderungen geben, die einen hohen Speicherbedarf haben (Sortieren von großen String-Feldern, viele Facettierungen von Feldern mit einer großen Anzahl unterschiedlicher Begriffe usw.), aber es wird erwartet, dass dies mit einer unzureichenden Menge an Arbeitsspeicher und irgendeiner Art von Zauberei irgendwie „zum Laufen“ gebracht werden kann. Ein Freund von mir hat ein Sprichwort: „Man kann nicht 15 Pfund Reis in einen 10-Pfund-Sack packen.“ Legen Sie sich auf jeden Fall darauf fest, zumindest ein Minimum an angemessenen Ressourcen anzuschaffen.
• Bestehen Sie darauf, Indizierung und Suche auf demselben Host auszuführen. Eine der ersten Empfehlungen, die wir bei Lucidworks unseren Kunden häufig geben, ist die Trennung von Indizierung und Suche auf (mindestens) zwei getrennten Knoten. Dies bringt mehrere Vorteile mit sich. Erstens konkurrieren die Indizierungs- und Suchprozesse nicht um Ressourcen (CPU, Speicher usw.). Zweitens können die Knoten für eine optimale Leistung leicht unterschiedlich konfiguriert werden. Planen Sie auf der Grundlage der Anzahl der Dokumente, der Indexgröße und des erwarteten Abfragevolumens unbedingt eine angemessene Hardware ein.

Sünde Nummer 3: Stolz

Stolz (für unsere Zwecke): das Versäumnis, die gute Arbeit anderer anzuerkennen. Eine übermäßige Liebe zu sich selbst.

Ingenieure lieben es, zu programmieren. Das geht manchmal so weit, dass sie eine benutzerdefinierte Arbeit erstellen wollen, für die es vielleicht schon eine Lösung gibt, nur weil: a) sie glauben, dass sie es besser machen können. b) sie glauben, dass sie durch den Prozess lernen können. c) es „Spaß machen würde“. Dies soll Sie nicht davon abhalten, an einem Open-Source-Projekt mitzuarbeiten, Fehler zu beheben oder bestehende Funktionen zu verbessern. Aber seien Sie vorsichtig, dass Sie nicht überstürzt mit der Programmierung beginnen, bevor Sie wissen, welche Möglichkeiten bereits bestehen. Messen Sie zweimal, schneiden Sie einmal.

• Erfinden Sie das Rad nicht neu. Ich habe erlebt, dass Entwickler geradezu nach Ausreden suchen, um ihren eigenen Abfrageparser oder eine andere benutzerdefinierte Komponente zu schreiben. Manchmal ist ein solcher Aufwand notwendig, und zum Glück macht Open-Source-Software dies auf eine Weise möglich, die mit kommerzieller Such-Software niemals möglich wäre. Vergewissern Sie sich jedoch, dass Sie einen echten Bedarf haben, bevor Sie einen benutzerdefinierten Code schreiben – zumindest solange das Unternehmen die Kosten dafür trägt. Die Pflege einer benutzerdefinierten Codebasis und deren Synchronisierung mit Solr ist mit zusätzlichem Aufwand verbunden. Vergewissern Sie sich also, dass dies wirklich die einzige Möglichkeit ist, einen bestimmten Anwendungsfall zu lösen.
• Nutzen Sie die Mailinglisten und die Listenarchive. Das sollte eigentlich selbstverständlich sein, aber es gibt immer noch viele, die denken, dass dies irgendwie unter ihrer Würde ist, als ob um Hilfe zu bitten irgendwie ein Makel wäre. Andererseits sollten Sie beim Posten auf den Mailinglisten die Zeit aller Beteiligten effizient nutzen. Durchsuchen Sie die Listenarchive gründlich, bevor Sie etwas posten. (Lucidworks Search Hub macht es zum Kinderspiel, relevante Mailinglisten, Dokumentationen, Blogs, Javadoc und andere Quellen an einem Ort zu durchsuchen.) Wenn Sie eine Frage stellen, beschreiben Sie das Problem kurz und bündig und machen Sie den anderen klar, was Sie brauchen. Bleiben Sie während des gesamten Threads beim Thema. Lucene- und Solr-Committer und Lucidworks-Mitarbeiter nehmen regelmäßig an den Mailinglisten teil. Nutzen Sie diese Ressource, wenn Sie ein echtes Problem haben.

Sünde Nummer 4: Lust

Sie müssen mir in diesem Fall künstlerische Freiheit zugestehen, sonst können wir diesen Blog nicht mehr als jugendfrei bezeichnen. Definieren wir also Lust als „ein unnatürliches Verlangen nach etwas, das bis zur Zügellosigkeit oder zum Wahnsinn geht“. NA GUT.

• Die JVM Heap-Größe wurde zu hoch angesetzt, so dass nicht genug RAM für das Betriebssystem übrig blieb. Wir haben also endlich die RAM-Zuteilung erhalten, auf die wir so lange gewartet haben (siehe: Gier) und was machen wir jetzt? Wir haben jetzt 16 GB RAM auf unserem Rechner, also weisen wir dem Heap, auf dem Solr läuft, 15 GB zu. Puh! Zeit für eine kalte Dusche! Solr mag das einzige Objekt Ihrer Begierde sein, aber vernachlässigen Sie nicht das Betriebssystem. Hier sind Geduld und Aufmerksamkeit gefragt. Überwachen Sie die JVM unter Last und ermitteln Sie, wie groß der Speicherbedarf von Solr wirklich ist. Sie möchten, dass das Betriebssystem in der Lage ist, Dateisystemdaten zwischenzuspeichern (insbesondere die Lucene-Indizes), also stellen Sie sicher, dass genügend RAM für das Betriebssystem zur Verfügung steht.
• Zu viel Aufmerksamkeit für die JVM und die Garbage Collection. Andererseits (und im direkten Gegensatz zu unserem ersten Aufzählungspunkt unter Gier) sollten Sie es mit der JVM nicht übertreiben. Es gibt scheinbar unendlich viele Möglichkeiten, eine JVM zu optimieren und abzustimmen. Tappen Sie nicht in die Falle, jede obskure JVM- oder GC-Einstellung auszuprobieren, es sei denn, Sie sind ein JVM-Experte. Sobald Sie die Grundlagen der JVM beherrschen und die Unterschiede zwischen den verschiedenen Arten von Garbage Collectors verstehen, sollten Sie in den meisten Fällen nicht mehr allzu kreativ werden müssen. Werfen Sie nicht einfach aus Neugierde „-XX:CMSIncrementalDutyCycleMin=10“ in den Mix.
• Versuchen Sie, die Grenzen der automatischen Erwärmung auszuloten. Wie warm ist zu warm? Wir alle wünschen uns schnellstmögliche Antwortzeiten bei der Suche, und die automatische Erwärmung des queryResultCache und des filterCache von Solr sind wichtige Hilfsmittel, um die Antworten für die beliebtesten Abfragen so schnell wie möglich zu halten. Aber wir sollten es nicht übertreiben. Eine übermäßige Anzahl von automatischen Aufwärmvorgängen kann zu übermäßigen Aufwärmzeiten für die Caches führen, was sich wiederum auf die Aufwärmzeit neuer IndexSearcher nach jeder Übertragung auswirkt. Fragen Sie sich, ob Sie wirklich bei jedem Commit die ersten 5.000 Abfragen automatisch aufwärmen müssen. Es kann leicht passieren, dass die Zeit zum Aufwärmen eines neuen IndexSearchers Ihre Commit-Zyklen übersteigt, was zu allen möglichen seltsamen Verhaltensweisen führen kann, einschließlich OutOfMemory Exceptions. Vergewissern Sie sich, dass Sie Ihre durchschnittlichen Aufwärmzeiten für alle Ihre Caches und Ihre neuen IndexSearcher kennen. Es ist tatsächlich besser, mit bescheideneren Auto-Warming-Zahlen zu beginnen und diese bei Bedarf zu erhöhen, als mit zu hohen Werten zu beginnen. Erstellen Sie Berichte oder Datenbankeinträge über Benutzerabfragen, indem Sie Ihre Produktionsprotokolldateien analysieren. Verwenden Sie diese Daten, um ein Gefühl dafür zu bekommen, welches die beliebtesten Abfragen sind. Manchmal reicht es aus, die automatische Zählung auf 100 zu setzen. Aber es braucht Zeit und Mühe, um den goldenen Mittelweg zwischen Caches, die zu kühl sind, und Caches, die „en fuego“ sind, zu finden.

Sünde Nummer 5: Neid

• Sie wollen Funktionen, die andere Websites haben, die Sie aber nicht brauchen. Konzentrieren Sie sich auf Ihre geschäftlichen Anforderungen. Stellen Sie sicher, dass Sie wissen, was Sie von Ihrer Suchanwendung wirklich brauchen. Ein häufiges Szenario auf den Mailinglisten ist eines, das der Lucene/Solr-Committer Chris Hostetter das „XY“-Problem nennt. Aus der Mailingliste für Solr-Benutzer: „Sie haben es mit ‚X‘ zu tun, Sie nehmen an, dass ‚Y‘ Ihnen helfen wird, und Sie fragen nach ‚Y‘, ohne mehr Details über ‚X‘ zu geben, damit wir das ganze Problem verstehen können. Vielleicht beinhaltet die beste Lösung überhaupt kein ‚Y'“. Wissen Sie, was Sie brauchen und konzentrieren Sie sich auf die Anforderungen.
• Der Wunsch, einen größeren Index zu haben als der andere. Das Gegenteil von „Gier“, wenn man nicht genug Ressourcen zur Verfügung stellt. „Auf den Mond schießen“ und versuchen, ein mögliches Wachstum in den nächsten 20 Jahren zu berücksichtigen. Eine Falle für diejenigen, die glauben, dass ihr Status durch die Größe ihrer Serverfarm bestimmt wird. Planen Sie auf jeden Fall voraus, aber erwarten Sie nicht, dass Sie in die Zukunft sehen können, um jedes mögliche Szenario vorherzusehen. Planen Sie klug, aber übertreiben Sie es nicht.

Sünde Nummer 6: Völlerei

„Fit und schlank bleiben“ ist normalerweise eine gute Praxis bei der Entwicklung und Ausführung von Solr-Anwendungen. Viele dieser Probleme fallen in die Kategorie „Faulheit“ und sind in der Regel Fälle, in denen der zusätzliche Aufwand, Ihre Konfiguration und Daten effizient zu verwalten, nicht als wichtig erachtet wird.

• Mangelnde Beachtung der Feldkonfiguration im Schema. Speichern von Feldern, die nie abgerufen werden. Indizierung von Feldern, die nie durchsucht werden. Speichern von Termvektoren, Positionen und Offsets, die nie verwendet werden. Unnötige Aufblähung. Verstehen Sie Ihre Daten und Ihre Benutzer und gestalten Sie Ihr Schema und Ihre Felder entsprechend.
• Ungeprüfte Abfragen, die redundant oder ineffizient sind. Ich habe Fälle gesehen, in denen Abfragen programmatisch mit viel Redundanz und unsinniger Logik erstellt wurden. Nutzen Sie die Vorteile von Filterabfragen, wann immer dies möglich ist. Wenn Sie zum Beispiel eine Abfrage wie diese haben – &q=inhalt:solr AND datenquelle:wiki AND kategorie:suche AND sprache:en – verwenden Sie Filterabfragen für Felder, bei denen es Sinn macht: &q=inhalt:solr&fq=datenquelle:wiki&fq=kategorie:suche&fq=sprache:en.

Sünde Nummer 7: Zorn

Während Zorn normalerweise als Synonym für Wut angesehen wird, wollen wir hier eine ältere Definition verwenden: „eine vehemente Verleugnung der Wahrheit, sowohl gegenüber anderen als auch in Form von Selbstverleugnung, Ungeduld.“

• Sie gehen davon aus, dass Sie Ihre Daten niemals neu indizieren müssen. Es ist leicht, sich auf Schemadesign, Konfiguration, Bereitstellung, Skalierungsprobleme, Leistung und Relevanzoptimierung zu konzentrieren und dabei zu vernachlässigen, wie Sie Ihren Index im Falle einer größeren oder kleineren Katastrophe neu erstellen können. Ein Schritt, den Sie bei Ihrer Planung niemals auslassen sollten, ist die Überlegung, wie Sie Ihren Index im Falle eines Hardwareausfalls neu erstellen können. Wenn Sie von einem Master auf einen oder mehrere Slaves replizieren, sollten Sie einen zusätzlichen Slave in Betracht ziehen, der zwar nicht für die Suche verwendet wird, aber Replikationen des Index empfangen kann, um als Backup für den Master zu dienen. Wenn möglich, sichern Sie Ihre Indexdaten auf anderen Speichermedien. Wenn Sie keinen großen Index haben und diesen ohne großen Aufwand neu erstellen können, wenn er gelöscht wird oder verloren geht, sollten Sie zumindest einen Plan und Verfahren für eine schnelle Neuindizierung haben.
• Eile bei der Produktion. Natürlich haben wir alle Fristen, aber Sie haben nur eine Chance, einen ersten Eindruck zu hinterlassen. Vor Jahren war ich an einem Projekt beteiligt, bei dem wir unsere Suchanwendung vorzeitig (vor dem Zeitplan) freigegeben haben, weil das Unternehmen entschied, dass es besser sei, etwas zu haben, als keine Suchoption zu haben. Wir Entwickler waren der Meinung, dass wir mit weiteren vier Wochen Arbeit ein voll funktionsfähiges System liefern könnten, das eine hervorragende Suchanwendung sein würde. Aber wir stürzten uns in die Produktion und hatten einige große Mängel. Unsere Kunden waren wütend, als sie nach ihren Produkten suchten und sie nicht finden konnten. Wir bekamen einen schlechten Ruf, verärgerten einige Geschäftspartner und verloren Geld, nur weil wir es für notwendig hielten, eine Suchanwendung vier Wochen früher zum Laufen zu bringen.

Halten Sie es also einfach, bleiben Sie klug, bleiben Sie auf dem Laufenden und halten Sie Ihre Suchanwendung auf dem rechten Weg. Suchen Sie (klug) und Sie werden finden.

Sieben Todsünden Gemälde von Hieronymus Bosch