Dimensionierung von Hardware in der Abstraktion: Warum wir keine endgültige Antwort haben

Oder „Warum können Sie eine einfache Frage nicht beantworten?“ Ein Kunde nach dem anderen und ein Benutzer nach dem anderen…

Oder „Warum können Sie eine einfache Frage nicht beantworten?“

Ein Kunde nach dem anderen und ein Benutzer nach dem anderen (auf der Liste des Benutzers) stellen die durchaus vernünftige Frage: „Was für eine Hardware brauchen wir, um Solr auszuführen, wenn wir Dokumente der Größe X haben? Mich schaudert es jedes Mal, wenn diese Frage gestellt wird, denn unsere Antwort lautet unweigerlich „Es kommt darauf an ™“. Das ist so, als würden Sie fragen: „Wie groß muss der Rechner sein, auf dem ein C-Programm läuft? Sie müssen wissen, was das Programm zu tun versucht und wie viele Daten es enthält. Die Anzahl der Dokumente, die Sie in einer einzigen Instanz von Solr speichern können, wird meist durch den Heap von Java begrenzt. Um Ihnen eine Vorstellung davon zu geben, wie groß die Bandbreite ist, haben wir bei Lucidworks gesehen:

• 10M Dokumente benötigen 64G Java Heap. Zing wurde verwendet, um GC unter Kontrolle zu halten
• 300M Dokumente passen in 12G Java Heap.

In der Regel antworten wir: „Das können wir nicht abstrakt sagen, Sie müssen einen Prototyp erstellen“. Das ist keine Faulheit unsererseits. Wir antworten so, weil bei der Beantwortung dieser Frage eine Reihe von Faktoren eine Rolle spielen und die Kunden selten im Voraus wissen, wie die tatsächlichen Merkmale der Daten und Suchmuster aussehen werden. Die Beantwortung dieser Frage erfordert in der Regel ohnehin die Erstellung von Prototypen. Ich persönlich habe mindestens dreimal versucht, eine Matrix zu erstellen, die bei der Beantwortung dieser Frage helfen soll, und habe nach einer Weile aufgegeben, weil die Antworten selbst für dieselbe Reihe von Dokumenten so stark variieren!

Letzteres ist etwas kontra-intuitiv. Um ein vereinfachtes Beispiel zu verwenden: Nehmen wir an, ich habe einen Korpus von 11 Millionen Dokumenten indiziert. Ich habe zwei Felder, beides Stringfelder „type“ und „id“. Type hat 11 eindeutige Werte und id hat 11M eindeutige Werte (es ist ein <uniqueKey>). Der Einfachheit halber ist jeder eindeutige Wert in diesen Feldern genau 32 Zeichen lang. Die Speicherung eines Strings in Java ist mit einem gewissen Overhead verbunden, und Solr behält einige zusätzliche Informationen, z.B. für die Sortierung. Der Gesamtspeicher, den Solr benötigt, um einen Wert für die Sortierung zu speichern, beträgt 56 Bytes + (2 * characters_in_string), soweit ich mich erinnere. In der 3.x-Codezeile wird also der RAM-Speicher für die Sortierung nach:

• Das Feld „Typ“ ist trivial (11 * (56 + 64) = 1.320) Bytes.
• Das Feld „id“ ist, nun ja, 1 Million mal so groß (11.000.000 * (56 + 64) = 1.320.000.000) Bytes.

Jetzt sehen Sie, warum es keine einfache Antwort gibt. Die Größe des Quelldokuments ist für den Speicherbedarf im obigen Beispiel fast völlig irrelevant. Jedes Dokument könnte sehr kurz sein, 32 Bytes für die „id“ und 32 Bytes für „type“. Natürlich benötigen Sie auch Ressourcen für den invertierten Index, die Facettierung, die Zwischenspeicherung von Dokumenten, die Zwischenspeicherung von Filterabfragen, usw. usw. ….. Jede einzelne dieser Funktionen kann sehr unterschiedliche Ressourcen erfordern, je nachdem, wie sie verwendet werden. „Es kommt darauf an ™“.

