MongoDB ist zu klein geworden … was nun?

Question 1

Wenn Sie an einem Punkt sind, an dem die aktuelle Leistung zu langsam ist oder die Grenzen erreicht sind, haben Sie drei Möglichkeiten. Und diese gelten für jedes Problem.

Vertikal skalieren: Das bedeutet, erhöhen Sie die Leistung Ihres Rechners. Mehr CPU oder mehr RAM.
Horizontal skalieren: Das bedeutet, die Anzahl der Arbeiter zu erhöhen. Mehr Prozesse, mehr Threads, mehr Maschinen.
Design ändern: Mach es anders. Andere Software, andere Algorithmen, anderes Speichersystem, anderes was auch immer.

Da du 1) und 2) aus deinen Möglichkeiten ausgeschlossen hast, bleibt nur noch Lösung 3) übrig. Also los...

Answer

Wenn Sie an einem Punkt sind, an dem die aktuelle Leistung zu langsam ist oder die Grenzen erreicht sind, haben Sie drei Möglichkeiten. Und diese gelten für jedes Problem.

Vertikal skalieren: Das bedeutet, erhöhen Sie die Leistung Ihres Rechners. Mehr CPU oder mehr RAM.
Horizontal skalieren: Das bedeutet, die Anzahl der Arbeiter zu erhöhen. Mehr Prozesse, mehr Threads, mehr Maschinen.
Design ändern: Mach es anders. Andere Software, andere Algorithmen, anderes Speichersystem, anderes was auch immer.

Da du 1) und 2) aus deinen Möglichkeiten ausgeschlossen hast, bleibt nur noch Lösung 3) übrig. Also los...

Question 2

Wir haben dieselbe Frage im Mongo-Forum gestellt und der CTO von Mongo hat geantwortet, dass wir seine Präsentation zur Optimierung von Indizes noch einmal durchgehen sollten.

http://www.10gen.com/presentations/mongosf2011/schemascale

In dieser Präsentation erklärt Herr Horowitz ausdrücklich, dass Sharding/horizontale Skalierung in vielen Situationen übertrieben sein kann und dass Designansätze (einschließlich einiger eher nicht intuitiver Ansätze, die irgendwie spezifisch für Mongo sind) dazu führen können, dass ein bestimmter Server viel weiter skaliert werden kann.

Dabei wurden einige interessante Konzepte vorgestellt, darunter die Verwendung clientseitiger Logik zur Optimierung der Verwendung der Datenbank auf verschiedene „nicht normalisierte“ Arten. Die Präsentation enthält einen klaren Subtext, der besagt: „Wenn Sie einfach nach Vorschrift bauen, können Sie leicht auf unerwünschte Probleme im Zusammenhang mit der Skalierung stoßen.“ Beispielsweise stellt Herr Horowitz (der CTO von 10Gen, dem Hersteller von MongoDB) ein „hybrides“ Design vor, bei dem Sie anstelle eines Dokuments pro „Datensatz“ vielleicht 100 „Datensätze“ in ein Dokument einfügen, was zu einer Art „Bucket“-Ansatz führt. Dies wird ausdrücklich getan, um den Index-Footprint zu reduzieren. Dies ist etwas, das auf dem Client codiert wird und kein „Feature“ von MongoDB ist. Dieser hybride Ansatz könnte für uns funktionieren und uns eine 4- oder 8-fache Verbesserung der Indexgröße bringen.

Er diskutiert auch „rechts balancierte“ B-Bäume, bei denen es im Grunde darum geht, das Indexdesign so zu optimieren, dass die meisten Abfragen nur auf den „rechten Teil“ des Index zugreifen (im Gegensatz zum wahlfreien Zugriff auf den gesamten Index, der für eine gute Leistung erfordert, dass der gesamte Index in den RAM passt). Dieser Ansatz wird uns nicht helfen, da wir den gesamten Index abfragen müssen.

