Ist Sharding für kleine Sammlungen effektiv?

11

Es sieht so aus, als ob Datenbank-Sharding großartig ist, wenn ich riesige Sammlungen habe. Was ist, wenn ich viele ziemlich große Sammlungen habe? Nehmen wir an, dass für 1 Sammlung von 100 000 000 Dokumenten (nicht sehr große Kommentare) das Sharding effektiv ist. Ist es auch für 10 000 Sammlungen mit jeweils 10 000 Dokumenten wirksam?

(Ich denke, diese Frage gilt weiterhin für tabellenorientierte Datenbanken, wenn Sie Sammlungen durch Tabellen und Dokumente durch Zeilen ersetzen. Wenn möglich, möchte ich die theoretische Antwort sowie die Antwort im spezifischen MongoDB-Szenario kennen, sofern diese von der theoretischen abweicht Antworten.)

mongodb

— João Pinto Jerónimo
quelle

5

Ist es auch für 10 000 Sammlungen mit jeweils 10 000 Dokumenten wirksam?

Die meisten Menschen haben das Problem der "einzelnen großen Sammlung", und daher ist das Sharding eindeutig nützlich, um die Kopfschmerzen beim Ausgleich dieser Daten zu verringern.

Wenn Sie jedoch 10 000 kleine Sammlungen haben, werden Ihre Kopfschmerzen wahrscheinlich nicht "die Daten ausgleichen". Bei so vielen kleinen Sammlungen besteht Ihr Problem wahrscheinlich darin, diese Sammlungen zu verfolgen. Abhängig von Ihrer Dokumentgröße können Sie möglicherweise nicht einmal die Untergrenze für das tatsächliche Auftreten von Sharding überschreiten.

Für die wirklich kleinen Sammlungen können Sie den wenig bekannten Befehl movePrimary verwenden , um den Speicherort Ihrer Daten zu verwalten.

Die andere Sichtweise ist natürlich, warum Sie 10.000 Sammlungen haben. Eine Sammlung benötigt keine homogenen Objekte und bei 10.000 Sammlungen müssen die meisten davon generiert werden. Es ist durchaus möglich, verschiedene "Datentypen" in derselben Sammlung zu speichern, die Anzahl der Sammlungen zu verringern und den Typ dann als Teil des Shard-Schlüssels einzuschließen.

— Gates VP
quelle

Danke, ich habe genau versucht zu wissen, ob das Beste, was ich tun kann, darin besteht, diese Tonnen von Sammlungen loszuwerden und eine große zu machen. Ich hatte schon Tonnen von Sammlungen, weil ich eine verbreitete Überzeugung hörte: "Riesige Sammlungen sind schlecht für Sie, weil die Indizes nicht in den Arbeitsspeicher passen und es sehr langsam sein wird, sie abzufragen und zu aktualisieren." Aber ich denke, Sharding wurde erstellt, um dieses Problem zu lösen ... Danke !!

— João Pinto Jerónimo

Ehrlich gesagt finde ich, dass man die Indizes auch oft "betrügen" kann. Wenn Sie zwei Sammlungen haben foound barmit der gleichen Datenstruktur, können Sie sie in die fusionieren bazSammlung und die außer Kraft setzen _ids(in Code): { _id: "foo123" }, { _id: "bar123" }. Sie haben einen größeren Index, aber nur einen Index, der den Typ enthält. Keine Voraussetzung, nur "Denkanstoß".

— Gates VP

4

MongoDB-Sharding funktioniert, indem eine Sammlung in kleinere "Blöcke" aufgeteilt und gleichmäßig auf mehrere Maschinen verteilt wird. Die Standardblockgröße, die im Allgemeinen am effizientesten ist, beträgt 200 MB. Wenn eine Sammlung also nicht viel größer als 200 MB wird, wird sie nicht in Blöcke aufgeteilt und kann daher nicht gesplittert werden. Daher gibt es keine Vorteile.

Im Allgemeinen ist das Sharding von Daten über mehrere Computer eine sehr effektive Methode zum Skalieren von Lese-, Schreib- und Abfragen. Sie profitieren von mehreren CPUs, Festplatten und Speicher, die parallel zum Lesen, Schreiben und Verarbeiten von Daten arbeiten. Das Skalieren des Speichers ist besonders wichtig für MongoDB, wo eine hohe Leistung sehr empfindlich auf Datenanpassungen im Speicher reagiert.

— Chris Fulstow
quelle

Zu Ihrer Information: Die Standardblockgröße beträgt 64 MB ab 1,8.

— Gates VP