it-swarm.com.de

Informationen zur Leistung von Single-Threaded- und Multithread-Datenbanken

H2 ist eine Single-Threaded-Datenbank mit einem guten Ruf in Bezug auf die Leistung. Andere Datenbanken sind Multithread-Datenbanken.

Meine Frage ist: Wann wird eine Multithread-Datenbank interessanter als eine Single-Thread-Datenbank? Wie viele Benutzer? Wie viele Prozesse? Was ist der Auslöser? Hat jemand Erfahrung zu teilen?

Zusammenfassung

  • Der übliche Engpass ist der Festplattenzugriff
  • SSDs sind schnell, aber zerbrechlich (Fehlerverfahren ist ein Muss)
  • Eine lange Abfrage auf einem einzelnen Thread-System blockiert alle anderen
  • Das Konfigurieren eines Multithreading-Systems kann schwierig sein
  • Multithread-Datenbanken sind auch auf Single-Core-Systemen von Vorteil
59

Hier ist meine Meinung:

Normalerweise ist der Engpass (oder der langsamste Teil) eines DB-Systems die Festplatte. Die CPU spitzt nur während arithmetischer Operationen, Verarbeitung oder anderer Aufgaben, die die CPU ausführt. Bei richtiger Architektur kann Multithreading dazu beitragen, die Last einer Abfrage auf die CPU auszugleichen, anstatt die langsamen Lese-/Schreibvorgänge auf der Festplatte durchzuführen. Es gibt Fälle, in denen es schneller ist, einen Wert mithilfe der CPU-Zyklen zu berechnen, als eine berechnete Spalte (die zuvor auf der Festplatte gespeichert wurde) zu erstellen und diese Spalte von der Festplatte zu lesen.

In einigen RDBMS gibt es eine temporäre Datenbank (Tempdb), die von allen DBs in dieser Instanz zum Sortieren, Hashing, temporären Variablen usw. verwendet wird. Multithreading und Aufteilen dieser Tempdb-Dateien können verwendet werden, um den Durchsatz der Tempdb zu verbessern Dadurch wird die Gesamtserverleistung verbessert.

Mithilfe von Multithreading (Parallelität) kann die Ergebnismenge einer Abfrage aufgeteilt werden, um auf den verschiedenen Kernen des Servers verarbeitet zu werden, anstatt nur einen Kern zu verwenden. Diese Funktion verbessert nicht immer die Leistung, aber es gibt Fälle, in denen dies der Fall ist, und daher ist die Funktion verfügbar.

Die der Datenbank zur Verfügung stehenden Threads werden für viele Zwecke verwendet: Lesen/Schreiben auf die Festplatte, Benutzerverbindungen, Hintergrundjobs, Sperren/Verriegeln, Netzwerk-E/A usw. Abhängig von der Betriebssystemarchitektur werden die Threads präventiv der CPU zugeführt und werden verwaltet mit Wartezeiten und Warteschlangen. Wenn die CPU diese Threads ziemlich schnell knacken kann, sind die Wartezeiten gering. Ein Multithread-DB ist schneller als ein Single-Thread-DB, da in einem Single-Thread-DB nur ein Thread recycelt werden muss, anstatt dass andere Laufflächen verfügbar sind.

Die Skalierbarkeit wird ebenfalls zu einem Problem, da mehr Threads erforderlich sind, um das skalierte DB-System zu verwalten und auszuführen.

31
StanleyJohns

Wenn es eine Sache gibt, die ich über MySQL sagen kann, ist, dass InnoDB, seine Transaktionsspeicher-Engine (ACID-kompatibel), tatsächlich Multithread-fähig ist. Es ist jedoch so multithreaded, wie Sie es konfigurieren !!! InnoDB bietet auch in der Standardeinstellung eine hervorragende Leistung in einer einzelnen CPU-Umgebung. Um die InnoDB-Multithreading-Funktionen nutzen zu können, müssen Sie viele Optionen aktivieren.