Aber was ist mit einem „durchschnittlichen“ Dokument?

Das führt zu der Frage: „OK, Sie können es nicht genau sagen. Aber haben Sie nicht wenigstens ein paar Durchschnittswerte? Können Sie angesichts der Tatsache, dass unsere Dokumente durchschnittlich ### Bytes groß sind, nicht eine Schätzung abgeben?“ Leider gibt es so etwas wie ein „durchschnittliches“ Dokument nicht. Hier sind ein paar Beispiele:

• MS Word-Dokumente. Im Verzeichniseintrag steht, dass unsere Word-Dokumente durchschnittlich 16K groß sind. Können Sie diese Zahl nicht verwenden? Leider nicht, es sei denn, Sie können uns sagen, wie viel Text in jedem Dokument enthalten ist. Bei den 16K kann es sich um das einfachste Word-Dokument der Welt handeln, das 1K an Formatierungsinformationen enthält, der Rest ist Text. Es kann ein Word-Dokument mit 1K Text und dem Rest Grafiken sein, und Solr indiziert keine nicht-textuellen Daten.
• Videos. Das ist sogar noch schlimmer. Wir garantieren praktisch, dass 99,9 % eines Videos weggeworfen werden, da es sich um nicht-textliche Daten handelt, die in Solr nicht indiziert werden. Und beachten Sie die Raffinesse hier. Auch wenn wir fast alle Bytes wegwerfen, könnte die Sortierung immer noch wie oben beschrieben aussehen und überraschend viel Speicherplatz beanspruchen!
• RDBMS. Das ist mein Favorit. Es geht in der Regel so: „Wir haben 7 Tabellen, Tabelle 1 hat 25M Zeilen, 3 numerische Spalten und 3 Textspalten mit durchschnittlich 120 Byte, Tabelle 2 hat 1M Zeilen, 4 Spalten, 2 numerische und 2 Textspalten mit durchschnittlich 64 Byte. Tabelle 3 hat…“. Nun, in Solr müssen Sie die Daten oft denormalisieren, um die Benutzerfreundlichkeit zu optimieren. Je nach Datenbankstruktur könnte jede Zeile in Tabelle 1 mit 100 Zeilen in Tabelle 2 verknüpft sein und die Denormalisierung der Daten könnte erfordern, dass Sie (25.000.000 * 100 * 64 * 2) Bytes an Rohdaten nur für die beiden Tabellen haben! Andererseits könnten Tabelle 1 und Tabelle 2 auch überhaupt keine Join-Beziehung haben. Der Versuch, abstrakt vorherzusagen, was das für Solr bedeutet, ist also ein guter Weg, um verrückt zu werden.
  • Und wenn Sie wirklich verrückt werden wollen, überlegen Sie, was es bedeutet, wenn sich herausstellt, dass einige der Zeilen in Tabelle 1 BLOBs haben, die mit Text verbunden sind.
• Ich habe einmal an einem Ort gearbeitet, an dem, ehrlich gesagt, eines der „Dokumente“ eine 23-bändige Fachenzyklopädie war (ich würde Sie nicht anlügen).

Und dabei geht es noch nicht einmal darum, wie die Daten in diesen Dokumenten verwendet werden. Wie das obige Beispiel zeigt, ist die Art und Weise, wie die Daten verwendet werden, genauso wichtig wie ihre reine Größe.

Andere Faktoren bei der Größenbestimmung einer Maschine

Im ersten Beispiel oben geht es nur um die Sortierung nach ein paar Feldern. Hier finden Sie eine Liste von Fragen, mit deren Hilfe Sie zumindest feststellen können, ob es sich bei der Hardware um handelsübliche PCs oder Supercomputer handeln muss:

• Für jedes Feld, das Sie für die Sortierung verwenden werden
  • Wie viele eindeutige Werte wird es geben?
  • Welche Art von Werten gibt es jeweils? (String? Datum? Numerisch?)
• Für jedes Feld, das Sie für die Facettierung verwenden
  • Wie viele eindeutige Werte wird es geben?
  • Welche Arten von Werten?