Wir werden diese Konzepte im Rahmen einer Überprüfung unseres Systems verwenden.

(Interessant ist, dass von allen Orten, an denen ich diese Frage gepostet habe, die einzige Person mit einer konstruktiven Antwort der CTO von MongoDB selbst ist.)

AKTUALISIERUNG (2017)

Letztendlich haben wir festgestellt, dass Mongodb für eine Produktionsumgebung nicht geeignet ist. Alle paar Monate wird die gesamte Datenbank gelöscht und alle Daten gehen verloren. (Es ist keine primäre Datenquelle, daher können wir mit dem Problem leben, wenn auch nicht glücklich.)

Wir haben jetzt ein Projekt zur Migration zum Elasticsearch-Stack abgeschlossen und führen es jetzt in die Produktion ein. (Wir verwenden Elasticsearch seit Jahren erfolgreich.) Elasticsearch-Daten sind nicht so langlebig wie beispielsweise Microsoft SQL Server (bei uns sind Elasticsearch-Cluster mit nicht wiederherstellbarem Datenverlust ausgefallen), aber Elasticsearch ist mindestens 10x (erfahrungsgemäß mehr als 100x) zuverlässiger als Mongodb. (Elasticsearch gibt intelligenterweise nicht vor, Windows als Produktionsplattform zu unterstützen, eine der großen Sünden von Mongodb.)

Wir gehen davon aus, dass wir unsere gesamte Mongodb-Umgebung im Laufe der kommenden Wochen bereinigt haben werden.

Weiter!

AKTUALISIERUNG (2018-2019)

Der Elasticsearch-Stack hat geliefert. Wir haben festgestellt, dass er sehr zuverlässig und skalierbar ist, und haben es nie bereut. Mongo war damals ein toller Ansatz, aber jetzt ist es seit Jahren nicht mehr da, und das ist gut so. Wir haben zwei Elastic-Cluster betrieben, einen für Protokolldaten (der unseren Mongo-Server ersetzt hat) und einen zweiten für echte Anwendungsdaten. Jeder Cluster hat 1-2 TB Daten. Es dauerte eine Weile, bis wir die Daten endlich hatten.vielder Architekturarbeit (insbesondere auf der Anwendungsseite), um sowohl skalierbar als auch leistungsfähig zu sein, aber sie liefert.

Answer

Wir haben dieselbe Frage im Mongo-Forum gestellt und der CTO von Mongo hat geantwortet, dass wir seine Präsentation zur Optimierung von Indizes noch einmal durchgehen sollten.

http://www.10gen.com/presentations/mongosf2011/schemascale

In dieser Präsentation erklärt Herr Horowitz ausdrücklich, dass Sharding/horizontale Skalierung in vielen Situationen übertrieben sein kann und dass Designansätze (einschließlich einiger eher nicht intuitiver Ansätze, die irgendwie spezifisch für Mongo sind) dazu führen können, dass ein bestimmter Server viel weiter skaliert werden kann.

Dabei wurden einige interessante Konzepte vorgestellt, darunter die Verwendung clientseitiger Logik zur Optimierung der Verwendung der Datenbank auf verschiedene „nicht normalisierte“ Arten. Die Präsentation enthält einen klaren Subtext, der besagt: „Wenn Sie einfach nach Vorschrift bauen, können Sie leicht auf unerwünschte Probleme im Zusammenhang mit der Skalierung stoßen.“ Beispielsweise stellt Herr Horowitz (der CTO von 10Gen, dem Hersteller von MongoDB) ein „hybrides“ Design vor, bei dem Sie anstelle eines Dokuments pro „Datensatz“ vielleicht 100 „Datensätze“ in ein Dokument einfügen, was zu einer Art „Bucket“-Ansatz führt. Dies wird ausdrücklich getan, um den Index-Footprint zu reduzieren. Dies ist etwas, das auf dem Client codiert wird und kein „Feature“ von MongoDB ist. Dieser hybride Ansatz könnte für uns funktionieren und uns eine 4- oder 8-fache Verbesserung der Indexgröße bringen.