innodb_thread_concurrency legt die Obergrenze für die Anzahl gleichzeitiger Threads fest, die InnoDB offen halten kann. Die beste runde Nummer hierfür ist (2 x Anzahl der CPUs) + Anzahl der Festplatten. [~ # ~] update [~ # ~] : Wie ich aus erster Hand von der Percona NYC-Konferenz erfahren habe, sollten Sie dies auf 0 setzen, um zu warnen InnoDB Storage Engine, um die beste Anzahl von Threads für die Umgebung zu finden, in der es ausgeführt wird.

innodb_concurrency_tickets legt die Anzahl der Threads fest, die die Parallelitätsprüfung ungestraft umgehen können. Nach Erreichen dieses Grenzwerts wird die Überprüfung der Thread-Parallelität wieder zur Norm.

innodb_commit_concurrency legt die Anzahl der gleichzeitigen Transaktionen fest, die festgeschrieben werden können. Da der Standardwert 0 ist, kann durch Nichteinstellung einer beliebigen Anzahl von Transaktionen gleichzeitig festgeschrieben werden.

innodb_thread_sleep_delay legt die Anzahl der Millisekunden fest, die ein InnoDB-Thread ruhen kann, bevor er erneut in die InnoDB-Warteschlange eingeht. Die Standardeinstellung ist 10000 (10 Sek.).

innodb_read_io_threads und innodb_write_io_threads (beide seit MySQL 5.1.38) weisen die angegebene Anzahl von Threads für Lese- und Schreibvorgänge zu. Die Standardeinstellung ist 4 und das Maximum ist 64.

innodb_replication_delay legt einem Slave eine Thread-Verzögerung auf, wenn innodb_thread_concurrency erreicht ist.

innodb_read_ahead_threshold ermöglicht lineare Ablesungen der festgelegten Anzahl von Extents (64 Seiten [Seite = 16 KB]), bevor auf asynchrones Lesen umgeschaltet wird.

Die Zeit würde mir entgehen, wenn ich mehr Optionen nennen würde. Sie können darüber in MySQLs Dokumentation lesen.

Die meisten Menschen kennen diese Funktionen nicht und sind sehr zufrieden damit, dass InnoDB nur ACID-konforme Transaktionen durchführt. Wenn Sie eine dieser Optionen optimieren, geschieht dies auf eigene Gefahr.

Ich habe mit MySQL 5.5 Multiple Buffer Pool Instances (162 GB in 9 Buffer Pools Instanzen) gespielt und versucht, Daten auf diese Weise automatisch im Speicher zu partitionieren. Einige Experten sagen, dass dies zu einer Leistungsverbesserung von 50% führen sollte. Was ich bekam, war eine Menge Thread-Sperren, die InnoDB tatsächlich zum Crawlen brachten. Ich wechselte zu 1 Puffer (162 GB) und alles war wieder gut in der Welt. Ich denke, Sie benötigen Percona-Experten, um dies einzustellen. Ich werde morgen auf der Percona MySQL-Konferenz in New York sein und danach fragen, ob sich die Gelegenheit bietet.

Zusammenfassend lässt sich sagen, dass sich InnoDB auf einem Server mit mehreren CPUs aufgrund seiner Standardeinstellungen für Multithread-Vorgänge jetzt gut verhält. Das Optimieren erfordert große Sorgfalt, große Geduld, gute Dokumentation und guten Kaffee (oder Red Bull, Jolt usw.).

Guten Morgen, guten Abend und gute Nacht !!!

UPDATE 27.05.2011 20:11

Kam am Donnerstag von Percona MySQL-Konferenz in New York zurück. Was für eine Konferenz. Ich habe viel gelernt, aber ich habe eine Antwort erhalten, die ich in Bezug auf InnoDB prüfen werde. Ich wurde von Ronald Bradford informiert, dass InnoBB durch Setzen von 0 auf innodb_thread_concurrency die beste Vorgehensweise intern mit Thread-Parallelität festlegen kann. Ich werde in MySQL 5.5 weiter damit experimentieren.

UPDATE 2011-06-01 11:20

InnoDB ist ACID-konform und funktioniert sehr gut mit MultiVersion Concurrency Control . Transaktionen sollten Isolationsstufen aufweisen (standardmäßig wiederholbare Lesevorgänge), die verhindern, dass andere Personen auf Daten zugreifen können.

Bei Multi-Core-Systemen hat InnoDB einen langen Weg zurückgelegt. In der Vergangenheit konnte InnoDB in einer Multicore-Umgebung keine gute Leistung erbringen. Ich erinnere mich, dass ich mehrere MySQL-Instanzen auf einem einzelnen Server ausführen musste, um die mehreren Kerne dazu zu bringen, die mehreren MySQL-Prozesse auf die CPUs zu verteilen. Dies ist dank Percona und später MySQL (eh, Oracle, was mich immer noch zum Würgen bringt) nicht mehr erforderlich, da InnoDB zu einer ausgereifteren Speicher-Engine entwickelt wurde, die ohne großen Aufwand einfach auf die Kerne zugreifen kann. Die aktuelle Instanz von InnoDB kann heute auf einem einzelnen Kernserver gut funktionieren.

49
RolandoMySQLDBA

Sobald Sie mehrere Benutzer oder Prozesse gleichzeitig haben oder sogar einen einzelnen Prozess mit Multithread-Datenbankzugriff, wird eine Datenbank, die Threading unterstützt, möglicherweise interessant.

H2 ist threadsicher, serialisiert jedoch alle Anforderungen an die Datenbank, was in einem Szenario mit hoher Last zu einem potenziellen Leistungsproblem werden kann. Ob dies für ein bestimmtes Projekt tatsächlich der Fall ist, hängt von einer Kombination Ihrer Leistungsanforderungen, der Anzahl der Threads/Benutzer/Prozesse, die auf die Datenbank zugreifen, der Häufigkeit der von diesen Threads ausgeführten Abfragen und der durchschnittlichen und Worst-Case-Leistung Ihres Projekts ab Anfragen.

Wenn Ihre Leistungsanforderungen beispielsweise innerhalb einer Sekunde beantwortet werden sollen, haben Sie nicht mehr als 10 gleichzeitige Benutzer, die eine einzelne Abfrage ausführen, deren Ausführung 0,05 Sekunden dauert. Mit einer Single-Threaded-Datenbank können Sie diese Ziele dennoch erreichen (obwohl Multithreading) würde wahrscheinlich schon einen spürbaren Leistungsschub geben). Angesichts des gleichen Szenarios mit einer einzelnen potenziellen Abfrage mit einer Worst-Case-Leistung von einer halben Sekunde können Sie durch die Serialisierung Ihres Datenbankzugriffs Ihre Leistungsziele nicht mehr erreichen.

