MySQL InnoDB, Multithreading, Multiinserts und Sperren. Suche nach der richtigen Strategie

Question

Meine Frage ist nicht spezifisch, aber es ist abstrakt. In meinen Projekten beschäftige ich mich oft mit der Verarbeitung von Hintergrund-DBs, habe aber immer noch keine gute Strategie, wie man das richtig macht.

Zum Beispiel haben wir eine Tabelle mit vielen Datensätzen haben, mehrere hunderttausend Datensätze oder Ereignis Millionen. Hintergrund-Daemon ändert die Daten dieser Tabelle permanent. Es aktualisiert und fügt Datensätze basierend auf anderen Daten ein, die von außen eingeholt wurden. Um Zeit zu sparen, verwende ich Multi-INSERTs, um eine Zeit zu sparen, weil ich mir nicht vorstellen kann, wie lange die Aktualisierungsdatensätze einzeln dauern können. Da der Hintergrundprozess im Multi-Threading-Modus ausgeführt wird, musste ich WRITE LOCK für diese Tabelle verwenden. Wenn ich das nicht mache, dann bekomme ich viele Deadlock-Fehler, weil jedes Multi-Insert Lücken und Autoinkremente in der Tabelle blockiert und sie nicht unabhängig voneinander ausführen können. WRITE LOCK versetzt alle Abfragen in die Warteschlange und sie werden nacheinander ausgeführt. Die nächste Abfrage wartet, während die vorherige abgeschlossen ist. Vielleicht ist hier mein erster Fehler, aber ich habe keine andere effektive Methode gefunden, Multi-Inserts im Multithread-Modus auszuführen. Ein einfaches Schema des Daemon sieht so aus:

Von der anderen Seite haben wir eine Benutzeroberfläche, die Daten aus der Tabelle anzeigt. Es führt SELECT-Abfrage von unserer Tabelle aus. Aber wie gesagt, wenn der Hintergrundprozess läuft, ist die WRITE-Sperre aktiviert. Das bedeutet, READ-Operationen sollten auch warten, während die Sperre aktiv ist. Für den Benutzer sieht es aus wie ein ganzer Server gehängt.

, warum ich diese Frage zu schreiben. Gibt es Strategien, große Datenmengen zusammen mit der Lesefähigkeit zu modifizieren?

Answer 1

Anstatt WRITE LOCK, lassen Sie uns die Deadlocks minimieren und mit denen umgehen, die immer noch passieren.

• Sortieren Sie die Daten, die Sie dosieren (Mehrfacheinfügung oder Aktualisierung).
• Do not Batch "zu viele". Jenseits von etwa 100 Zeilen ist eine Batch-Einfügung in "abnehmende Erträge". Das heißt, es lohnt sich nicht 1000 auf einmal zu dosieren. Wenn 100 Ihnen zu viele Deadlocks gibt, wählen Sie eine niedrigere Nummer.
• Wenn ein Deadlock geschieht, wiederholen die Transaktion.
• Statistiken sammeln. Wie viele Zeilen, wie viele Transaktionen, wie viele Deadlocks usw. Diese Metriken helfen Ihnen, die Stapelverarbeitung zu optimieren.

Staging-Tabelle. Ein anderer Ansatz besteht darin, Dinge durch eine Zwischenspeichertabelle (Arbeitstabelle) zu einem einzelnen Prozessor zu trichterieren; mehrere Quellen können es füttern. Das bedeutet, dass viele Verbindungen in eine einzige Tabelle ohne Indizes und so wenig Aufwand wie möglich eingefügt werden. Haben Sie einen Prozess, der an einer anderen Tabelle arbeitet; Flip-Flop die Tabellen, wenn Sie fertig sind. Siehe high speed ingestion.

anzumerken, dass die Normalisierung und andere chaotische Prozesse behandelt werden können, während die Daten in der Zwischenspeichertabelle ist, um dadurch nicht die Haupttabelle stören und liest.

Was ich gerade beschrieben, ähnlich wie @Drew in den Kommentaren erwähnt. Ich schlage jedoch vor, kontinuierlich zu bearbeiten und flipflopping - das vermeidet Unordnung der löscht, etc.

Auf der lesen Seite, stellen Sie sicher, dass die Abfragen gut optimiert sind. Einsatz