• Wie viele Filterabfragen müssen im Cache gespeichert werden?
• Wie viele Dokumente werden Sie in Ihrem Korpus haben?
• Wie groß sind die von Ihnen zurückgegebenen Seiten (d. h. wie viele Ergebnisse möchten Sie auf einmal anzeigen)?
• Werden die Suchergebnisse vollständig aus Solr-Inhalten erstellt oder holen Sie einen Teil der Informationen aus einer anderen Quelle (z. B. RDBMS, Dateisystem)?
• Wie viele Dokumente werden Ihrer Meinung nach durchschnittlich in jedem Segment gelöscht? (*)
• Beabsichtigen Sie, eigene Caches einzurichten? (*)
• Für wie viele Felder wollen Sie Termvektoren speichern und wie viele Terme in jedem Feld? (**)
• Für wie viele Felder wollen Sie Normen speichern und wie viele Begriffe in jedem Feld? (**)
• Wie werden Ihre Benutzer ihre Abfragen strukturieren? (***)
• Wie hoch ist die Abfragelast, die Sie unterstützen müssen?
• Was sind akzeptable Antwortzeiten (Max/Median/99. Perzentil)?

Mit den Einträgen, die mit (*) und (**) gekennzeichnet sind, habe ich Ihnen einen Strich durch die Rechnung gemacht. Von einem Kunden die Beantwortung dieser Fragen zu verlangen, vorausgesetzt, er ist nicht bereits Solr-/Such-Experte, ist einfach grausam. Sie sind Kauderwelsch, solange Sie das Endprodukt (und Solr) nicht gründlich verstehen. Aber sie haben Auswirkungen auf Ihre Hardwareanforderungen (vor allem auf den Arbeitsspeicher)!

Die mit (**) gekennzeichneten Einträge können bereits in einem frühen Stadium des Prozesses beantwortet werden , wenn ein Kunde Fragen wie „Sollen Phrasenabfragen unterstützt werden?“ und „Soll die Längennormalisierung berücksichtigt werden?“ beantworten kann. Letzteres ist ebenfalls Kauderwelsch, es sei denn, Sie verstehen, wie Solr/Lucene Scoring funktioniert.

Und der mit (***) markierte Eintrag ist einfach unmöglich zu beantworten, es sei denn, Sie bilden die Abfragen entweder streng programmatisch oder haben eine bestehende Anwendung, die Sie nach Abfragen durchsuchen können. Und selbst wenn Sie Abfragen aus einer bestehenden Anwendung haben, ändert sich das Nutzungsverhalten der Benutzer sehr oft, wenn sie ein neues System benutzen.

Ein weiteres Problem ist, dass die Antworten auf diese Fragen oft erst dann gegeben werden, wenn die Produktmanager sehen, welche Auswirkungen z.B. das Weglassen von Normen hat. Und das können sie erst sehen, wenn ein Prototyp verfügbar ist. Man kann also eine „beste Vermutung“ über die Antworten anstellen, einen Prototyp erstellen und messen.

Haben Sie Mitleid mit den Einsatzkräften

Irgendwo in Ihrem Unternehmen gibt es eine Gruppe, die für die Bestellung von Hardware und deren reibungslosen Betrieb zuständig ist. Ich habe volles Verständnis dafür, wenn die Person, die für die Koordinierung mit dieser Gruppe zuständig ist, die Antwort „Wir können Ihnen erst nach dem Prototyp sagen, welche Hardware Sie benötigen“ nicht mag. Sie müssen die Hardware kaufen, sie bereitstellen und mitten in der Nacht aufwachen, wenn das System zum Stillstand kommt, und versuchen, es wieder zum Laufen zu bringen, bevor der ganze Verkehr am nächsten Morgen losgeht. Wenn Sie die Mitarbeiter des Betriebs bitten, mit der Bestellung von Hardware zu warten, bis Sie einen Prototyp in Betrieb haben und Messungen vornehmen können, bekommen sie zu Recht einen Ausschlag. Die (berechtigte) Befürchtung ist, dass sie die Informationen, die sie für ihre Arbeit benötigen, erst eine Woche vor der Inbetriebnahme erhalten werden. Seien Sie nett zu Ihren Mitarbeitern und bringen Sie den Prototyp als erstes zum Laufen.

