MongoDB Survival Guide

Alle guten Startups sterben entweder schnell oder wachsen maßstabsgetreu. Wir werden ein solches Startup modellieren, bei dem es zuerst um Funktionen und dann um Leistung geht. Mit MongoDB, einer beliebten NoSQL-Datenspeicherlösung, verbessern wir die Leistung. MongoDB ist einfach zu starten und viele Probleme haben sofort einsatzbereite Lösungen. Wenn jedoch die Last zunimmt, kommt ein Rechen heraus, vor dem Sie noch niemand gewarnt hat ... bis heute!



Die Modellierung wird von Sergey Zagursky durchgeführt , der für die Backend-Infrastruktur im Allgemeinen und MongoDB im Besonderen in Joom verantwortlich ist . Es wurde auch auf der Serverseite der Entwicklung von MMORPG Skyforge gesehen. Wie Sergei sich selbst beschreibt, ist er „ein professioneller Kegelnehmer mit eigener Stirn und Rechen“. Unter dem Mikroskop ein Projekt, das eine Akkumulationsstrategie verwendet, um technische Schulden zu verwalten. In dieser Textversion des Berichts in HighLoad ++ werden wir in chronologischer Reihenfolge vom Auftreten des Problems zur Lösung mit MongoDB übergehen.

Erste Schwierigkeiten

Wir modellieren ein Startup, das Unebenheiten stopft. Die erste Lebensphase - Funktionen werden in unserem Startup gestartet und unerwartet kommen Benutzer. Unser kleiner MongoDB-Server hat eine Last, von der wir nie geträumt haben. Aber wir sind in der Cloud, wir sind ein Startup! Wir machen die einfachsten Dinge: Schauen Sie sich die Anforderungen an - oh, und hier haben wir die gesamte Korrektur für jeden Benutzer abgezogen, hier werden wir die Indizes erstellen, wir werden die Hardware dort hinzufügen und hier werden wir zwischenspeichern.
Alles - wir leben weiter!

Wenn Probleme mit so einfachen Mitteln gelöst werden können, sollten sie auf diese Weise gelöst werden.

Der zukünftige Weg eines erfolgreichen Starts ist jedoch eine langsame, schmerzhafte Verzögerung des horizontalen Skalierungsmoments. Ich werde versuchen, Ratschläge zu geben, wie man diese Zeit überlebt, zur Skalierung kommt und nicht auf den Rechen tritt.

Langsame Aufnahme

Dies ist eines der Probleme, auf die Sie möglicherweise stoßen. Was tun, wenn Sie sie treffen und die oben genannten Methoden nicht helfen? Antwort: Standardmäßig ist der Haltbarkeitsgarantiemodus in MongoDB . In drei Worten funktioniert es so:

• Wir kamen zur Hauptleitung und sagten: "Schreiben!".
  
• Primärreplik aufgezeichnet.
  
• Danach wurden sekundäre Repliken von ihr gelesen und sie sagten primär: "Wir haben aufgenommen!"
  

In dem Moment, in dem die meisten sekundären Replikate dies getan haben, wird die Anforderung als vollständig betrachtet und die Steuerung kehrt zum Treiber in der Anwendung zurück. Mit solchen Garantien können wir sicher sein, dass die Haltbarkeit nach der Rückkehr der Kontrolle zur Anwendung nirgendwohin führt, selbst wenn MongoDB sich hinlegt, außer bei absolut schrecklichen Katastrophen.

Glücklicherweise ist MongoDB eine solche Datenbank, mit der Sie die Haltbarkeitsgarantien für jede einzelne Anfrage reduzieren können.

Bei wichtigen Anfragen können wir standardmäßig die maximalen Haltbarkeitsgarantien beibehalten und bei einigen Anfragen reduzieren.

Klassen anfordern

