Met de meeste, zo niet heel 2018 achter ons (afhankelijk van wanneer je dit bericht leest), lijdt het geen twijfel dat het een fantastisch jaar was voor open-source SQL-databases.
PostgreSQL 11 en MySQL 8 zijn beide uitgebracht, waardoor beide gemeenschappen genoeg hebben om 'over te praten '. Eerlijk gezegd hebben beide leveranciers veel belangrijke wijzigingen en toevoegingen in hun respectievelijke releases doorgevoerd en verdienen ze hun lof en lof.
Normaal gesproken post ik over het eerste hier op de blog van Verscheidenenines (Veel dank aan een geweldige organisatie!) maar ik heb ook interesse in het laatste. Met veel blogberichten op mijn eigen website (link in mijn bio-sectie), meestal gericht op MySQL-versie 5.7, staat het (MySQL) altijd in mijn randapparatuur.
Dus wat heeft MySQL 8 dat versie 5.7 niet heeft? Wat zijn de verbeteringen? Nou, dat zijn er veel. Eigenlijk te veel om in één blogpost te behandelen.
Ik heb onlangs een upgrade naar versie 8 uitgevoerd in mijn huidige Linux-leer-/ontwikkelomgeving, dus ik dacht eraan om er een paar aan te wijzen.
Ik kan je geen diepgaande discussie over je 'favoriet . garanderen ' nieuwe functie(s). Aan de andere kant zal ik degenen bezoeken die mijn aandacht hebben getrokken, hetzij via een persoonlijke interesse of via de vele geweldige blogberichten die het hele jaar door op versie 8 zijn gepubliceerd.
MySQL wordt steeds beter... Geweldige verbeteringen in versie 8!
Rollen
Met Rollen kunnen DBA's redundantie verminderen, waarbij veel gebruikers hetzelfde privilege of dezelfde set privileges zouden delen.
Rollen maken deel uit van de SQL-standaard.
Nadat u een specifieke rol met de gewenste/vereiste privileges heeft aangemaakt, kunt u gebruikers die specifieke rol toewijzen via het GRANT-commando of op dezelfde manier, 'neemt weg ' met REVOKE.
Rollen hebben tal van voordelen en om het leven een beetje gemakkelijker te maken, zijn er een aantal tabellen om u te helpen deze bij te houden:
-
mysql.role_edges - Hier vindt u die rollen en de gebruikers die eraan zijn toegewezen.
mysql> DESC mysql.role_edges; +-------------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+---------------+------+-----+---------+-------+ | FROM_HOST | char(60) | NO | PRI | | | | FROM_USER | char(32) | NO | PRI | | | | TO_HOST | char(60) | NO | PRI | | | | TO_USER | char(32) | NO | PRI | | | | WITH_ADMIN_OPTION | enum('N','Y') | NO | | N | | +-------------------+---------------+------+-----+---------+-------+ 5 rows in set (0.01 sec) -
mysql.default_roles - Slaat alle standaardrollen en de toegewezen gebruikers op.
mysql> DESC mysql.default_roles; +-------------------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+----------+------+-----+---------+-------+ | HOST | char(60) | NO | PRI | | | | USER | char(32) | NO | PRI | | | | DEFAULT_ROLE_HOST | char(60) | NO | PRI | % | | | DEFAULT_ROLE_USER | char(32) | NO | PRI | | | +-------------------+----------+------+-----+---------+-------+ 4 rows in set (0.00 sec)
De combinatie van beide tabellen (niet in de betekenis van SQL JOIN) zorgt in wezen voor een 'gecentraliseerde locatie ' waar u kunt:al uw geïmplementeerde relaties en toewijzingen van gebruikersrolprivileges kennen, bewaken en beoordelen.
Waarschijnlijk is het eenvoudigste voorbeeldscenario voor rolgebruik:
U heeft meerdere gebruikers die 'alleen-lezen toegang . nodig hebben ' op een specifieke tabel, waarvoor ten minste het SELECT-privilege vereist is. In plaats van deze aan elke gebruiker afzonderlijk toe te kennen (SELECT), kunt u een rol met dat privilege instellen (maken) en die rol vervolgens aan die gebruikers toewijzen.
Maar rollen hebben een kleine 'catch '. Eenmaal aangemaakt en toegewezen aan een gebruiker, moet de ontvangende gebruiker een actieve standaardrol hebben ingesteld tijdens authenticatie bij het inloggen.
Nu we het toch over rollen en gebruikers hebben, vind ik het belangrijk om de wijziging te vermelden die in MySQL 8 is doorgevoerd met betrekking tot het onderdeel valid_password, een variant van de plug-in valid_password die in versie 5.7 wordt gebruikt.
Deze component biedt verschillende verschillende 'categorieën ' van wachtwoordcontrole:laag, gemiddeld (standaard) en sterk. Bezoek de onderdeeldocumentatie valid_password voor een volledig overzicht van de validatiespecificaties van elk niveau.
NoSQL vermengd met SQL - The Document Store
Deze functie is er een waar ik nog steeds over leer, ondanks een vluchtige interesse in MongoDB begin 2016. Tot op heden zijn mijn interesse, studie en leren uitsluitend gericht geweest op 'SQL'. Ik ben me er echter van bewust (door veel lezen op het web) dat velen enthousiast zijn over dit soort structurering (documentgericht) verweven met 'relationele SQL' die nu beschikbaar is in de MySQL 8-documentopslag.
Hieronder vindt u veel voordelen bij het gebruik van het documentarchief. Zorg ervoor dat je je favorieten vermeldt die ik misschien heb gemist in het opmerkingengedeelte:
- Het JSON-gegevenstype wordt ondersteund sinds MySQL-versie 5.7.8, maar versie 8 introduceerde aanzienlijke verbeteringen voor het werken met JSON. Nieuwe JSON-specifieke functies samen met 'steno ' operators die kunnen worden gebruikt in plaats van meerdere functie-aanroepen - met gelijke resultaten/uitvoer.
- Misschien is een van de belangrijkste voordelen dat u niet langer meerdere database-oplossingen hoeft te implementeren en ermee te werken, aangezien NoSQL, SQL of een combinatie van beide worden ondersteund in het documentarchief.
- Een "DevAPI" biedt naadloze workflowmogelijkheden binnen een NoSQL-gegevenscontext (verzamelingen en documenten). (Bezoek de officiële documentatie van de DevAPI-gebruikershandleiding voor meer informatie).
- Krachtige opdrachtregelsessies met Python, SQL of Javascript als de 'shell'-taal.
- ACID-compatibel.
- Verken en ontdek snel uw gegevens zonder een schema te definiëren zoals u zou doen in een relationeel model.
Veelgebruikte tabeluitdrukkingen (CTE's of de WITH-clausule)
Wat kun je nog meer zeggen over CTE's? Deze dingen zijn een game-changer! Om te beginnen, wat is precies een algemene tabeluitdrukking?
Van Wikipedia:
"Een algemene tabelexpressie, of CTE, (in SQL) is een tijdelijke benoemde resultatenset, afgeleid van een eenvoudige query en gedefinieerd binnen het uitvoeringsbereik van een SELECT-, INSERT-, UPDATE- of DELETE-instructie."
Ik zal een eenvoudig voorbeeld geven om CTE's te demonstreren. Hun volledige kracht wordt echter niet benut in deze sectie, omdat er veel complexere use-case voorbeelden zijn dan deze.
Ik heb een eenvoudige naamtabel met deze beschrijving en gegevens:
mysql> DESC name;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| f_name | varchar(20) | YES | | NULL | |
| l_name | varchar(20) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name |
+--------+------------+
| Jim | Dandy |
| Johhny | Applesauce |
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+------------+
5 rows in set (0.00 sec)Laten we eens kijken hoeveel achternamen beginnen met 'Z':
mysql> SELECT *
-> FROM name
-> WHERE l_name LIKE 'Z%';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Makkelijk genoeg.
Als u echter de WITH-component gebruikt, kunt u 'toegang' ' dezelfde set met queryresultaten (die kan worden beschouwd als een afgeleide tabel) en er later naar verwijzen in dezelfde instructie - of 'scope ':
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT * FROM last_Z;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Ik wijs in feite een naam toe aan de query en wikkel deze tussen haakjes. Selecteer vervolgens de gegevens die ik wil van wat nu de laatste_Z CTE is.
De last_Z CTE biedt een complete resultatenset, zodat u deze nog verder kunt filteren binnen dezelfde instructie:
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT f_name, l_name FROM last_Z WHERE l_name LIKE '%a';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)Een paar van de krachtigere functies zijn 'ketenen ' meerdere CTE's samen en verwijzend naar andere CTE's binnen CTE's.
Hier is een voorbeeld om je een idee te geven (hoewel niet zo handig):
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%'),
best_friend AS (
SELECT f_name, l_name
FROM last_Z
WHERE l_name LIKE '%a')
SELECT * from best_friend;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)In de bovenstaande query kun je zien waar ik de last_Z CTE van de best_friend CTE heb gescheiden met een komma en die query vervolgens tussen haakjes heb geplaatst na het AS-trefwoord.
Merk op dat ik dan kan verwijzen naar (en gebruik) de last_Z CTE om in wezen de best_friend CTE te definiëren.
Hier zijn een paar redenen waarom CTE's zo'n significante verbetering zijn in versie 8:
- Andere SQL-leveranciers hebben CTE's ondersteund (veel sinds eerdere versies binnen hun individuele ecosysteem) en nu heeft MySQL 8 de kloof op dit gebied gedicht.
- Een standaard SQL-opname.
- In sommige gevallen (waar van toepassing) zijn CTE's een betere optie dan tijdelijke tabellen, weergaven, afgeleide tabellen (of inline weergaven) en sommige subquery's.
- CTE's kunnen een 'on-the-fly 'berekeningsresultaten die u kunt opvragen.
- Een CTE kan naar zichzelf verwijzen - ook wel een recursieve CTE genoemd (hier niet gedemonstreerd).
- CTE's kunnen andere CTE's benoemen en gebruiken
Vensterfuncties
Analytische query's zijn nu mogelijk in MySQL 8. Omdat Window-functies niet mijn sterkste punt zijn, ben ik gefocust op een meer diepgaande studie en een beter begrip ervan, in het algemeen, om vooruit te komen. Deze volgende voorbeeld (en) zijn meestal elementair volgens mijn begrip. Suggesties, advies en best practices zijn welkom van lezers.
Ik heb deze VIEW die een fictieve resultatenset met pijpgegevens biedt (iets dat ik enigszins begrijp):
mysql> SELECT * FROM pipe_vw;
+---------+-------------+-----------+-------+-------------+------------+----------------+
| pipe_id | pipe_name | joint_num | heat | pipe_length | has_degree | wall_thickness |
+---------+-------------+-----------+-------+-------------+------------+----------------+
| 181 | Joint-278 | 39393A | 9111 | 17.40 | 1 | 0.393 |
| 182 | Joint-8819 | 19393Y | 9011 | 16.60 | 0 | 0.427 |
| 183 | Joint-9844 | 39393V | 8171 | 10.40 | 0 | 0.393 |
| 184 | Joint-2528 | 34493U | 9100 | 11.50 | 1 | 0.427 |
| 185 | Joint-889 | 18393z | 9159 | 13.00 | 0 | 0.893 |
| 186 | Joint-98434 | 19293Q | 8174 | 9.13 | 0 | 0.893 |
| 187 | Joint-78344 | 17QTT | 179 | 44.40 | 1 | 0.893 |
| 188 | Joint-171C | 34493U | 17122 | 9.45 | 1 | 0.893 |
| 189 | Joint-68444 | 17297Q | 6114 | 11.34 | 0 | 0.893 |
| 190 | Joint-4841R | 19395Q | 5144 | 25.55 | 0 | 0.115 |
| 191 | Joint-1224C | 34493U | 8575B | 15.22 | 1 | 0.893 |
| 192 | Joint-2138 | 34493C | 91 | 13.55 | 1 | 0.893 |
| 193 | Joint-122B | 34493U | 9100B | 7.78 | 1 | 0.893 |
+---------+-------------+-----------+-------+-------------+------------+----------------+
13 rows in set (0.00 sec)Stel je voor, ik heb de pijpactivarecords nodig die worden gepresenteerd in een soort rijrangschikking, afhankelijk van de lengte van elke individuele pijp. (Bijvoorbeeld:de langste lengte is 'gelabeld' met positie nummer 1, de op een na langste lengte is 'gelabeld' met positie 2, enz...)
Gebaseerd op de RANK() Window Functiebeschrijving in de documentatie:
"Retourneert de rangorde van de huidige rij binnen zijn partitie, met gaten. Peers worden beschouwd als gelijken en krijgen dezelfde rangorde. Deze functie wijst geen opeenvolgende rangschikkingen toe aan peergroepen als er groepen van groter dan één bestaan; het resultaat is niet-aangrenzende rangnummers ."
Het lijkt geschikt voor deze eis.
mysql> SELECT pipe_name, pipe_length,
-> RANK() OVER(ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+---------------+
| pipe_name | pipe_length | long_to_short |
+-------------+-------------+---------------+
| Joint-78344 | 44.40 | 1 |
| Joint-4841R | 25.55 | 2 |
| Joint-278 | 17.40 | 3 |
| Joint-8819 | 16.60 | 4 |
| Joint-1224C | 15.22 | 5 |
| Joint-2138 | 13.55 | 6 |
| Joint-889 | 13.00 | 7 |
| Joint-2528 | 11.50 | 8 |
| Joint-68444 | 11.34 | 9 |
| Joint-9844 | 10.40 | 10 |
| Joint-171C | 9.45 | 11 |
| Joint-98434 | 9.13 | 12 |
| Joint-122B | 7.78 | 13 |
+-------------+-------------+---------------+
13 rows in set (0.01 sec)In het volgende scenario wil ik nog verder bouwen op het vorige voorbeeld door de records van langste naar kortste lengte te rangschikken, maar per individuele groep van de verschillende wall_thickness-waarden.
Misschien zullen de onderstaande zoekopdracht en resultaten beter uitleggen waar mijn proza niet heeft:
mysql> SELECT pipe_name, pipe_length, wall_thickness,
-> RANK() OVER(PARTITION BY wall_thickness ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+----------------+---------------+
| pipe_name | pipe_length | wall_thickness | long_to_short |
+-------------+-------------+----------------+---------------+
| Joint-4841R | 25.55 | 0.115 | 1 |
| Joint-278 | 17.40 | 0.393 | 1 |
| Joint-9844 | 10.40 | 0.393 | 2 |
| Joint-8819 | 16.60 | 0.427 | 1 |
| Joint-2528 | 11.50 | 0.427 | 2 |
| Joint-78344 | 44.40 | 0.893 | 1 |
| Joint-1224C | 15.22 | 0.893 | 2 |
| Joint-2138 | 13.55 | 0.893 | 3 |
| Joint-889 | 13.00 | 0.893 | 4 |
| Joint-68444 | 11.34 | 0.893 | 5 |
| Joint-171C | 9.45 | 0.893 | 6 |
| Joint-98434 | 9.13 | 0.893 | 7 |
| Joint-122B | 7.78 | 0.893 | 8 |
+-------------+-------------+----------------+---------------+
13 rows in set (0.00 sec)Deze query gebruikt de clausule PARTITION BY in de kolom wall_thickness omdat we de rangschikking willen (die ORDER BY pipe_length DESC biedt), maar we hebben deze nodig in de context van de individuele wall_thickness-groepen.
Elke lange_naar_korte kolomrangschikking wordt teruggezet naar 1 wanneer u een andere kolomwaarde tegenkomt (of verandert) naar een andere muurdikte.
Laten we ons concentreren op de resultaten van één enkele groep.
Gericht op de records met wall_thickness-waarden 0.893, heeft de rij met pipe_length 44.40 een corresponderende long_to_short 'ranking' van 1 (het is de langste), terwijl de rij met pipe_length 7.78 een corresponderende long_to_short 'ranking' van 8 (de kortste) heeft, allemaal daarbinnen specifieke groep (0,893) van wall_thickness-waarden.
Vensterfuncties zijn behoorlijk krachtig en hun volledige reikwijdte en reikwijdte zou onmogelijk in één sectie kunnen worden behandeld. Zorg ervoor dat en bezoek de vensterfuncties die worden ondersteund in de MySQL 8-documentatie voor meer informatie over de momenteel beschikbare.
Verbeterde ruimtelijke ondersteuning en mogelijkheden
Dit is een geweldige reeks functies die zijn opgenomen in MySQL 8. De ondersteuning van eerdere versies, of het ontbreken daarvan, was gewoon niet te vergelijken met implementatie(s) van andere leveranciers (denk aan PostGIS voor PostgreSQL).
De afgelopen 10 jaar heb ik in het veld gewerkt als Pipeline Surveyor, waarbij ik GPS- en activagegevens verzamelde, dus deze groep veranderingen trekt zeker mijn aandacht.
Expertise op het gebied van ruimtelijke data is een veelomvattend onderwerp op zich en wees gerust, ik ben er verre van een expert in. Ik hoop echter de belangrijke wijzigingen tussen versie 5.7 en 8 samen te vatten en op een duidelijke en beknopte manier over te brengen.
Laten we ons vertrouwd maken met 2 sleuteltermen (en concepten) voor de doeleinden van deze sectie.
-
Spatial Reference System of SRS - Hier is een gedeeltelijke definitie van Wikipedia:
"Een ruimtelijk referentiesysteem (SRS) of coördinatenreferentiesysteem (CRS) is een op coördinaten gebaseerd lokaal, regionaal of mondiaal systeem dat wordt gebruikt om geografische entiteiten te lokaliseren. Een ruimtelijk referentiesysteem definieert een specifieke kaartprojectie, evenals transformaties tussen verschillende ruimtelijke referentiesystemen systemen."
-
Spatial Reference System Identifier of SRID - Wikipedia heeft SRID's ook als zodanig gedefinieerd:
"Een Spatial Reference System Identifier (SRID) is een unieke waarde die wordt gebruikt om geprojecteerde, niet-geprojecteerde en lokale ruimtelijke coördinatensysteemdefinities ondubbelzinnig te identificeren. Deze coördinatensystemen vormen het hart van alle GIS-toepassingen."
MySQL ondersteunt veel typen ruimtelijke gegevens. Een van de meest voorkomende is een PUNT. Als je je GPS gebruikt om naar je favoriete restaurant te navigeren, dan is die locatie een PUNT op een kaart.
MySQL 5.7 behandelt vrijwel elk 'ruimtelijk object ' met een SRID van 0, wat belangrijk is voor berekeningen. Die berekeningen worden berekend in een cartesiaans coördinatensysteem. We weten echter allemaal dat onze aardbol een bol is en verre van plat. Daarom heb je in versie 8 de mogelijkheid om het in berekeningen als plat of bolvormig te beschouwen.
Terug naar die twee termen die we eerder hebben gedefinieerd.
Hoewel 0 de standaard SRID is in MySQL versie 8, worden veel (ongeveer 5.000+) andere SRID's ondersteund.
Maar waarom is dat belangrijk?
Deze fantastische uitleg via de blogpost Spatial Reference Systems in MySQL 8.0 vat het mooi samen:
"Standaard, als we geen SRID specificeren, zal MySQL geometrieën creëren in SRID 0. SRID 0 is MySQL's notie van een abstract, unitless, oneindig Catesiaans vlak. Terwijl alle andere SRS's verwijzen naar een oppervlak en eenheden definiëren voor de assen, SRID 0 niet."
In wezen, bij het uitvoeren van berekeningen met SRID's anders dan SRID 0 , dan komt de vorm van onze aarde in het spel, wordt overwogen en beïnvloedt die berekeningen. Dit is cruciaal voor zinvolle/nauwkeurige berekeningen. Voor een diepgaand overzicht en betere extrapolatie, zie deze blogpost over geografie in MySQL 8.
Ik raad ook ten zeerste de MySQL Server Team-blogpost, Geographic Spatial Reference Systems in MySQL 8.0, aan voor duidelijkheid over SRS's. Zorg ervoor dat je het leest!
Tot slot, voor problemen met het upgraden van ruimtelijke gegevens van versie 5.7 naar 8, gaat u naar enkele van de incompatibele wijzigingen die hier worden vermeld voor meer informatie.
Andere opmerkelijke waarnemingen
Hieronder staan andere releaseverbeteringen die ik moet erkennen, hoewel ze niet diepgaand worden behandeld in deze blogpost:
- utf8mb4 is nu de standaard tekenset (voorheen latin1) - Betere ondersteuning voor degenen die emoji's moeten hebben naast sommige talen...
- Transactional Data Dictionary - MySQL-metadata is nu ondergebracht in InnoDB-tabellen.
- Onzichtbare indexen - Stel de zichtbaarheid van een index in voor de optimizer en bepaal uiteindelijk of het toevoegen of verwijderen ervan (de index) een goede of slechte zaak is. Het toevoegen van een index aan een bestaande grote tabel kan 'duur zijn ' in termen van vergrendeling en bronnen.
- Aflopende indexen - Betere prestaties op geïndexeerde waarden die in aflopende volgorde worden opgeslagen.
- Kolom direct toevoegen - Geef voor schemawijzigingen ALGORITHM=INSTANT op in ALTER TABLE-instructies en vermijd (indien mogelijk voor de bewerking) metagegevensvergrendelingen. (Zie voor meer informatie dit geweldige bericht van het MySQL Server Team en de ALTER TABLE-sectie van de officiële documenten.)
Bonussectie:iets wat ik had gehoopt te zien...
Gerelateerde bronnen ClusterControl voor MySQL Word een MySQL DBA-blogserie - Algemene bewerkingen - Wijzigingen in de replicatietopologie Word een MySQL DBA-blogserie - Database-upgradesControlebeperkingen zijn nog niet doorgedrongen in het MySQL-product.
Net als bij eerdere MySQL-versies, is de syntaxis van de controlebeperking toegestaan in uw CREATE TABLE-opdrachten, maar wordt deze genegeerd. Voor zover ik weet, ondersteunen de meeste andere SQL-leveranciers controlebeperkingen. Kom naar het feest MySQL!
MySQL is aanzienlijk 'opgevoerd ' het aanbod in versie 8. De ondersteuning van robuuste ruimtelijke mogelijkheden, handige rolopties voor gebruikersbeheer, 'hybride' SQL/NoSQL-gegevensoplossingen en analytische functies naast de vele aanvullende verbeteringen, is echt opmerkelijk.
Naar mijn mening blijft MySQL met versie 8 een solide optie bieden in het steeds groter wordende, concurrerende open-source SQL-ecosysteem, vol met relevante en veelzijdige oplossingen.
Bedankt voor het lezen.