{"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\/nl\/blog\/news\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","title":{"rendered":"Een nieuwe belangrijke tak van de database MariaDB 11 is gepresenteerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Tien jaar na de oprichting van de 10.x tak is de release van de database MariaDB 11.0.0 gepresenteerd, met verschillende belangrijke verbeteringen en veranderingen die de compatibiliteit verstoren. De tak heeft momenteel de kwaliteit van een alfa-versie en zal klaar zijn voor gebruik na stabilisatie. De vorming van de volgende belangrijke tak MariaDB 12, met incompatibele wijzigingen, wordt niet eerder verwacht dan over 10 jaar (in 2032). <\/p>\n
Het MariaDB-project ontwikkelt een afgeleide van MySQL, die zoveel mogelijk de achterwaartse compatibiliteit behoudt en zich onderscheidt door de integratie van extra opslagengines en uitgebreide mogelijkheden. De ontwikkeling van MariaDB wordt beheerd door de onafhankelijke organisatie MariaDB Foundation in overeenstemming met een open en transparant ontwikkelingsproces, los van specifieke leveranciers. De database MariaDB wordt in plaats van MySQL geleverd in veel Linux-distributies (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) en is ge\u00efmplementeerd in grote projecten zoals Wikipedia, Google Cloud SQL en Nimbuzz. <\/p>\n
De belangrijkste verbetering in de tak MariaDB 11 is de overgang van de query-optimalisator naar een nieuw kostenmodel (cost model), dat een nauwkeuriger voorspelling van de gewichten van elk uitvoeringsplan mogelijk maakt. Hoewel het nieuwe model helpt om enkele prestatieknelpunten weg te nemen, is het mogelijk dat het niet optimaal is in alle scenario's en dat sommige queries mogelijk langzamer worden. Gebruikers worden daarom aangeraden deel te nemen aan testen en de ontwikkelaars te informeren in geval van problemen. <\/p>\n
Het eerder gebruikte model was goed geschikt voor het vinden van de optimale index, maar had problemen met de toepasbaarheid van tabelscans, indexscans of range-query's. In het nieuwe model is dit nadeel opgelost door de basiskosten van de opslagmotor operaties te wijzigen. Bij de beoordeling van de prestaties van bewerkingen die afhankelijk zijn van schijf snelheid, zoals sequentieel scannen van records, wordt nu aangenomen dat de gegevens zijn opgeslagen op een SSD, die een leessnelheid van 400MB per seconde biedt. Daarnaast zijn andere gewichten van de optimizer aangepast, wat bijvoorbeeld de mogelijkheid heeft gerealiseerd om indexen te gebruiken voor 'ORDER BY\/GROUP BY' operaties in subqueries en de verwerking van zeer kleine tabellen te versnellen. <\/p>\n
Het wordt opgemerkt dat het nieuwe gewichtmodel een optimaler uitvoeringsplan voor de query zal kiezen in de volgende situaties: <\/p>\n
\n
Bij het gebruik van queries die meer dan 2 tabellen omvatten.\n
Wanneer er indexen zijn die een groot aantal gelijke waarden bevatten.\n
Bij het gebruik van bereikqueries die meer dan 10% van de tabel dekken.\n
Bij complexe queries waarin niet alle gebruikte kolommen zijn ge\u00efndexeerd.\n
Wanneer er queries worden gebruikt die verschillende opslagengines aanspreken (bijvoorbeeld wanneer in \u00e9\u00e9n query wordt verwezen naar tabellen in zowel InnoDB als Memory engines).\n
Bij het gebruik van FORCE INDEX om het queryplan te verbeteren.\n
Bij verslechtering van het query-plan in het geval van gebruik van 'ANALYZE TABLE'.\n
Wanneer de query een groot aantal afgeleide tabellen omvat (een groot aantal geneste SELECTs).\n
Bij het gebruik van ORDER BY of GROUP BY uitdrukkingen die indexeerbaar zijn. <\/ul>\n
Belangrijke compatibiliteitsproblemen in de MariaDB 11-tak: <\/p>\n
\n
SUPER-rechten stellen niet langer in staat om handelingen uit te voeren waarvoor afzonderlijke privileges beschikbaar zijn. Bijvoorbeeld, voor het wijzigen van het formaat van binaire logs zijn BINLOG ADMIN-rechten nodig.\n
De implementatie van de wijzigingsbuffer in InnoDB is verwijderd.\n
innodb_flush_method en innodb_file_per_table zijn als verouderd verklaard.\n
Ondersteuning van namen mysql* is als verouderd verklaard.\n
Het instellen van de parameter explicit_defaults_for_timestamp op 0 is als verouderd verklaard.\n
Symbolische links voor compatibiliteit met MySQL zijn in een apart pakket geplaatst.\n
De standaardwaarde van de parameter innodb_undo_tablespaces is gewijzigd naar 3. <\/ul>\n<\/ul>\n