Die erste Garantieebene, die wir entfernen können, besteht darin, nicht auf die Bestätigung des Datensatzes durch die meisten Replikate zu warten . Dies spart Latenz, erhöht jedoch nicht die Bandbreite. Manchmal ist jedoch eine Latenz erforderlich, insbesondere wenn der Cluster etwas überlastet ist und sekundäre Replikate nicht so schnell funktionieren, wie wir es möchten.

{w:1, j:true} 

Wenn wir Aufzeichnungen mit solchen Garantien schreiben, wissen wir in dem Moment, in dem wir die Kontrolle über die Anwendung erhalten, nicht mehr, ob die Aufzeichnung nach einem Unfall lebendig sein wird. Aber normalerweise lebt sie noch.

Die nächste Garantie, die sich auch auf Bandbreite und Latenz auswirkt, ist das Deaktivieren der Protokollierungsbestätigung . Ein Journaleintrag wird trotzdem geschrieben. Das Magazin ist einer der grundlegenden Mechanismen. Wenn wir die Bestätigung des Schreibens deaktivieren , tun wir nicht zwei Dinge: fsync im Protokoll und warten nicht, bis es endet . Dies kann eine Menge Festplattenressourcen einsparen und den Durchsatz um ein Vielfaches steigern, indem einfach die Dauer der Garantie geändert wird.

 {w:1, j:false} 

Die strengsten Haltbarkeitsgarantien sind das Deaktivieren von Bestätigungen . Wir erhalten nur eine Bestätigung, dass die Anfrage das primäre Replikat erreicht hat. Dies spart Latenz und erhöht den Durchsatz in keiner Weise.

 {w:0, j:false} —   . 

Wir werden auch verschiedene andere Dinge erhalten, zum Beispiel, dass die Aufzeichnung aufgrund eines Konflikts mit einem eindeutigen Schlüssel fehlgeschlagen ist.

Für welche Operationen gilt dies?

Ich erzähle Ihnen von der Anwendung für das Setup in Joom. Zusätzlich zur Last von Benutzern, bei denen es keine Zugeständnisse für die Haltbarkeit gibt, gibt es eine Last, die als Hintergrund-Batch-Last bezeichnet werden kann: Aktualisieren, Nachzählen von Bewertungen, Sammeln von Analysedaten.

Diese Hintergrundoperationen können Stunden dauern, sind jedoch so konzipiert, dass sie bei einem Absturz, beispielsweise einem Backend, nicht das Ergebnis all ihrer Arbeit verlieren, sondern von dem Punkt in der jüngeren Vergangenheit aus fortgesetzt werden. Das Reduzieren der Haltbarkeitsgarantie ist für solche Aufgaben nützlich, insbesondere da fsync im Protokoll wie bei allen anderen Vorgängen die Latenz auch beim Lesen erhöht.

Skalierung lesen

Das nächste Problem ist die unzureichende Lesebandbreite . Denken Sie daran, dass es in unserem Cluster nicht nur primäre, sondern auch sekundäre Replikate gibt, aus denen Sie lesen können . Lass es uns tun.

Sie können lesen, aber es gibt Nuancen. Etwas veraltete Daten stammen von sekundären Replikaten - um 0,5 bis 1 Sekunden. In den meisten Fällen ist dies normal, aber das Verhalten des sekundären Replikats unterscheidet sich vom Verhalten der primären Replikate.

Auf der sekundären Ebene wird oplog verwendet, das sich nicht auf der primären Replik befindet. Dieser Prozess ist nicht auf niedrige Latenz ausgelegt - nur die MongoDB-Entwickler haben sich nicht darum gekümmert. Unter bestimmten Umständen kann die Verwendung von Oplog von primär zu sekundär zu Verzögerungen von bis zu 10 s führen.

Sekundäre Replikate sind nicht für Benutzeranfragen geeignet - Benutzererfahrungen machen einen flotten Schritt in den Papierkorb.