Haben Sie Mitleid mit den Projektträgern

Die Führungskräfte, die für ein Lucidworks- oder Solr-Projekt verantwortlich sind, bekommen ebenfalls Ausschlag, wenn man ihnen sagt: „Wir werden erst in ein oder zwei Monaten wissen, welche Art von Maschine wir brauchen“, und das zu Recht. Sie müssen schließlich um Geld bitten, um Ihr Gehalt zu bezahlen und Hardware zu kaufen. Und Sie sagen ihnen: „Wir wissen nicht, wie viel Hardware wir brauchen, aber lassen Sie sich das Budget trotzdem genehmigen“.

Der beste Rat, den ich Ihnen geben kann, ist, Ihnen anzubieten, einen Prototyp zu erstellen (siehe unten). Glücklicherweise können Sie Velocity Response Writer oder die Lucidworks-Benutzeroberfläche verwenden, um zu sehen, wie die Suchergebnisse aussehen. So erhalten Sie sehr schnell eine gute Vorstellung davon, welche Arten von Suchen Sie unterstützen möchten. Es wird nicht die Benutzeroberfläche für Ihr Produkt sein, aber Sie können damit sehen, wie die Suchergebnisse aussehen. Und oft können Sie ein Stück Hardware verwenden, das Sie herumliegen haben (oder eine Cloud-Maschine mieten), um einige Stresstests durchzuführen. Bieten Sie Ihrem Sponsor ein definiertes Go/No-Go-Prototyping-Projekt an; so ist zumindest das Risiko bekannt.

Und die Arbeit wird nicht umsonst gewesen sein, wenn Sie das Projekt fortsetzen. Meiner Meinung nach sind Stresstests vor dem Go-Live erforderlich. Das UI-Prototyping wird erforderlich sein, bevor Sie eine anständige Benutzererfahrung haben.

Die andere Sache, die Sie Ihrem Sponsor anbieten können, ist, dass „Solr rockt“. Wir können Ihnen sagen, dass wir Kunden haben, die Milliarden von Dokumenten indizieren und durchsuchen und dabei Antwortzeiten von unter einer Sekunde erzielen. Allerdings haben sie etwas anderes als handelsübliche PCs, auf denen ihre Anwendungen laufen, und sie mussten….

Prototyping: Wie Sie dieses Problem in den Griff bekommen

Natürlich kann man nicht sagen: „Bauen Sie einfach alles zusammen und gehen Sie live, dann werden Sie es schon herausfinden“. Zum Glück kann man verlässliche Schätzungen vornehmen, aber dazu muss man Prototypen erstellen. Wir empfehlen Folgendes.

Nehmen Sie eine Maschine, von der Sie glauben, dass sie dem, was Sie für die Produktion verwenden möchten, nahe kommt, und stellen Sie Ihre beste Vermutung darüber an, wie sie verwendet werden wird. Eine „beste Schätzung“ kann Folgendes beinhalten:

• Durchsuchen Sie alle aktuellen Anwendungen nach Nutzungsmustern
• Arbeiten Sie mit Ihren Produktmanagern zusammen, um realistische Szenarien zu erstellen
• Beschaffung von Daten, entweder durch deren Synthese oder durch Verwendung Ihrer echten Dokumente
• Abfragen erhalten, entweder durch Synthese oder durch Auswertung bestehender Anwendungen

Sobald dies geschehen ist, benötigen Sie zwei Zahlen für Ihre Zielhardware: wie viele Abfragen pro Sekunde Sie durchführen können und wie viele Dokumente Sie auf diesem Rechner speichern können.

