Ich habe kürzlich RavenDB gelernt und würde es gerne anwenden.
Ich habe mich gefragt, welchen Rat oder welche Vorschläge die Leute hatten, um das System skalierbar zu machen, insbesondere um die Daten auf mehrere Server zu verteilen, aber das auf einem einzelnen Server starten und nur nach Bedarf wachsen kann.
Ist es ratsam oder sogar möglich, mehrere Datenbanken in einer einzigen Instanz zu erstellen und Sharing über sie hinweg zu implementieren? Um es dann zu skalieren, würde es einfach darum gehen, diese Datenbanken über die Maschinen zu verteilen?
Mein erster Eindruck ist, dass dieser Ansatz funktionieren würde, aber ich würde gerne die Meinungen und Erfahrungen anderer hören.
Update 1:
Ich habe mehr über dieses Thema nachgedacht. Ich denke, mein Problem mit dem Ansatz "Sortiere es später" ist, dass es mir schwer fällt, Daten gleichmäßig auf Server in dieser Situation zu verteilen. Ich werde keinen String-Key haben, auf den ich zugreifen kann (A-E, F-M ..), es wird mit Zahlen gemacht.
Damit bleiben zwei Optionen übrig, die ich sehen kann. Entweder brichst du es an Grenzen, also ist 1-50000 auf Shard 1, 50001-100000 ist auf Shard 2, aber dann mit einer Site, die altert, sagen wir mal, deine ursprünglichen Shards werden viel weniger Arbeit machen. Alternativ leidet eine Strategie, bei der die Shards round geklappt und die Shard-ID in den Schlüssel eingefügt werden, wenn Sie ein Dokument in einen neuen Shard verschieben müssen, würde den Schlüssel ändern und URLs, die den Schlüssel verwendet haben, abbrechen.
Also meine neue Idee, und wieder mache ich es für einen Kommentar draußen, wäre es, vom ersten Tag an ein Eimersystem zu schaffen. Das funktioniert so, als würde man die Shard-ID in den Schlüssel füllen, aber man beginnt mit einer großen Zahl, sagen wir 1000, die man gleichmäßig verteilt. Wenn es dann Zeit ist, die Ladung in einen Shard zu teilen, können Sie Buckets 501-1000 auf den neuen Server verschieben und Ihre Shard-Logik schreiben, dass 1-500 zu Shard 1 geht und 501-1000 zu Shard 2. Dann, wenn a Dritter Server kommt online Sie wählen eine andere Palette von Eimern und passen sie an.
Für mein Auge gibt es Ihnen die Möglichkeit, sich in so viele Scherben zu teilen, wie Sie ursprünglich Eimer erstellt haben, um die Ladung sowohl hinsichtlich Menge als auch Alter gleichmäßig zu verteilen. Ohne die Schlüssel ändern zu müssen.
Gedanken?
Ich denke, eine gute Lösung ist die Verwendung virtueller Shards. Sie können mit einem Server beginnen und alle virtuellen Shards auf einen einzelnen Server verweisen. Verwenden Sie das Modul für die inkrementelle ID, um die Zeilen gleichmäßig auf die virtuellen Shards zu verteilen. Mit Amazon RDS haben Sie die Möglichkeit, einen Slave zu einem Master zu machen. Bevor Sie die Sharding-Konfiguration ändern (mehr virtuelle Shards auf den neuen Server richten), sollten Sie einen Slave zu einem Master machen, dann Ihre Konfigurationsdatei aktualisieren und dann löschen Alle Datensätze auf dem neuen Master, die Modulu verwenden, entsprechen nicht dem Shard-Bereich, den Sie für die neue Instanz verwenden.
Sie müssen auch Zeilen vom ursprünglichen Server löschen, aber alle neuen Daten mit IDs, die auf den neuen virtuellen Shard-Bereichen basieren, verweisen auf den neuen Server. Sie müssen also die Daten nicht verschieben, sondern die Vorteile des Amazon RDS-Servers nutzen.
Sie können dann das Replikat vom ursprünglichen Server erstellen. Sie erstellen eine eindeutige ID als: Shard ID + Table Type ID + Inkrementelle Nummer. Wenn Sie also die Datenbank abfragen, wissen Sie, zu welchem Shard die Daten geholt werden sollen.
Ich weiß nicht, wie es mit RavenDB gemacht werden kann, aber es kann ziemlich gut mit Amazon RDS funktionieren, weil Amazon Ihnen bereits Replikations- und Server-Promotion-Funktionen bietet.
Ich stimme zu, dass sie eine Lösung sein sollten, die von Anfang an eine nahtlose Soziabilität bietet und den Entwicklern nicht die Möglichkeit gibt, Probleme zu lösen, wenn diese auftreten. Außerdem habe ich herausgefunden, dass viele NoSQL-Lösungen, die Daten gleichmäßig über Shards verteilen, innerhalb eines Clusters mit geringer Latenz arbeiten müssen. Das muss man berücksichtigen. Ich habe versucht, Couchbase mit zwei verschiedenen EC2-Rechnern zu verwenden (nicht in einem dedizierten Amazon-Cluster) und der Datenausgleich war sehr, sehr langsam. Das trägt auch zu den Gesamtkosten bei.
Ich möchte auch hinzufügen, was pinterest getan hat, um ihre Skalierbarkeitsprobleme zu lösen, indem ich 4096 virtuelle Shards verwende.
Sie sollten auch mit vielen NoSQL-Datenbanken nach Paging-Problemen suchen. Mit diesem Ansatz können Sie Daten recht einfach puffern, aber möglicherweise nicht auf die effizienteste Weise, da Sie möglicherweise mehrere Datenbanken abfragen müssen. Ein anderes Problem ist das Ändern des Schemas. Pinterest löste das, indem er alle Daten in einem JSON Blob in MySQL ablegte. Wenn Sie eine neue Spalte hinzufügen möchten, erstellen Sie eine neue Tabelle mit der neuen Spalte Daten + Schlüssel und können Index für diese Spalte verwenden. Wenn Sie die Daten beispielsweise per E-Mail abfragen müssen, können Sie eine weitere Tabelle mit den E-Mails + ID erstellen und einen Index für die E-Mail-Spalte erstellen. Zähler sind ein anderes Problem, ich meine Atomzähler. Es ist also besser, diese Zähler aus dem JSON herauszunehmen und sie in eine Spalte zu setzen, damit Sie den Zählerwert erhöhen können.
Es gibt großartige Lösungen, aber am Ende des Tages finden Sie heraus, dass sie sehr teuer sein können. Ich zog es vor, meine Zeit damit zu verbringen, meine eigene Lösung zu entwickeln und mir später die Kopfschmerzen zu ersparen. Wenn Sie sich für den anderen Weg entscheiden, warten viele Unternehmen darauf, dass Sie in Schwierigkeiten geraten und um eine Menge Geld bitten, um Ihre Probleme zu lösen. Denn in dem Moment, in dem Sie sie brauchen, wissen sie, dass Sie alles bezahlen werden, damit Ihr Projekt wieder funktioniert. Das ist aus meiner eigenen Erfahrung, deshalb breche ich mir den Kopf, um mit meinem Ansatz, der auch viel billiger ist, meine eigene Sharding-Lösung zu bauen.
Eine weitere Option ist die Verwendung von Middleware-Lösungen für MySQL wie ScaleBase oder DBshards. Sie können also weiterhin mit MySQL arbeiten, aber zu dem Zeitpunkt, an dem Sie skalieren müssen, haben sie eine bewährte Lösung. Und die Kosten könnten viel niedriger sein als die Alternative.
Noch ein Tipp: Wenn Sie Ihre Konfiguration für Shards erstellen, fügen Sie ein write_lock-Attribut hinzu, das false oder true akzeptiert. Wenn es falsch ist, werden Daten nicht in diesen Shard geschrieben. Wenn Sie also die Liste der Shards für einen bestimmten Tabellentyp (dh Benutzer) abrufen, wird es nur für die anderen Shards desselben Typs geschrieben. Dies ist auch gut für die Sicherung. Sie können also einen benutzerfreundlichen Fehler für Besucher anzeigen, wenn Sie alle Shards sperren möchten, wenn Sie alle Daten sichern, um Snapshots mit Momentaufnahmen aller Shards zu erhalten. Obwohl ich denke, dass Sie eine globale Anforderung für das Snapshot aller Datenbanken mit Amazon RDS senden können und Point-in-Time-Sicherung verwenden können.
Die Sache ist, dass die meisten Unternehmen keine Zeit damit verbringen werden, mit einer DIY-Sharding-Lösung zu arbeiten, sie werden es vorziehen, für ScaleBase zu bezahlen. Diese Lösung kommt von einzelnen Entwicklern, die es sich von Anfang an leisten können, für eine skalierbare Lösung zu bezahlen, aber sicher sein wollen, dass sie eine Lösung haben, wenn sie den Punkt erreichen, an dem sie es brauchen. Schauen Sie sich einfach die Preise an und Sie werden feststellen, dass es Sie viel kosten wird. Ich teile gerne meinen Code mit Ihnen, sobald ich fertig bin. Sie gehen mit dem besten Weg meiner Meinung nach, es hängt alles von Ihrer Anwendungslogik ab. Ich modelliere meine Datenbank als einfach, keine Joins, keine komplizierten Aggregationsabfragen - das löst viele meiner Probleme.In Zukunft können Sie Map Reduce verwenden, um diese großen Datenabfragen zu lösen.
Tags und Links ravendb sharding scalability