Auf nicht schattierten Clustern sind diese Spitzen weniger auffällig, aber immer noch vorhanden. Shard-Cluster leiden darunter, dass Oplog besonders vom Löschen betroffen ist und das Löschen Teil der Aufgabe des Balancers ist . Der Balancer löscht Dokumente in kurzer Zeit zuverlässig und geschmackvoll zu Zehntausenden.

Anzahl der Verbindungen

Der nächste zu berücksichtigende Faktor ist die Begrenzung der Anzahl der Verbindungen auf MongoDB-Instanzen . Standardmäßig gibt es keine Einschränkungen, außer für Betriebssystemressourcen. Sie können eine Verbindung herstellen, solange dies zulässig ist.

Je mehr gleichzeitige Anforderungen gleichzeitig ausgeführt werden, desto langsamer werden sie ausgeführt. Die Leistung verschlechtert sich nichtlinear . Wenn daher eine Zunahme von Anfragen bei uns eintrifft, ist es besser, 80% zu bedienen, als 100% nicht zu bedienen. Die Anzahl der Verbindungen muss direkt auf MongoDB begrenzt werden.

Es gibt jedoch Fehler, die aufgrund dessen Probleme verursachen können. Insbesondere ist der Verbindungspool auf der MongoDB-Seite sowohl für Benutzer- als auch für Service-Intracluster-Verbindungen gleich . Wenn die Anwendung alle Verbindungen aus diesem Pool "gefressen" hat, kann die Integrität im Cluster verletzt werden.

Wir haben davon erfahren, als wir den Index neu erstellen wollten, und da wir die Eindeutigkeit aus dem Index entfernen mussten, durchlief das Verfahren mehrere Phasen. In MongoDB können Sie nicht gleich neben dem Index erstellen, jedoch ohne Eindeutigkeit. Deshalb wollten wir:

• Erstellen Sie einen ähnlichen Index ohne Eindeutigkeit
  
• Entfernen Sie den Index mit Eindeutigkeit.
  
• Erstellen Sie einen Index ohne Eindeutigkeit anstelle von Remote.
  
• vorübergehend löschen.
  

Als der temporäre Index noch auf dem sekundären Index fertiggestellt wurde, haben wir begonnen, den eindeutigen Index zu löschen. Zu diesem Zeitpunkt kündigte die sekundäre MongoDB ihre Sperre an. Einige Metadaten wurden blockiert, und in der Mehrzahl wurden alle Datensätze gestoppt: Sie hingen im Verbindungspool und warteten darauf, dass sie bestätigten, dass der Datensatz bestanden wurde. Alle Lesevorgänge auf der Sekundärseite wurden ebenfalls gestoppt, da das globale Protokoll erfasst wurde.

Der Cluster in einem so interessanten Zustand verlor auch seine Konnektivität. Manchmal erschien es und als zwei Bemerkungen miteinander verbunden waren, versuchten sie, in ihrem Zustand eine Wahl zu treffen, die sie nicht treffen konnten, weil sie eine globale Sperre haben.

Moral der Geschichte: Die Anzahl der Verbindungen muss überwacht werden.

Es gibt einen bekannten MongoDB-Rechen, der immer noch so oft angegriffen wird, dass ich mich entschlossen habe, einen kurzen Spaziergang darauf zu machen.

Verlieren Sie keine Dokumente

Wenn Sie eine Anforderung per Index an MongoDB senden, gibt die Anforderung möglicherweise nicht alle Dokumente zurück , die die Bedingung erfüllen, und dies in völlig unerwarteten Fällen. Dies liegt an der Tatsache, dass wenn wir zum Anfang des Index gehen, das Dokument, das am Ende für die Dokumente, die wir übergeben haben, an den Anfang verschoben wird. Dies ist ausschließlich auf die Veränderlichkeit des Index zurückzuführen . Verwenden Sie für eine zuverlässige Iteration Indizes für nicht stabile Felder, und es treten keine Schwierigkeiten auf.
MongoDB hat seine eigenen Ansichten, welche Indizes verwendet werden sollen. Die Lösung ist einfach: Mit Hilfe von $ Hinweis zwingen wir MongoDB, den von uns angegebenen Index zu verwenden .