Er diskutiert auch „rechts balancierte“ B-Bäume, bei denen es im Grunde darum geht, das Indexdesign so zu optimieren, dass die meisten Abfragen nur auf den „rechten Teil“ des Index zugreifen (im Gegensatz zum wahlfreien Zugriff auf den gesamten Index, der für eine gute Leistung erfordert, dass der gesamte Index in den RAM passt). Dieser Ansatz wird uns nicht helfen, da wir den gesamten Index abfragen müssen.

Wir werden diese Konzepte im Rahmen einer Überprüfung unseres Systems verwenden.

(Interessant ist, dass von allen Orten, an denen ich diese Frage gepostet habe, die einzige Person mit einer konstruktiven Antwort der CTO von MongoDB selbst ist.)

AKTUALISIERUNG (2017)

Letztendlich haben wir festgestellt, dass Mongodb für eine Produktionsumgebung nicht geeignet ist. Alle paar Monate wird die gesamte Datenbank gelöscht und alle Daten gehen verloren. (Es ist keine primäre Datenquelle, daher können wir mit dem Problem leben, wenn auch nicht glücklich.)

Wir haben jetzt ein Projekt zur Migration zum Elasticsearch-Stack abgeschlossen und führen es jetzt in die Produktion ein. (Wir verwenden Elasticsearch seit Jahren erfolgreich.) Elasticsearch-Daten sind nicht so langlebig wie beispielsweise Microsoft SQL Server (bei uns sind Elasticsearch-Cluster mit nicht wiederherstellbarem Datenverlust ausgefallen), aber Elasticsearch ist mindestens 10x (erfahrungsgemäß mehr als 100x) zuverlässiger als Mongodb. (Elasticsearch gibt intelligenterweise nicht vor, Windows als Produktionsplattform zu unterstützen, eine der großen Sünden von Mongodb.)

Wir gehen davon aus, dass wir unsere gesamte Mongodb-Umgebung im Laufe der kommenden Wochen bereinigt haben werden.

Weiter!

AKTUALISIERUNG (2018-2019)

Der Elasticsearch-Stack hat geliefert. Wir haben festgestellt, dass er sehr zuverlässig und skalierbar ist, und haben es nie bereut. Mongo war damals ein toller Ansatz, aber jetzt ist es seit Jahren nicht mehr da, und das ist gut so. Wir haben zwei Elastic-Cluster betrieben, einen für Protokolldaten (der unseren Mongo-Server ersetzt hat) und einen zweiten für echte Anwendungsdaten. Jeder Cluster hat 1-2 TB Daten. Es dauerte eine Weile, bis wir die Daten endlich hatten.vielder Architekturarbeit (insbesondere auf der Anwendungsseite), um sowohl skalierbar als auch leistungsfähig zu sein, aber sie liefert.

Question 3

Die Antworten auf Ihr „Skalierungsproblem“ gefallen Ihnen vielleicht nicht, weil Sie eigentlich kein Skalierungsproblem haben, sondern ein Design- und Implementierungsproblem. Sie indizieren nicht effizient.

Im Ernst, wenn Sie der Meinung sind, dass Sie unbedingt Indizes dieser Größe behalten müssen, werden Sie bei jedem Datenbankprodukt, das Sie kaufen, das gleiche Problem haben, nämlich abscheulich große Indizes im RAM zu behalten. Sie müssten einen Server mit hoher Kapazität kaufen (DL380 G7 kann das, und es ist ein Standardserver mittlerer Preisklasse; nichts Exotisches), um diese Indizes zu speichern.

Eine Suche nach „MongoDB-Optimierungsindizes“ liefert als Hilfestellung mehrere nützliche Links:

http://www.mongodb.org/display/DOCS/Optimization

http://www.10gen.com/events/indexingmatters

