2013-07-23 10 views
6

Im Moment führen wir ein MongoDB Replicaset mit 2 Servern + 1 Arbiter.Wann starten Sie MongoDB sharding

Und wir speichern etwa 150 GB Daten in den Datenbanken auf dem Replicaset.

Im Moment denken wir darüber nach, wann wir mit dem Sharding anfangen sollen. Weil wir uns fragen, ob es einen Punkt gibt, wo Sie nicht mehr anfangen können, zu schärfen.

Es ist offensichtlich, dass wir sharding beginnen müssten, bevor wir nicht mehr genügend Speicherplatz auf der Festplatte haben, unsere CPU überlastet ist oder die Gesamtleistung wegen zu wenig RAM sinkt.

Jemand sagte mir auch, dass es eine Grenze von 256 GB Datengröße gibt, nach der Sie nicht mehr sharding beginnen können. Ich lese auch die offizielle Dokumentation http://docs.mongodb.org/manual/sharding/ und "MongoDB die definitive Anleitung", das konnte ich nicht beweisen.

Aus Ihrer Erfahrung gibt es eine Grenze, wo Sie mit Sharding begonnen haben sollten?

Antwort

6

Ich würde Sharding beginnen, wenn Sie etwa 60-70% Ressourcenauslastung erreichen. Dies könnte sowohl Festplattenspeicher als auch RAM sein. Das Limit von 256 GB ist tatsächlich da, es ist dokumentiert unter http://docs.mongodb.org/manual/reference/limits/#Sharding%20Existing%20Collection%20Data%20Size

+0

War das nicht behoben, da es eher ein "Bug" war? Ich erinnere mich daran, gelesen zu haben, dass es behoben wurde ': /' – Sammaye

+0

das wäre interessant;), und wenn ich das Handbuch richtig hatte, sobald die Sammlung geteilt wird, kann es die 256 GB pro Shard richtig überschreiten? – Dukeatcoding

+0

@Dukeatcoding Yeah keine Grenze für die Größe einer sharded Sammlung (pro Shard auch) es ist nur vor-sharded, MongoDB hat ein Problem über 256GB beim Erstellen der Shard, kann mich nicht genau erinnern, was – Sammaye

6

Ich habe festgestellt, dass das Limit auf Lese-/Schreibzugriff basiert; afterall sharding geht es um die Erhöhung der Kapazität, vor allem schreibt, während Replikat-Sets mehr mit Reads beschäftigt ist. Die Verwendung separater Server (Knoten) für Datenbereiche (Shard-Schlüssel) kann jedoch auch Lesevorgänge unterstützen, so dass es für beide eine Auswirkung hat.

Zum Beispiel könnten Sie nur 40% Ihres aktuellen Serverspeichers mit Ihrem aktuellen Arbeitssatz verwenden, aber aufgrund der Menge der Schreibvorgänge, die an diesen einzelnen Server gesendet werden, könnten Geschwindigkeitsprobleme aufgrund von IO auftreten. Zu diesem Zeitpunkt würden Sie das Sharding berücksichtigen.

Also wirklich würde ich persönlich sagen, und diese Frage ist stark meinungsbasiert, dass Sie shard sollten, wenn Sie das Gefühl haben, dass Sie mehr Kapazität für Operationen als kosteneffektiv für ein einzelnes Replikat benötigen.

Ich habe von einzelnen Replik Setups gewusst, die normalerweise einen ganzen Cluster aufnehmen können, aber es hängt davon ab, wie groß Ihr Budget ist. Wenn ein Computer größer wird, wird er teurer.

+0

Sie vielleicht richtig mit der Leistung. Da wir einige hundert Schreibvorgänge pro Sekunde haben, wird die Sperrzeit höher und höher, dies sollte sich auch durch das Sharding verbessern, nicht wahr? – Dukeatcoding

+0

@Dukeatcoding 100 wties pro Sekunde schafft Sperrprobleme? Hmmm meine Knoten können bis zu 1 Million Operationen pro Sekunde bewältigen ...Jede – Sammaye

+0

@Dukeatcoding Sie haben hier möglicherweise ein Optimierungsproblem, es wird normalerweise empfohlen, Ihre Datenbank zu optimieren, bevor Sie sich entschließen, es zu zerlegen – Sammaye