Um die erste Zahl zu erhalten, wählen Sie eine „vernünftige“ Anzahl von Dokumenten. Ich persönlich wähle eine Zahl in der Größenordnung von 10 Millionen. Verwenden Sie nun eines der Lasttest-Tools (jMeter, SolrMeter), um genügend Abfragen abzufeuern (Sie müssen Beispielabfragen erstellt haben!), um den Rechner zu sättigen. Solr zeigt normalerweise eine abflachende QPS-Rate. Damit meine ich, dass Sie, sagen wir, 10 (oder 50 oder 100) QPS erreichen und dort bleiben. Wenn Sie mehr Abfragen starten, ändert sich die durchschnittliche Antwortzeit, aber die QPS-Rate bleibt relativ konstant.

Nehmen Sie nun z.B. 80 % der obigen QPS-Rate und fügen Sie der Solr-Instanz Dokumente in Schritten von z.B. 1 Mio. hinzu, bis der Rechner umkippt. Das kann weniger elegant sein, als den Rechner mit Abfragen zu sättigen. Sie können einen Wendepunkt erreichen, an dem die Antwortrate dramatisch ansteigt.

Jetzt haben Sie zwei Zahlen: die maximale QPS-Rate, die Sie erwarten können, und die Anzahl der Dokumente, die Ihre Zielhardware verarbeiten kann. Verschiedene Überwachungstools können Sie warnen, wenn Sie sich einer der beiden Zahlen nähern, so dass Sie vorbeugende Maßnahmen ergreifen können.

Beachten Sie, dass es eine beträchtliche Anzahl von Tuning-Parametern gibt, die diese Zahlen beeinflussen können. Die Übung, diese frühzeitig zu verstehen, ist von unschätzbarem Wert für die laufende Wartung. Noch wertvoller wird es sein, wenn Sie ein Test-Kabelbaum haben, mit dem Sie die Änderungen, die Sie für die Version N + 1 vornehmen möchten, testen können. Ganz zu schweigen von den interessanten Tricks, die man mit Multi-Core-Maschinen anwenden kann.

Skalierung

OK, Sie haben diese magischen Zahlen für die Abfrageraten und die Anzahl der Dokumente pro Maschine. Was passiert, wenn Sie sich diesen Zahlen nähern? Dann werden Sie den Standard-Solr-Skalierungsprozess implementieren.

Solange der gesamte Index auf einen einzigen Rechner mit angemessener Leistung passt, können Sie bei Bedarf skalieren, indem Sie einfach weitere Slave-Rechner hinzufügen, um die von Ihnen benötigte QPS-Rate zu erreichen.

Wenn Sie sich der Anzahl der Dokumente nähern, die Sie auf einem einzigen Rechner hosten können, müssen Sie entweder auf einen größeren Rechner umziehen oder Shards anlegen. Wenn Sie ein Wachstum erwarten, das ein Sharding erforderlich macht, können Sie mit mehreren Shards beginnen (die vielleicht auf einem einzigen Rechner gehostet werden), um diese später bei Bedarf auf separate Hardware zu verteilen.

Diese Themen werden an anderer Stelle behandelt, so dass ich sie hier nicht noch einmal im Detail wiederholen werde, aber es handelt sich um Standard-Solr-Anwendungsfälle:

• http://wiki.apache.org/solr/CollectionDistribution
• http://wiki.apache.org/solr/DistributedSearch/

Und es kommt noch schlimmer

Angenommen, Sie haben ein Modell für Ihr Nutzungsverhalten erstellt und es in eine schöne Tabelle eingepasst. Nun möchten Sie einige der raffinierten Funktionen von Solr 4.x nutzen. Ihr Modell ist nun fast, aber nicht ganz, nutzlos.

Es gab einige bemerkenswerte Verbesserungen bei der Speichernutzung von Solr/Lucene mit den FST-basierten Strukturen in der 4.x-Codezeile (jetzt in Alpha). Hier sind einige nützliche Blogs:

• Weitere Hintergrundinformationen finden Sie in den Blogbeiträgen von Mike McCandless: http://blog.mikemccandless.com/2010/12/using-finite-state-transducers-in.html und http://blog.mikemccandless.com/2011/01/finite-state-transducers-part-2.html.
• Wenn Sie sehen möchten, wie viel Arbeit in so etwas steckt, besuchen Sie http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html.
• Falls Sie es nicht wissen, ich bin ein Fan von Mikes Blogs….
• Ich habe hier darüber gebloggt: http://www.lucidimagination.com/blog/2012/04/06/memory-comparisons-between-solr-3x-and-trunk/.

Warum schweife ich hier ab? Weil bei einigen Tests, die ich durchgeführt habe, der Speicherbedarf für dieselben Operationen zwischen 3.x und trunk/4.0 (4.0-ALPHA ist erschienen) um 2/3 gesunken ist. Selbst wenn Sie also die richtige Formel für die Berechnung all dieser Dinge in der Zusammenfassung für 3.x Solr haben, könnten diese Informationen jetzt irreführend sein. Ich gebe zu, dass ich einen Worst-Case-Test verwendet habe, aber dies ist ein weiteres Beispiel dafür, warum Ihnen ein Prototyp und ein Stresstest-Setup gute Dienste leisten werden.

Und SolrCloud (Solr mit ZooKeeper für automatische verteilte Indizierung, Suche und nahezu Echtzeit) verändert das Spiel ebenfalls erheblich. Manchmal wünsche ich mir, die Entwickler würden eine Weile stillhalten und mich aufholen lassen!

Persönliche Tirade

Ich habe mehr Jahre mit dem Programmieren verbracht, als ich zugeben möchte. Es hat lange gedauert, bis ich aufgehört habe, den Leuten zu sagen, was sie hören wollten, selbst wenn diese Antwort Unsinn war! Das Problem bei dem Versuch, die Größenfrage zu beantworten, ist genau das Problem, mit dem Entwickler konfrontiert werden, wenn sie gefragt werden: „Wie lange brauchen Sie, um dieses Programm zu schreiben?“; alles, was Sie sagen, wird so ungenau sein, dass es schlimmer ist als gar keine Antwort. Die gesamte Methodik der Agilen Programmierung lehnt es ausdrücklich ab, genaue, weit entfernte Schätzungen abzugeben, und ich bin ein Bekehrter.

Ich denke, es ist weitaus freundlicher, den Leuten von vornherein zu sagen: „Ich kann Ihnen keine Zahl nennen, das ist der Prozess, den wir durchlaufen müssen, um einen vernünftigen Kostenvoranschlag zu finden“ und die Arbeit zu erzwingen, als eine oberflächliche, ungenaue Antwort zu geben, die garantiert zu einem oder mehreren der folgenden Ergebnisse führt (fast).

• Ungenauigkeiten bei den Kosten, weil die angegebene Hardware zu groß oder zu klein war
• „Go live“, das am ersten Tag wegen unzureichender Hardware scheitert
• „Die Inbetriebnahme verzögert sich, weil die Stresstests in der Woche vor dem Zieldatum gezeigt haben, dass eine Menge neuer Hardware benötigt wird.
• Verzögerungen und Kosten, weil sich die Anforderungen ändern, sobald der Produktmanager sieht, was die Entwickler implementiert haben (ich hätte nicht gedacht, dass es so aussehen würde)… und der PM verlangt Änderungen, die mehr Hardware erfordern
• Geschwüre in der Operationsabteilung
• Geschwüre für den Projektsponsor

Wenn Sie ein striktes Wasserfallmodell verfolgen, werde ich mich ein wenig beugen. Aber wenn Sie nach einem strengen Wasserfallmodell vorgehen, können Sie auch alle oben genannten Fragen beantworten und eine vernünftige Schätzung im Voraus erhalten.

Andere Ressourcen

Grant Ingersoll hat auch zu diesem Thema gebloggt, siehe: http://www.lucidimagination.com/blog/2011/09/14/estimating-memory-and-storage-for-lucenesolr/

Solr Wiki „Powered By“, siehe: http://wiki.apache.org/solr/PublicServers. Einige der Personen, die Informationen zu dieser Seite hinzugefügt haben, waren so freundlich, Hardware- und Durchsatzzahlen anzugeben.