Sammlungsgrößen

Unser Startup entwickelt sich, es gibt viele Daten, aber ich möchte keine Festplatten hinzufügen - wir haben im letzten Monat bereits dreimal hinzugefügt. Mal sehen, was in unseren Daten gespeichert ist, schauen wir uns die Größe der Dokumente an. Wie können Sie verstehen, wo in der Sammlung Sie die Größe reduzieren können? Nach zwei Parametern.

• Die Größe bestimmter Dokumente , die mit ihrer Länge Object.bsonsize() : Object.bsonsize() ;
  
• Entsprechend der durchschnittlichen Größe des Dokuments in der Sammlung : db.c.stats().avgObjectSize .
  

Wie kann die Größe des Dokuments beeinflusst werden?

Ich habe unspezifische Antworten auf diese Frage. Erstens erhöht ein langer Feldname die Größe des Dokuments. In jedem Dokument werden alle Feldnamen kopiert. Wenn das Dokument also einen langen Feldnamen hat, muss die Größe des Namens zur Größe jedes Dokuments hinzugefügt werden. Wenn Sie eine Sammlung mit einer großen Anzahl kleiner Dokumente in mehreren Feldern haben, benennen Sie die Felder mit Kurznamen: "A", "B", "CD" - maximal zwei Buchstaben. Auf der Festplatte wird dies durch Komprimierung ausgeglichen , aber alles wird unverändert im Cache gespeichert.

Der zweite Tipp ist, dass manchmal einige Felder mit geringer Kardinalität im Namen der Sammlung platziert werden können . Beispielsweise kann ein solches Feld eine Sprache sein. Wenn wir eine Sammlung mit Übersetzungen ins Russische, Englische, Französische und ein Feld mit Informationen zur gespeicherten Sprache haben, kann der Wert dieses Feldes in den Namen der Sammlung eingetragen werden. So reduzieren wir die Größe von Dokumenten und können die Anzahl und Größe von Indizes reduzieren - reine Einsparungen! Dies ist nicht immer möglich, da manchmal Indizes im Dokument vorhanden sind, die nicht funktionieren, wenn die Sammlung in verschiedene Sammlungen unterteilt ist.

Letzter Tipp zur Dokumentgröße - Verwenden Sie das Feld _id . Wenn Ihre Daten einen natürlichen eindeutigen Schlüssel haben, geben Sie ihn direkt in das Feld id_field ein. Auch wenn der Schlüssel zusammengesetzt ist - verwenden Sie eine zusammengesetzte ID. Es ist perfekt indiziert. Es gibt nur einen kleinen Rechen: Wenn Ihr Marshaller manchmal die Reihenfolge der Felder ändert, wird die ID mit denselben Feldwerten, aber mit unterschiedlicher Reihenfolge als unterschiedliche ID in Bezug auf einen eindeutigen Index in MongoDB betrachtet. In einigen Fällen kann dies in Go passieren.

Indexgrößen

Der Index speichert eine Kopie der darin enthaltenen Felder . Die Größe des Index besteht aus den indizierten Daten. Wenn wir versuchen, große Felder zu indizieren, müssen Sie sich darauf einstellen, dass der Index groß ist.

Der zweite Moment erhöht die Indizes stark: Array-Felder im Index multiplizieren andere Felder aus dem Dokument in diesem Index . Seien Sie vorsichtig mit großen Arrays in Dokumenten: Indizieren Sie entweder nichts anderes für das Array oder spielen Sie mit der Reihenfolge, in der die Felder im Index aufgelistet sind.

Die Reihenfolge der Felder ist wichtig , insbesondere wenn eines der Indexfelder ein Array ist . Wenn sich die Felder in der Kardinalität unterscheiden und sich in einem Feld die Anzahl der möglichen Werte stark von der Anzahl der möglichen Werte in einem anderen Feld unterscheidet, ist es sinnvoll, sie durch Erhöhen der Kardinalität zu erstellen. Sie können problemlos 50% der Indexgröße speichern, wenn Sie Felder mit unterschiedlicher Kardinalität austauschen. Die Permutation der Felder kann zu einer signifikanteren Verringerung der Größe führen.