Wenn Sie derzeit H2 in Ihrem Projekt verwenden, würde ich Ihnen empfehlen, einen Profiler für Ihre Codebasis unter einem Ladeszenario auszuführen (starten Sie einfach eine x-Anzahl von Threads, die gleichzeitig mit einigen typischen Anwendungsfällen auf Ihren Code treffen). Auf diese Weise erhalten Sie tatsächliche Messdaten zur Leistung und zu Engpässen in Ihrer Codebasis, anstatt nur zu theoretisieren. Wenn dies zeigt, dass Ihre Anforderungen einen großen Teil ihrer Zeit damit verbringen, nur auf den Zugriff auf die Datenbank zu warten, ist es Zeit, zu einer Thread-Datenbank zu wechseln.

11
Luke Hutteman

Nach allem, was ich sagen kann, ist "Single-Threaded" eine Art Fehlbezeichnung für H2. Der Punkt ist, dass es serialisiert alle Transaktionen (dh sie einzeln ausführen).

Die entscheidende Frage, ob dies für Ihre Anwendung "in Ordnung" ist oder nicht, lautet nicht "Wie viele Benutzer?". oder sogar "Wie viele Prozesse?", aber "Wie lange werden meine Transaktionen dauern?"

Wenn alle Ihre Transaktionen in Sekundenschnelle ausgeführt werden, ist dies möglicherweise in Ordnung. Wenn einige mehrere Stunden dauern, ist dies möglicherweise nicht in Ordnung, da alle anderen ausstehenden Transaktionen darauf warten, dass sie abgeschlossen werden. Die Entscheidung, ob dies "in Ordnung" ist oder nicht, hängt von Ihren eigenen Leistungsanforderungen ab - dh wie lange es akzeptabel ist, bis meine Benutzer die Datenbank mit Transaktionen erreichen.

--BEARBEITEN

Es scheint, dass H2 Transaktionen nicht wirklich serialisiert - nur DML. Mit anderen Worten, viele kurze Updates innerhalb einer einzelnen langen Transaktion blockiert keine anderen Updates . Wenn Sie jedoch nicht die experimentelle MVCC-Funktion verwenden, bedeutet das Sperren von Tabellen, dass dies in der Praxis einen ähnlichen Effekt hat. Es gibt auch eine experimentelle "multi_threaded" -Funktion , aber es kann nicht gleichzeitig mit MVCC verwendet werden