{"id":106286,"date":"2022-12-28T15:36:45","date_gmt":"2022-12-28T13:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11"},"modified":"2022-12-28T15:36:45","modified_gmt":"2022-12-28T13:36:45","slug":"predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","title":{"rendered":"Eine neue bedeutende Version der Datenbank MariaDB 11 wurde vorgestellt.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach 10 Jahren seit der Einf\u00fchrung des 10.x-Zweigs wird mit MariaDB 11.0.0 eine neue Version des Datenbankmanagementsystems vorgestellt, die mehrere bedeutende Verbesserungen und inkompatible \u00c4nderungen bietet. Der Branch hat derzeit den Status eines Alpha-Releases und wird f\u00fcr den produktiven Einsatz bereit sein, nachdem Stabilit\u00e4tspr\u00fcfungen abgeschlossen sind. Der n\u00e4chste bedeutende Branch, MariaDB 12, wird voraussichtlich fr\u00fchestens in 10 Jahren (im Jahr 2032) erscheinen und enth\u00e4lt ebenfalls inkompatible \u00c4nderungen. <\/p>\n
Das MariaDB-Projekt ist eine Abspaltung von MySQL, die m\u00f6glichst die R\u00fcckw\u00e4rtskompatibilit\u00e4t bewahrt und sich durch die Integration zus\u00e4tzlicher Speicher-Engines sowie erweiterte Funktionen auszeichnet. Die Entwicklung von MariaDB wird von der unabh\u00e4ngigen Organisation MariaDB Foundation geleitet, die einen offenen und transparenten Entwicklungsprozess verfolgt, der nicht von einzelnen Anbietern abh\u00e4ngt. MariaDB ersetzt MySQL in vielen Linux-Distributionen (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) und wird in gro\u00dfen Projekten wie Wikipedia, Google Cloud SQL und Nimbuzz eingesetzt. <\/p>\n
Ein wesentliches Verbesserungsmerkmal in der MariaDB 11-Version ist der Wechsel des Abfrageoptimierers zu einem neuen Kostenmodell, das eine genauere Vorhersage der Kosten jedes Ausf\u00fchrungsplans erm\u00f6glicht. Obwohl das neue Modell einige Leistungsengp\u00e4sse beseitigt, k\u00f6nnte es in bestimmten Szenarien suboptimal sein und zu einer Verlangsamung mancher Abfragen f\u00fchren. Daher wird den Nutzern empfohlen, an Tests teilzunehmen und die Entwickler im Falle von Problemen zu informieren. <\/p>\n
Das zuvor verwendete Modell eignete sich gut zur Ermittlung des optimalen Index, hatte jedoch Probleme bei der Anwendbarkeit von Tabellenscans, Indexscans oder Bereichsabfragen. In dem neuen Modell wurde dieser Nachteil durch eine Anpassung der Basisgewichte der Operationen mit der Speicherungsmotor beseitigt. Bei der Bewertung der Leistung von Operationen, die von der Festplattengeschwindigkeit abh\u00e4ngen, wie z. B. sequenziellen Aufzeichnungen, wird nun davon ausgegangen, dass die Daten auf einem SSD-Laufwerk gespeichert sind, das eine Lesegeschwindigkeit von 400 MB pro Sekunde bietet. Dar\u00fcber hinaus wurden auch andere Gewichtungsparameter des Optimierers optimiert, was beispielsweise die Verwendung von Indizes f\u00fcr die Operationen \u201eORDER BY\/GROUP BY\u201c in Unterabfragen erm\u00f6glicht und die Arbeit mit sehr kleinen Tabellen beschleunigt hat. <\/p>\n
Es wird darauf hingewiesen, dass das neue Gewichtungsmodell in den folgenden Situationen die Auswahl eines optimaleren Ausf\u00fchrungsplans f\u00fcr Abfragen erm\u00f6glicht: <\/p>\n
\n
Bei Abfragen, die mehr als 2 Tabellen abdecken.\n
Wenn Indizes mit einer gro\u00dfen Anzahl identischer Werte vorhanden sind.\n
Bei der Verwendung von Bereichen, die mehr als 10 % der Tabelle abdecken.\n
Bei komplexen Abfragen, bei denen nicht alle verwendeten Spalten indexiert sind.\n
Wenn Abfragen verwendet werden, die verschiedene Speichermotoren ansprechen (zum Beispiel, wenn in einer Abfrage auf Tabellen in den Engines InnoDB und Memory zugegriffen wird).\n
Bei der Verwendung von FORCE INDEX zur Verbesserung des Abfrageplans.\n
Bei einer Verschlechterung des Abfrageplans im Falle der Verwendung von \u201eANALYZE TABLE\u201c.\n
Wenn die Abfrage eine gro\u00dfe Anzahl von abgeleiteten Tabellen umfasst (eine hohe Anzahl von verschachtelten SELECTs).\n
Bei der Verwendung von ORDER BY oder GROUP BY-Anweisungen, die unter die Indizes fallen. <\/ul>\n
Hauptvertr\u00e4glichkeitsprobleme in der MariaDB 11-Serie: <\/p>\n
\n
SUPER-Rechte erm\u00f6glichen nicht mehr die Ausf\u00fchrung von Aktionen, f\u00fcr die separate Privilegien erforderlich sind. Zum Beispiel sind f\u00fcr die \u00c4nderung des Formats von Bin\u00e4rprotokollen die Rechte BINLOG ADMIN erforderlich.\n
Die Implementierung des Change Buffers in InnoDB wurde entfernt.\n
innodb_flush_method und innodb_file_per_table wurden als veraltet erkl\u00e4rt.\n
Die Unterst\u00fctzung von mysql*-Namen wurde als veraltet erkl\u00e4rt.\n
Das Setzen des Parameters explicit_defaults_for_timestamp auf 0 wurde als veraltet erkl\u00e4rt.\n
Symbolische Links zur Kompatibilit\u00e4t mit MySQL wurden in ein separates Paket ausgegliedert.\n
Der Standardwert des Parameters innodb_undo_tablespaces wurde auf 3 ge\u00e4ndert. <\/ul>\n<\/ul>\n