Manchmal, wenn das Feld einen großen Wert enthält, müssen wir diesen Wert nicht mehr oder weniger vergleichen, sondern einen klaren Gleichheitsvergleich. Dann kann der Index für das Feld mit starkem Inhalt durch den Index für Hash aus diesem Feld ersetzt werden . Kopien von Hash werden im Index gespeichert, keine Kopien dieser Felder.

Dokumente löschen

Ich habe bereits erwähnt, dass das Löschen von Dokumenten ein unangenehmer Vorgang ist und es besser ist, wenn möglich nicht zu löschen. Versuchen Sie beim Entwerfen eines Datenschemas, entweder das Entfernen einzelner Daten zu minimieren oder ganze Sammlungen zu löschen. Sie könnten mit ganzen Sammlungen gelöscht werden. Das Entfernen von Sammlungen ist ein billiger Vorgang, und das Löschen von Tausenden einzelner Dokumente ist ein schwieriger Vorgang.

Wenn Sie immer noch viele Dokumente löschen müssen, müssen Sie die Drosselung durchführen . Andernfalls wirkt sich das Massenlöschen von Dokumenten auf die Leselatenz aus und ist unangenehm. Dies ist besonders schlecht für die Latenz auf sekundären.

Es lohnt sich, eine Art „Stift“ zu machen, um die Drosselung zu aktivieren - es ist sehr schwierig, das Niveau beim ersten Mal zu erreichen. Wir haben es so oft durchlaufen, dass die Drosselung ab dem dritten, vierten Mal vermutet wird. Betrachten Sie zunächst die Möglichkeit eines Festziehens.

Wenn Sie mehr als 30% einer großen Sammlung löschen, übertragen Sie Live-Dokumente in die benachbarte Sammlung und löschen Sie die alte Sammlung als Ganzes. Es ist klar, dass es Nuancen gibt, weil die Last von der alten auf die neue Sammlung umgeschaltet wird, aber wenn möglich verschoben wird.

Eine andere Möglichkeit, Dokumente zu löschen, ist der TTL- Index, ein Index, der das Feld indiziert, das den Mongo-Zeitstempel enthält, der das Datum enthält, an dem das Dokument gestorben ist. Zu diesem Zeitpunkt löscht MongoDB dieses Dokument automatisch.

Der TTL-Index ist praktisch, aber es gibt keine Drosselung in der Implementierung. MongoDB ist es egal, wie diese Löschungen entfernt werden. Wenn Sie versuchen, eine Million Dokumente gleichzeitig zu löschen, haben Sie einige Minuten lang einen nicht funktionsfähigen Cluster, der sich nur mit dem Löschen und nicht mehr befasst. Um dies zu verhindern, fügen Sie etwas Zufälligkeit hinzu , verbreiten Sie die TTL so weit, wie es Ihre Geschäftslogik und die Spezialeffekte auf die Latenz zulassen. Das Verschmieren von TTL ist unerlässlich, wenn Sie natürliche Gründe für die Geschäftslogik haben, die das Löschen zu einem bestimmten Zeitpunkt konzentrieren.

Scherben

Wir haben versucht, diesen Moment zu verschieben, aber es ist soweit - wir müssen immer noch horizontal skalieren. Für MongoDB ist dies eine Scherbe.

Wenn Sie bezweifeln, dass Sie Scherben benötigen, brauchen Sie diese nicht.

Sharding verkompliziert das Leben eines Entwicklers und entwickelt sich auf verschiedene Weise. In einem Unternehmen nennen wir es Sharding Tax. Wenn wir eine Sammlung sharden, nimmt die spezifische Leistung der Sammlung ab : MongoDB benötigt einen separaten Index für das Sharding, und zusätzliche Parameter müssen an die Anforderung übergeben werden, damit sie effizienter ausgeführt werden kann.

