{"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\/news\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","title":{"rendered":"Die 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 der Version 10.x wurde die Datenbank MariaDB 11.0.0 ver\u00f6ffentlicht, die mehrere bedeutende Verbesserungen und \u00c4nderungen enth\u00e4lt, die die Kompatibilit\u00e4t beeintr\u00e4chtigen. Die Version hat derzeit den Status einer Alpha-Version und wird f\u00fcr produktive Anwendungen nach der Stabilisierung bereit sein. Die n\u00e4chste bedeutende Version, MariaDB 12, welche inkompatible \u00c4nderungen enth\u00e4lt, wird fr\u00fchestens in 10 Jahren (im Jahr 2032) erwartet. <\/p>\n
Das Projekt MariaDB entwickelt eine Abspaltung von MySQL, die m\u00f6glichst die R\u00fcckw\u00e4rtskompatibilit\u00e4t wahrt und sich durch die Integration zus\u00e4tzlicher Speichermotoren und erweiterter Funktionen auszeichnet. Die Entwicklung von MariaDB wird von der unabh\u00e4ngigen Organisation MariaDB Foundation in einem offenen und transparenten Entwicklungsprozess geleitet, der nicht von einzelnen Anbietern abh\u00e4ngig ist. Die Datenbank MariaDB wird in vielen Linux-Distributionen (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) anstelle von MySQL ausgeliefert und ist in gro\u00dfen Projekten wie Wikipedia, Google Cloud SQL und Nimbuzz integriert. <\/p>\n
Das wichtigste Upgrade in der Version MariaDB 11 ist der Wechsel des Abfrageoptimierers auf ein neues Kostenmodell (cost model), das eine genauere Vorhersage der Gewichtungen jedes Ausf\u00fchrungsplans erm\u00f6glicht. Obwohl das neue Modell einige Engp\u00e4sse bei der Leistung beseitigen kann, ist es m\u00f6glicherweise nicht in allen Szenarien optimal und k\u00f6nnte einige Abfragen verlangsamen. Daher wird den Benutzern empfohlen, an Tests teilzunehmen und die Entwickler bei Problemen zu informieren. <\/p>\n
Das zuvor verwendete Modell war gut geeignet, um den optimalen Index zu finden, hatte jedoch Probleme mit der Anwendbarkeit von Tabellenscans, Indexscans oder Bereichsabfragen. In dem neuen Modell wurde dieser Nachteil durch die Anpassung des Basisgewichts von Speicher-Engine-Operationen behoben. Bei der Leistungsbewertung von Operationen, die von der Datentransferrate abh\u00e4ngen, wie dem sequenziellen Scannen von Datens\u00e4tzen, wird nun angenommen, dass die Daten auf einer SSD gespeichert sind, die eine Lesegeschwindigkeit von 400 MB pro Sekunde bietet. Zus\u00e4tzlich wurden auch andere Gewichtungsparameter des Optimierers angepasst, wodurch beispielsweise die Verwendung von Indizes f\u00fcr die Operationen \u201eORDER BY\/GROUP BY\u201c in Unterabfragen realisiert und die Verarbeitung sehr kleiner Tabellen beschleunigt werden konnte. <\/p>\n
Es wird festgestellt, dass das neue Gewichtungsmodell die Auswahl eines optimaleren Ausf\u00fchrungsplans f\u00fcr Abfragen in folgenden Situationen erm\u00f6glichen wird: <\/p>\n
\n
Bei der Verwendung von Abfragen, die mehr als 2 Tabellen abdecken.\n
Bei Vorhandensein von Indizes mit einer gro\u00dfen Anzahl gleicher Werte.\n
Bei der Verwendung von Bereichen, die mehr als 10 % der Tabelle abdecken.\n
Bei komplexen Abfragen, in denen nicht alle verwendeten Spalten indiziert sind.\n
Wenn Abfragen verwendet werden, die verschiedene Speicher-Engines 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 bei Verwendung von \u201eANALYZE TABLE\u201c.\n
Wenn die Abfrage eine gro\u00dfe Anzahl abgeleiteter Tabellen umfasst (eine gro\u00dfe Anzahl von verschachtelten SELECTs).\n
Bei der Verwendung von ORDER BY oder GROUP BY-Ausdr\u00fccken, die in die Indizes fallen. <\/ul>\n
Die wichtigsten Inkompatibilit\u00e4ten im MariaDB 11 Branch: <\/p>\n
\n
Die SUPER-Rechte erlauben nicht mehr die Ausf\u00fchrung von Aktionen, f\u00fcr die separate Privilegien gelten. Beispielsweise sind f\u00fcr die \u00c4nderung des Formats der bin\u00e4ren Logs die Berechtigungen BINLOG ADMIN erforderlich.\n
Die Implementierung des \u00c4nderungs-Puffers in InnoDB wurde entfernt.\n
Die Parameter innodb_flush_method und innodb_file_per_table wurden als veraltet erkl\u00e4rt.\n
Die Unterst\u00fctzung der Namen mysql* wurde als veraltet erkl\u00e4rt.\n
Die Einstellung 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 verschoben.\n
Der Standardwert des Parameters innodb_undo_tablespaces wurde auf 3 ge\u00e4ndert. <\/ul>\n<\/ul>\n