http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/

http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer

Sie reagieren vielleicht defensiv, weil Sie Ihre Recherchen durchgeführt haben, aber diejenigen von uns, die MongoDB in der Produktion verwenden, wissen, dass Ihnen viele Punkte entgehen.

Darüber hinaus schreit der Kommentar „Unterm Strich: MongoDB ist FOSS, aber wir müssen $$$$$$$ für Hardware ausgeben, um es auszuführen? Wir sollten lieber kommerzielle Software kaufen!“ vor Ignoranz und Arroganz.

Answer

Die Antworten auf Ihr „Skalierungsproblem“ gefallen Ihnen vielleicht nicht, weil Sie eigentlich kein Skalierungsproblem haben, sondern ein Design- und Implementierungsproblem. Sie indizieren nicht effizient.

Im Ernst, wenn Sie der Meinung sind, dass Sie unbedingt Indizes dieser Größe behalten müssen, werden Sie bei jedem Datenbankprodukt, das Sie kaufen, das gleiche Problem haben, nämlich abscheulich große Indizes im RAM zu behalten. Sie müssten einen Server mit hoher Kapazität kaufen (DL380 G7 kann das, und es ist ein Standardserver mittlerer Preisklasse; nichts Exotisches), um diese Indizes zu speichern.

Eine Suche nach „MongoDB-Optimierungsindizes“ liefert als Hilfestellung mehrere nützliche Links:

http://www.mongodb.org/display/DOCS/Optimization

http://www.10gen.com/events/indexingmatters

http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/

http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer

Sie reagieren vielleicht defensiv, weil Sie Ihre Recherchen durchgeführt haben, aber diejenigen von uns, die MongoDB in der Produktion verwenden, wissen, dass Ihnen viele Punkte entgehen.

Darüber hinaus schreit der Kommentar „Unterm Strich: MongoDB ist FOSS, aber wir müssen $$$$$$$ für Hardware ausgeben, um es auszuführen? Wir sollten lieber kommerzielle Software kaufen!“ vor Ignoranz und Arroganz.

Question 4

Warum würden Sie sagen: „SQL Server Express kann VIEL mehr Daten auf VIEL weniger Hardware verarbeiten als Mongo (SQL Server entspricht nicht unseren architektonischen Wünschen, sonst würden wir es verwenden!)“. Wenn Sie Ihre Datenbankarchitektur ändern müssen (da Ihre andere Datenbank nicht wie erforderlich skaliert werden kann und Sie SQL Server verwenden würden, besteht die Antwort für mich darin, Ihr Datenbankdesign so zu korrigieren, dass es mit SQL Server funktioniert. Das Einzige, was mir einfällt, was nicht „reparierbar“ ist, ist, wenn Sie wirklich eine ACID-freie Datenbank wünschen (was mir seltsam erscheinen würde, wenn Debug- und Transaktionsprotokolleinfügungen gelöscht werden können)

Answer

Warum würden Sie sagen: „SQL Server Express kann VIEL mehr Daten auf VIEL weniger Hardware verarbeiten als Mongo (SQL Server entspricht nicht unseren architektonischen Wünschen, sonst würden wir es verwenden!)“. Wenn Sie Ihre Datenbankarchitektur ändern müssen (da Ihre andere Datenbank nicht wie erforderlich skaliert werden kann und Sie SQL Server verwenden würden, besteht die Antwort für mich darin, Ihr Datenbankdesign so zu korrigieren, dass es mit SQL Server funktioniert. Das Einzige, was mir einfällt, was nicht „reparierbar“ ist, ist, wenn Sie wirklich eine ACID-freie Datenbank wünschen (was mir seltsam erscheinen würde, wenn Debug- und Transaktionsprotokolleinfügungen gelöscht werden können)

MongoDB ist zu klein geworden … was nun?

Antwort1

Antwort2

Antwort3

Antwort4

verwandte Informationen