Einige Sharding-Dinge funktionieren einfach nicht gut. Zum Beispiel ist es eine schlechte Idee, Abfragen mit skip , insbesondere wenn Sie viele Dokumente haben. Sie geben den Befehl: "100.000 Dokumente überspringen."

MongoDB denkt so: „Erstens, zweitens, drittens ... einhunderttausendstel, gehen wir weiter. Und wir werden dies dem Benutzer zurückgeben. “

In einer nicht gemeinsam genutzten Sammlung führt MongoDB eine Operation irgendwo in sich selbst aus. In Shard-like - sie liest wirklich alle 100.000 Dokumente und sendet sie an einen Sharding-Proxy - in Mongos , die bereits auf ihrer Seite die ersten 100.000 herausfiltern und verwerfen. Eine unangenehme Funktion, die man beachten sollte.

Der Code wird mit dem Sharding sicherlich komplizierter - Sie müssen den Sharding-Schlüssel an viele Stellen ziehen. Dies ist nicht immer bequem und nicht immer möglich. Einige Abfragen werden entweder per Broadcast oder Multicast gesendet, wodurch auch die Skalierbarkeit nicht erhöht wird. Treffen Sie die Wahl eines Schlüssels, mit dem das Sharding genauer wird.

In Shard-Sammlungen wird die count unterbrochen . Sie beginnt mehr als in der Realität eine Zahl zurückzugeben - sie kann zweimal lügen. Der Grund liegt im Ausgleichsprozess, wenn Dokumente von einem Splitter zum anderen gegossen werden. Wenn die Dokumente auf den benachbarten Splitter gegossen, aber noch nicht auf dem Original gelöscht wurden, count sie trotzdem gezählt. MongoDB-Entwickler nennen dies keinen Fehler - es ist eine solche Funktion. Ich weiß nicht, ob sie das Problem beheben werden oder nicht.

Ein gemischter Cluster ist viel schwieriger zu verwalten . Devops werden Sie nicht mehr begrüßen, da das Entfernen eines Backups radikal komplizierter wird. Beim Sharding blinkt die Notwendigkeit einer Infrastrukturautomatisierung wie ein Feueralarm - etwas, auf das Sie vorher hätten verzichten können.

Wie Sharding in MongoDB funktioniert

Es gibt eine Sammlung, wir wollen sie irgendwie um Scherben verteilen. Zu diesem Zweck teilt MongoDB die Sammlung mithilfe des Shard-Schlüssels in Blöcke auf und versucht, sie im Shard-Schlüsselbereich in gleiche Teile zu teilen. Als nächstes kommt der Balancer, der diese Brocken sorgfältig nach den Scherben im Cluster auslegt . Darüber hinaus ist es dem Balancer egal, wie viel diese Brocken wiegen und wie viele Dokumente sich darin befinden, da das Balancieren Stück für Stück erfolgt.

Sharding Key

Entscheiden Sie immer noch, was Sie scherben möchten? Nun, die erste Frage ist, wie man einen Sharding-Schlüssel auswählt. Ein guter Schlüssel hat mehrere Parameter: hohe Kardinalität , Nichtstabilität und passt gut zu häufigen Anforderungen .

Die natürliche Wahl eines Sharding-Schlüssels ist der Primärschlüssel - das ID-Feld. Wenn das ID-Feld zum Sharding geeignet ist, ist es besser, direkt darauf zu sharden. Dies ist eine ausgezeichnete Wahl - er hat eine gute Kardinalität, er ist nicht stabil, aber wie gut er in häufige Anfragen passt, hängt von Ihrer Geschäftsspezifität ab. Bauen Sie auf Ihre Situation auf.

