Zusammenfassung

  • Bei Atlas Core mit getrennten Search Nodes löscht eine Pause deren Daten. Beim Fortsetzen entstehen neue Knoten und Indizes; während des Aufbaus sind $search und $vectorSearch nicht verfügbar.
  • Die Suchmetriken aus der Zeit vor der Pause bleiben nicht erhalten. Ein brauchbarer Vorher-nachher-Vergleich braucht eigene Aufzeichnungen des Kunden.
  • Im pausierten Zustand fällt nur Speicherentgelt an. Die Wirtschaftlichkeit hängt außerdem davon ab, wie oft und mit welchem Vorlauf die Suche wieder einsatzbereit sein muss.

Die neue Kurve hat ein ausgezeichnetes Gedächtnis für heute

Eine frische Leistungskurve sieht ordentlich aus. Sie beginnt sauber, hat keine alten Ausreißer und erzählt nichts von der vergangenen Woche. Nach einer Pause von MongoDB Atlas kann genau darin das Problem liegen. Die Dokumentation der Suchmetriken erklärt: Die Metriken vor der Pause werden nicht aufbewahrt. Nach dem Fortsetzen stehen nur die Werte der neuen Suchknoten zur Verfügung.

Wer mit der Pause Geld sparen wollte und anschließend ihre Wirkung beurteilen möchte, verliert damit einen Teil des eingebauten Vergleichs. Das Werkzeug, das nach der Ersparnis gefragt wird, hat den Zustand davor vergessen. Eigene Messungen werden deshalb schon vor dem Ausschalten wertvoll.

Der Grund ist ein sehr konkreter Lebenszyklus. In Atlas Core mit separat bereitgestellten Search Nodes löscht die Pause die Daten dieser Knoten. Beim Fortsetzen erzeugt Atlas neue Suchknoten und baut die Indizes wieder auf. Bis dieser Aufbau abgeschlossen ist, stehen die Abfragestufen $search und $vectorSearch nicht zur Verfügung. Atlas Infinite unterstützt diese Knoten in der öffentlichen Vorschau noch nicht; hier geht es um die Core-Konfiguration.

Eine Pause bewahrt also die vorbereitete Suchfähigkeit nicht einfach wie einen gedeckten Tisch unter einer Haube auf. Der Tisch wird später wieder gedeckt. MongoDB übernimmt diese Arbeit automatisch. Der Kunde muss den Zeitpunkt bestimmen, an dem er seine Gäste einlädt.

Der Einkauf zählt ausgeschaltete Stunden, der Vertrieb zählt Minuten

Als Entscheidungsszenario genügt eine Produktvorführung mit einem durchsuchbaren Katalog. Der Datenbankzugang funktioniert, die Anwendung startet, der Suchindex wird noch erstellt. Der technische Wiederanlauf hat begonnen; die Vorführung braucht bereits Ergebnisse. Wer nur das Wiederlaufen des Clusters abnimmt, prüft einen anderen Gegenstand als der Verkäufer mit seinem Termin.

Die Einsparung hat durchaus Substanz. Nach den Kostenregeln für Cluster berechnet Atlas während einer Pause ausschließlich Speicher. Auch der sonst in der Grundausstattung enthaltene Speicher kostet in diesem Zustand Geld. Für selten genutzte Entwicklungsumgebungen entsteht damit ein vernünftiger Spielraum, aktive Rechenleistung zeitweise einzusparen.

Schwieriger ist die Rückreise in den Betrieb. Jemand muss früher starten, den Aufbau kontrollieren und die nötigen Abfragen prüfen. Werden diese Aufgaben auf andere Kostenstellen verteilt, kann die Sparmaßnahme in der einen Abteilung glänzen und in der anderen zusätzliche Vorbereitungszeit erzeugen. Der Konzern zahlt beides. Seine Berichte können es trotzdem getrennt feiern und beklagen.

Die Abrechnung der Suchknoten erfolgt stündlich; auch ein angebrochener Nutzungszeitraum wird als volle Stunde berechnet. Knotenanzahl, Ausstattung und Datenverkehr zwischen Such- und Datenbankknoten beeinflussen die Kosten. Eine belastbare Rechnung legt deshalb den tatsächlichen Rechnungsbetrag neben die Zeit bis zur nutzbaren Suche. Der dokumentierte Ressourcentarif liefert keinen neuen Abrechnungsbeginn, der automatisch mit der fachlichen Freigabe eines Suchergebnisses zusammenfällt.

Bei langen Ruhephasen kann der einmalige Anlauf gut in den Zeitplan passen. Bei vielen kurzen Unterbrechungen wird derselbe Anlauf zur wiederkehrenden Aufgabe. Die richtige Häufigkeit folgt aus der Nutzung. Ein stundenweise reservierter Teststand lässt sich anders betreiben als eine Umgebung, die auf Zuruf sofort vorführen soll.

Ein Indexwechsel hat einen Vorgänger; der Wiederanlauf nach der Pause nicht

Wer die Dokumentation nur nach dem Wort „Neuaufbau“ durchsucht, kann zwei Verfahren verwechseln. Bei einer gewöhnlichen Änderung der Indexdefinition baut MongoDB den neuen Index im Hintergrund, während der alte weiter Abfragen bedient. Die Indexverwaltung beschreibt außerdem, dass bei einer Änderung der Suchtopologie neue Knoten vorbereitet werden, bevor die alten verschwinden.

Das ist ein geordneter Schichtwechsel mit anwesender Vorgängerschicht. Nach der Pause sind die Daten der getrennten Suchknoten bereits entfernt. Die technische Ausgangslage ist damit eine andere. Ein Einkauf, der „Wartung ohne Unterbrechung“ aus einem Verfahren auf alle übrigen überträgt, kauft sich einen Zeitplan aus einem falschen Kapitel.

Die praktische Abnahme lässt sich genauer fassen. getSearchIndexes() gibt unter anderem den Status und queryable zurück. Dieses Feld sagt, ob der Index Abfragen annehmen kann. Danach folgt die fachliche Probe: Findet die Anwendung mit ihren tatsächlichen Suchbedingungen die erwarteten Einträge, und kommt die Antwort rechtzeitig?

Diese Probe sollte schon vor der Pause einmal aufgezeichnet werden. Datenmenge, Indexdefinition und Suchbedingungen gehören dazu. Nach dem Fortsetzen wiederholt man sie unter vergleichbaren Bedingungen oder vermerkt die Unterschiede. So entsteht eine gemeinsame Zeitachse für Betrieb, Produkt und Einkauf, auch wenn die Suchmetriken des Dienstes von vorn beginnen.

Es fehlen Kundenmessungen, die Wiederaufbauzeit, brauchbare Suchantworten und Rechnung zusammenführen; ein kurzer, verlässlicher Anlauf würde häufige Pausen attraktiver machen. Der dokumentierte Tausch ist trotzdem klar: weniger laufende Kapazität während der Ruhe, automatische Wiederherstellung der Suchfähigkeit danach. Eine Sparmaßnahme ist erst fertig bewertet, wenn die Suche ihren nächsten Termin eingehalten hat.