Es gibt theoretische Grenzen, wie ich weiter unten zeigen werde, aber selbst die untere Grenze ist hübsch hoch. Die Grenzen richtig zu berechnen ist nicht einfach, aber die Größenordnung sollte ausreichen.
mmapv1
Das tatsächliche Limit hängt von einigen Dingen ab, wie der Länge der Shard-Namen und dergleichen (das summiert sich, wenn Sie ein paar Hunderttausend davon haben), aber hier ist eine grobe Berechnung mit realen Daten.
Jeder Shard benötigt etwas Platz in der Konfigurationsdatenbank, die wie jede andere Datenbank auf 32 TB auf einem einzelnen Computer oder in einem Replikatsatz begrenzt ist. Auf den von mir administrierten Servern die durchschnittliche Größe eines Eintrags in config.shards ist 112 Bytes. Darüber hinaus benötigt jeder Chunk etwa 250 Bytes an Metadateninformationen. Gehen wir davon aus, dass die optimalen Chunk-Größen bei etwa 64 MB liegen.
Wir können maximal 500.000 Chunks pro Server haben. 500.000 * 250 Byte entsprechen 125 MB für die Chunk-Informationen pro Shard. Pro Shard haben wir also 125,000112 MB pro Shard, wenn wir alles ausschöpfen. Das Teilen von 32 TB durch diesen Wert zeigt uns, dass wir maximal etwas weniger als 256.000 Shards in einem Cluster haben können.
Jeder Shard wiederum kann Daten im Wert von 32 TB speichern. 256.000 * 32 TB sind 8,19200 Exabyte oder 8.192.000 Terabyte. Das wäre die Grenze für unser Beispiel.
Nehmen wir an, es sind 8 Exabyte. Ab sofort lässt sich das leicht mit „Genug für alle praktischen Zwecke“ übersetzen. Um Ihnen einen Eindruck zu vermitteln:Alle Daten der Library of Congress (in Bezug auf die Sammlungsgröße wohl eine der größten Bibliotheken der Welt) enthalten eine geschätzte Datengröße von etwa 20 TB, einschließlich Audio-, Video- und digitaler Materialien. Sie könnten das etwa 400.000 Mal in unseren theoretischen MongoDB-Cluster einfügen. Beachten Sie, dass dies die untere Grenze der maximalen Größe ist, wobei konservative Werte verwendet werden.
WiredTiger
Nun zum guten Teil:Die WiredTiger-Speicher-Engine hat diese Einschränkung nicht:Die Datenbankgröße ist nicht begrenzt (da es keine Begrenzung gibt, wie viele Datendateien verwendet werden können), sodass wir eine unbegrenzte Anzahl von Shards haben können. Selbst wenn diese Shards auf mmapv1 und nur unsere Konfigurationsserver auf WT laufen, wird die Größe von a nahezu unbegrenzt – die Beschränkung auf 16,8 MB RAM auf einem 64-Bit-System könnte irgendwo Probleme verursachen und dazu führen, dass die Indizes des config.shard Sammlung, die auf die Festplatte ausgelagert werden soll, wodurch das System blockiert wird. Ich kann nur raten, da mein Taschenrechner sich weigert, mit Zahlen in diesem Bereich zu arbeiten (und ich bin zu faul, es von Hand zu tun), aber ich schätze die Grenze hier im zweistelligen Yottabyte-Bereich (und den Platz, der benötigt wird, um das irgendwo zu hosten). in der Größe von Texas).
Schlussfolgerung
Machen Sie sich keine Gedanken über die maximale Datengröße in einer Sharding-Umgebung. Egal was passiert, es ist bei weitem genug, selbst bei der konservativsten Herangehensweise. Verwenden Sie Sharding, und Sie sind fertig. Übrigens:Selbst 32 TB sind höllisch viele Daten:Die meisten Cluster, die ich kenne, enthalten weniger Daten und Shards, weil die IOPS- und RAM-Auslastung die Kapazität eines einzelnen Knotens übersteigt.