Ich werde ein Beispiel für einen fehlgeschlagenen Sharding-Schlüssel geben. Ich habe bereits die Sammlung von Übersetzungen erwähnt - Übersetzungen. Es hat ein Sprachfeld, in dem die Sprache gespeichert ist. Zum Beispiel unterstützt die Sammlung 100 Sprachen und wir shard Sprache. Das ist schlecht - Kardinalität, die Anzahl der möglichen Werte beträgt nur 100 Stück, was klein ist. Dies ist jedoch nicht das Schlimmste - vielleicht reicht Kardinalität für diese Zwecke aus. Schlimmer noch, sobald wir uns in der Sprache umgesehen haben, stellen wir sofort fest, dass wir dreimal mehr englischsprachige Benutzer haben als die anderen. Dreimal so viele Anfragen kommen an die unglückliche Scherbe, in der sich Englisch befindet, als an alle anderen zusammen.

Daher sollte berücksichtigt werden, dass ein Splitterschlüssel manchmal natürlich zu einer ungleichmäßigen Lastverteilung neigt.

Ausbalancieren

Wir kommen zum Sharding, wenn der Bedarf für uns gereift ist - unser MongoDB-Cluster knarrt, knirscht mit seinen Festplatten, Prozessor - mit allem, was wir können. Wohin? Nirgendwo, und wir mischen heldenhaft die Fersen der Sammlungen. Wir scherben, starten und stellen plötzlich fest, dass das Balancieren nicht kostenlos ist .

Das Balancieren durchläuft mehrere Phasen. Der Balancer wählt Brocken und Scherben aus, von wo und wohin er transferiert. Die weitere Arbeit erfolgt in zwei Phasen: Zuerst werden Dokumente von der Quelle zum Ziel kopiert und dann werden kopierte Dokumente gelöscht .

Unsere Scherbe ist überladen, sie enthält alle Sammlungen, aber der erste Teil der Operation ist für ihn einfach. Aber das zweite - das Entfernen - ist ziemlich unangenehm, weil es eine Scherbe auf die Schulterblätter legt und bereits unter Last leidet.

Das Problem wird durch die Tatsache verschärft, dass, wenn wir viele Chunks, zum Beispiel Tausende, ausgleichen, mit den Standardeinstellungen alle diese Chunks zuerst kopiert werden und dann ein Entferner hereinkommt und beginnt, sie in großen Mengen zu löschen. Ab diesem Zeitpunkt ist der Vorgang nicht mehr betroffen und Sie müssen nur noch traurig beobachten, was passiert.

Wenn Sie sich einem überlasteten Cluster nähern, müssen Sie daher planen, da das Ausgleichen Zeit benötigt. Es ist ratsam, diese Zeit nicht zur Hauptsendezeit, sondern in Zeiten geringer Last zu nehmen. Balancer - ein nicht angeschlossenes Ersatzteil. Sie können sich dem primären Ausgleich im manuellen Modus nähern, den Ausgleich in der Hauptsendezeit ausschalten und ihn einschalten, wenn die Last abgenommen hat, um sich mehr zu erlauben.

Wenn Sie mit den Funktionen der Cloud weiterhin vertikal skalieren können, sollten Sie die Shard-Quelle im Voraus verbessern, um all diese Spezialeffekte geringfügig zu reduzieren.

Scherben müssen sorgfältig vorbereitet werden.

HighLoad ++ Siberia 2019 wird am 24. und 25. Juni in Nowosibirsk erscheinen. HighLoad ++ Sibirien bietet Entwicklern aus Sibirien die Möglichkeit, Berichte anzuhören, über hochgeladene Themen zu sprechen und in die Umgebung einzutauchen, in der "jeder seine eigenen hat", ohne über dreitausend Kilometer nach Moskau oder St. Petersburg zu fliegen. Von den 80 Anträgen genehmigte das Programmkomitee 25, und wir berichten über alle anderen Änderungen im Programm, Ankündigungen von Berichten und andere Neuigkeiten in unserer Mailingliste. Abonnieren Sie , um auf dem Laufenden zu bleiben.