MySQL à Oracle OpenWorld 2016

octobre 5, 2016

Du 18 au 22 septembre 2016 c’est déroulé l’Oracle OpenWorld, un ensemble de conférences parlant des technologies Oracle.

Bien entendu, MySQL était au programme, voici un petit résumé des annonces.

MySQL dans le cloud

MySQL, la base de données open source la plus populaire au monde a enfin son cloud officiel avec Oracle MySQL Cloud Service.

Parmi les principaux points :

  • Dernière version GA de MySQL (5.7) en version Enterprise.
  • Support technique réalisé par les équipes d’Oracle MySQL (en lien direct avec les devs)

Pour l’essayer : https://cloud.oracle.com/mysql

Plus d’infos:

MySQL Cloud Service Deep Dive from Morgan Tocker

 

MySQL HA

MySQL Group Replication est en RC, en clair la prochaine version sera la première GA.

MySQL Group Replication est la solution native MySQL pour faire de la haute disponibilité. C’est un plugin pour MySQL qui permet un mode de réplication virtuellement synchrone, avec detection et résolution des transactions (éventuellement) en conflit pour des architectures multi-master.

Plus d’infos:

 

 

Cependant, la grosse sensation a été l’annonce de la version Release Candidate de MySQL InnoDB Cluster !

 

MySQL InnoDB Cluster permet de faciliter le déploiement de solutions de haute disponibilité basées sur MySQL Group Replication.

Concrètement, avec l’aide du MySQL Shell il devient alors possible de mettre en oeuvre facilement un cluster MySQL Group Replication avec des instances de  MySQL Router en frontal.

Pour avoir une explication encore plus simple, regardez la demo de Fred et un tutorial.

Plus d’infos:

MySQL High Availability — InnoDB Clusters from Matt Lord

 

MySQL 8.0.0. DMR

La prochaine GA de MySQL sera la 8.

On passe donc de 5 (5.7) à 8… pourquoi ? Tout simplement parce que MySQL 6 a déjà existé (en 2007 puis abandonné).

Et pas 7 non plus car MySQL Cluster est en version 7 (7.4) actuellement. Du coup le premier chiffre de libre pour unifier les 2 solutions est le… 8 !  CQFD 🙂

MySQL 8.0.0 est une DMR, c’est donc la branche de développement. En clair à ne pas utiliser en production. Par contre je vous encourage à la télécharger (code source dispo également sur GitHub ou si vous préférez une image Docker ) et à tester les nouvelles fonctionnalités.

Au programme de cette version 8:

  • Common Table Expressions  (CTE) une sorte de table temporaire associée à une requête qui permet à l’aide de la commande WITH d’exprimer la récursivité (mais pas seulement). A noter qu’il est cependant possible d’émuler WITH RECURSIVE avec MySQL et ce sans attendre la 8, lire cet article de Guilhem.
  • Invisible indexes : index maintenu par l’optimiseur mais pas utilisé. Permet de tester le comportement du serveur lors de l’évaluation de la pertinence ou non d’un index.
  • Persisting configuration variables, la possibilité de rendre persistant les changements de configuration serveur fait en ligne.
  • Les roles : faciliter la gestion des utilisateurs
  • La base de données est en UTF-8 par défaut
  • et plein d’autres choses…

Plus d’infos:

Autres annonces

La version 3.3 de MySQL Enterprise Monitor (MEM) : outil de gestion et de supervision des bases MySQL. Cette version intègre un tout nouveau tableau de bord dédié à la sauvegarde. MEM 3.3 permet donc un intégration très fine avec MySQL Enterprise Backup notre outil de sauvegarde physique à chaud.
Group Backup Overview

 

MySQL Cluster 7.5 notre base de données distribuée en mémoire est en RC.

 

Videos

 

Présentations

Les présentations sont disponibles sur le site d’OOW.

 

Thank you for using MySQL!

0

Retour sur le meetup – MySQL Group Replication & MySQL as a Document Store

septembre 7, 2016

Ce mardi 6 septembre, un superbe meetup MySQL  c’est déroulé à Paris dans les locaux d’ Executive MBA Epitech  à Paris. Organisé et sponsorisé par  Oracle MySQL et Openska.

Un grand merci à tous les participants, aux organisateurs et au sponsor (Oracle).

Merci également à Frédéric (EMEA MySQL Community Manager) et à Dimitri (MySQL Performance Architect).

Les présentations de la soirée:

MySQL Group Replication – Haute Disponibilité avec Multi-Masters

de Frédéric Descamps

 

MySQL 5.7 & JSON – Nouvelles Opportunités pour les Développeurs

de Frédéric Descamps

 

Vous pouvez également les récupérer le blog de Frédéric.

 

Pour aller plus loin

MySQL Group Replication

 

MySQL as a Document Store

 

Et encore beaucoup de bonnes choses à venir 🙂 alors restez à l’écoute !

 

En bonus quelques photos:

https://plus.google.com/photos/114583255370443901762/albums/6327640843829307985

 

Thank you for using MySQL!

 

 

1

Meetup – MySQL Group Replication & MySQL as a Document Store

août 29, 2016

Oracle MySQL, Openska et Executive MBA Epitech ont le plaisir de vous inviter le mardi 6 septembre pour le premier meetup MySQL de la rentrée.

Au programme… du lourd, rien que du lourd 🙂

 

MySQL Group Replication: Haute Disponibilité avec Multi-Masters

Vous souhaitez avoir une architecture de base de données distribuée et hautement disponible ?
MySQL Group Replication est un plugin pour MySQL 5.7 qui fournit de la réplication (virtuellement) synchrone avec detection et gestion de conflits intégré. Ce plugin permet de passer facilement d’une architecture mono-serveur à une architecture distribuée multi-maîtres hautement disponible.

Venez découvrir les concepts ainsi que la meilleure façon de déployer une telle architecture.
http://mysqlhighavailability.com/mysql-group-replication-a-quick-start-guide/

 

Using MySQL as a Document Store: JSON Datatype & NoSQL

Faire du SQL et du NoSQL avec la même base de données est-ce possible ?
La réponse est oui avec MySQL!!!
A partir de MySQL 5.7.12, vous pouvez utiliser MySQL comme un « Document Store » (Un document est un ensemble de paires (clé/valeur) stocké par MySQL dans un format JSON binaire). Et cerise sur le gateau, les attributs du document JSON peuvent être indexés.
De plus, en utilisant le tout nouveau X DevAPI, il est également possible de gérer ces documents via une interface CRUD ou un interface SQL traditionnelle.
https://dev.mysql.com/doc/refman/5.7/en/document-store.html

 

Intervenants:

Frederic Descamps : EMEA MySQL Community Manager

Olivier Dasini : MySQL Principal Solutions Architect EMEA

 

Informations et inscription:
http://www.meetup.com/OpenTech/events/232136370/

 

Update {7 septembre 2016}

Présentation et autres infos

1

Oracle MySQL Tech Tour mai 2016

avril 27, 2016

Le 10 Mai 2016, l’Oracle MySQL Tech Tour passe par Paris !
Venez rencontrer l’équipe MySQL France et discuter des nouveautés de MySQL 5.7 comme :

et bien d’autres choses.

 

Pour vous inscrire et connaitre le programme complet Cliquer sur le lien ci-dessous :

https://eventreg.oracle.com/profile/web/index.cfm?PKWebId=0x3469984798

 

Oracle MySQL Tech Tour

Date : mardi 10 mai 2016

Lieu : Remix Coworking – 24 cour des Petites Ecuries 75010

Horaire : 14:00 – 17:15

Entrée libre

 

0

MySQL en tant que Document Store

avril 21, 2016
Tags: , ,

A partir de MySQL 5.7.12, la nouvelle version de la base de données la plus populaire permet aux devs et aux DBAs de déployer des bases MySQL qui implémentent un modèle document store, relationnel ou hybride (document ET relationnel) !
Plus d’info: http://dev.mysql.com/doc/refman/5.7/en/document-store.html

0

30 mins avec MySQL Query Rewriter

mars 2, 2016

Read this post in English

TL;TR

Parfois des requêtes problématiques tournent sur le serveur, mais il n’est pas possible de régler le problème à la source (requêtes venant d’un ORM par example )

MySQL 5.7 fournit :

  • Une API pre et post parse query rewrite
    • Les utilisateurs peuvent écrire leurs propre plugins
    • Permet d’éliminer le besoin d’un proxy
  • Avec le post-parse query plugin, il est possible :
    • De réécrire une requête problématique sans faire de changement au niveau de l’application
    • Ajouter des hints pour les index ou pour l’optimiseur
    • Modifier l’ordre des jointures

 

API du Plugin Query Rewrite

Pour citer cet article du MySQL Server Blog :

 »

MySQL now offer two APIs for writing query rewrite plugins.

Pre-parse rewrite plugin API,  is for when you know exactly – as in character-by-character exactly – what the offending queries look like. This one has a hook to intercept the query string right before it’s parsed.

Post-parse rewrite plugin API, comes in right after parsing and acts on the parse tree. It offers the basic functionality to walk over the parsed query, which is a lot more efficient than dealing with a string.

 »

Cet article traite du sujet Rewriter plugin, un post-parse query rewrite plugin, inclus dans la distribution MySQL 5.7 (à partir de la version MySQL 5.7.6).

 

Le plugin Rewriter

Installation et vérifications

La simplicité fait partie de la philosophie MySQL, l’installation du plugin n’y déroge pas.

Pour installer le plugin Rewriter, il faut lancer le script install_rewriter.sql localisé dans le répertoire share de votre installation MySQL.

Pour vérifier:

De nouveaux objets ont été créés

La table rewrite_rules du schéma query_rewrite fournie un stockage persistent des règles que le plugin Rewriter utilise pour décider quelles requêtes réécrire.

Le plugin peut être activé ou désactivé à chaud :

Il est également possible de l’activer par l’intermédiaire du fichier de configuration (my.cnf | my.ini)

 

Réécrire une requête

Le plugin post-parse rewrite ne fonctionne qu’avec les requêtes SELECT.

Toutes requêtes autres que SELECT génèrent lors du flush des règles, dans la colonne de la table rewrite_rules.message le message d’erreur suivant:

 

Le plugin Rewriter est facile à utiliser. Commençons par un exemple simple (voir simpliste) histoire de se faire la main. Transformons un SELECT n en un SELECT n+1 (n étant un entier).

Patterns

 -> SELECT 1      # Input

 <= SELECT 2    # Output

Ajouter la règle de réécriture

Pour ajouter une règle dans le plugin Rewriter, il faut ajouter des enregistrements dans la table rewrite_rules.

Le contenu de la table rewrite_rules est:

Les stats du Rewriter montrent:

 

Flusher la règle de réécriture

Ensuite il faut appeler la procédure stockée flush_rewrite_rules() pour charger les règles dans le plugin.

Lorsque le plugin charge les règles, il génère, entre autres, une forme normalisée de la requête ainsi qu’une valeur hash:

Le ? agit comme un ‘marqueur’ qui correspond aux données de la requête. Il ne peut être utilisé que pour les données, pas pour les mots clés SQL, ni les identifieurs,…  De plus le ? ne doit pas être entre guillemets ou apostrophes.

Si le parsing de la requête échoue, la procédure stockée va générée une erreur:

Vous trouverez plus de détails dans la colonne query_rewrite.rewrite_rules.message.

Exemple

Les stats du Rewriter montrent:

 

Requête réécrite

Petit état des lieux. Nous avons, ajouté, puis flushé la règle.  On peut donc maintenant exécuter une requête qui correspond au pattern et voir le résultat…

Magique !!!

La requête à été réécrite « à la volée ». Cependant, quelques détails intéressants sont cachés dans le warning.

 

Les stats du Rewriter ont été mis à jour en conséquence:

Pour désactiver une règle existante, il suffit de modifier la colonne enabled et recharger la table dans le plugin:

En passant il est possible de supprimer les enregistrements de la table:

OK!  maintenant que le concept est compris, voyons des exemples plus pertinents.

 

Exemples de réécritures avec Rewriter

Ex 1

Réécrire un jointure en sous-requête; Pour des raisons de performance, la requête doit être réécrite mais vous n’avez pas accès au coté applicatif.

Patterns

 -> SELECT count(distinct emp_no) FROM employees.employees INNER JOIN employees.salaries USING(emp_no) WHERE DATEDIFF(to_date, from_date) < {integer};

 <= SELECT count(emp_no) FROM employees.employees WHERE emp_no IN ( SELECT emp_no FROM employees.salaries WHERE DATEDIFF(to_date, from_date) < {integer});

Sans la règle

Ajout de la règle de réécriture

Avec la règle

Le temps d’exécution de la requête est passé de 12.93 à 3.77 secondes

Remarque

Il y a quelques années, j’ai écris cet article Jointure vs sous-requête où je compare les temps d’exécution d’un jointure et de son équivalent en sous-requête. L’optimiseur s’est bien amélioré depuis la version 5.5.

 

Ex 2

Borner le temps d’exécution maximum d’une requête; ie ajouter le hint MySQL 5.7  /*+ MAX_EXECUTION_TIME(X)*/ c’est à dire que le temps d’exécution de la requête ne pourra exeder X millisecondes.

Patterns

 -> SELECT count(distinct emp_no) FROM employees.employees INNER JOIN employees.salaries USING(emp_no) WHERE salary = {integer};

 <= SELECT /*+ MAX_EXECUTION_TIME(10000)*/ count(distinct emp_no) FROM employees.employees INNER JOIN employees.salaries USING(emp_no) WHERE salary = {integer};

Sans la règle

Ajout de la règle de réécriture

Avec la règle

 

Ex 3

Evolution du schema de la base après une MEP; ie Une colonne est ajoutée (ou supprimée) mais vous ne pouvez pas modifier la/les requête(s) qui utilise(nt) cette table.

Patterns

 -> SELECT first_name, last_name FROM employees.employees WHERE year(hire_date) = 2000;

 <= SELECT first_name, last_name, birth_date FROM employees.employees WHERE year(hire_date) = 2000;

Sans la règle

Ajout de la règle de réécriture

Avec la règle

 

D’autres idées ?

– Index hints : l’optimiseur n’utilisant pas le bon index, vous pouvez réécrire la requête en ajoutant les mots clés [USE | FORCE | IGNORE] INDEX

– Limiter la taille du résultat d’un SELECT, vous pouvez réécrire la requête en ajoutant la clause LIMIT 1000 (ou plus, ou moins).

En fait cela simule l’option –safe-update du client text mysql

Sky is the limit 🙂 donc à vous de jouer maintenant !

A noter que le plugin Rewriter ne remplace pas un code optimal et des requêtes correctement optimisées à la source…

Cependant, ce plugin peut vraiment être utile lorsque l’accès à la source est compliqué voir impossible.

Il est disponible dans MySQL 5.7 qui est vraiment une superbe version ! Essayer le plugin Rewriter il mérite définitivement plus de 30 minutes.

 

 

Pour aller plus loin

Post-parse query rewrite plugin

Pre-parse query rewrite plugin

 

Thank you for using MySQL!

 

 

0

JSON et colonnes générées avec MySQL

novembre 30, 2015

JSON

Le 24 novembre dernier, lors du Forum PHP, Tomas Ulin (Oracle’s MySQL VP of Engineering) a parlé de l’utilisation de JSON dans MySQL « MySQL 5.7 & JSON: New opportunities for developers« .

 

Voici les réponses à quelques questions qui m’ont été posées:

  • Comment se comporte mysqldump avec les colonnes générées ?
  • Comment utiliser la commande LOAD DATA INFILE avec des colonnes générées ?
  • JSON est il sensible à la casse dans MySQL ?

 

Le contexte, une table InnoDB catalog qui contient un champs doc de type JSON ainsi que des colonnes générées virtuelles isbn & publisher:

Quelques documents JSON :

à insérer dans la table catalog:

La table catalog contient donc 3 enregistrements:

 

Sauvegarder et restaurer une table contenant  des colonnes générées

Q: Comment se comporte mysqldump avec les colonnes générées ?

 

Faire une sauvegardes des données avec mysqldump, le résultat étant redirigé vers le fichier test.catalog.sql :

En visualisant le dump on s’appercoit que:

  • Les colonnes générées sont bien présentent dans la structure de la table.
  • La commande INSERT ne renseigne que les colonnes « classiques » id et doc

Avant de restaurer le dump dans la table, je vais la vider:

La table ne contient plus de donnée:

Chargement des données dans la table:

Ta damm!!!
La table a bien été restaurée, les colonnes générées virtuelles sont, comme convenu, recalculées à la volée.

 

Importer un fichier texte dans une table avec des colonnes générées

Q: Comment utiliser la commande LOAD DATA INFILE avec des colonnes générées ?

L’export des données se fait avec SELECT … INTO OUTFILE:

Avant d’importer le fichier texte dans la table, je vais la vider:

Import des données dans la table:

L’import de fichiers, avec la commande LOAD DATA INFILE, dans une table qui contient des colonnes générées ne diffère en rien de l’import dans une table sans colonne générée.

 

Sensibilité à la casse du contenu JSON

Q: JSON est il sensible à la casse dans MySQL ?

 

Rechercher tous les documents où l’éditeur est ENI (en majuscule):

Rechercher tous les documents où l’éditeur est eni (en minuscule):

Les documents JSON sont donc sensible à la casse.

 

Il est évidemment possible d’utiliser une fonction pour modifier la casse:

Cependant 2 contraintes:
– Si la colonne est indexée ce dernier ne pourra pas être utilisé.
– Ça fonctionne si et seulement si le mot est écrit dans la base entièrement en majuscule.

Une meilleure solution consiste à créer et a indexer une colonne générée qui contient les données en minuscule.

La colonne générée contient les directives suivantes:

  • LOWER : transformer en minuscules les chaines de caractères
  • JSON_UNQUOTE : supprimer les guillemets
  • VIRTUAL : la colonne générée est virtuelle. Les données ne sont pas stockées mais calculées à la volée.

 

La structure de la tables est maintenant:

La colonne publisher_lower contient la version tout en minuscule des données de la colonne publisher.

Ajout de l’index:

Nouvelle structure de table:

Maintenant les données étant stockées dans une collation non sensible à la casse (utf8_general_ci) la requête n’est plus sensible à la casse:

La commande EXPLAIN confirme que l’index est vu et utilisé:

En fait on vient d’implémenter un index sur une fonction (functional index).

Vous voulez en savoir plus sur MySQL 5.7 ?
Rejoignez nous sur l’Oracle MySQL Tech Tour Paris le 8 décember 2015.

Infos & inscriptions

Note: cet article vient en complément de l’article 30 mins avec JSON en MySQL

Je vous invite également à consulter:

BGOUG15: JSON support in MySQL 5.7 from Georgi Kodinov

 

 

 

1

30 mins avec JSON en MySQL

novembre 17, 2015

Read this post in English

Note: Cet article est inspiré de la présentation MySQL 5.7 + JSON de Morgan Tocker.

Comme vous le savez MySQL 5.7 est GA. Cette nouvelle mouture de la base de données open source la plus populaire au monde a plus de 150 nouvelles fonctionnalités. L’une d’entre elle est un type de données JSON natif ainsi que les fonctions JSON associées.

Prenons 30 minutes pour voir ce que cela donne…

 

Récupérer des documents JSON

Commençons pas récupérer des données au format JSON. Mirco Zeiss fournit un gros fichier JSON qui représente San Francisco (SF Open Data) : https://github.com/zemirco/sf-city-lots-json

Pour pouvoir manipuler ces données avec MySQL, quelques modifications sont nécessaires:

Ça à l’air bon !

Note: La taille des documents JSON stockés dans une colonne de type JSON est limitée par la valeur de la variable système max_allowed_packet. (Cette limitation ne s’applique que lorsque le serveur stocke les documents. En mémoire la taille des document peut donc être supérieure).

 

Notre document JSON sera stocké dans la table InnoDB features:

Une autre façon de stocker des documents JSON est de les mettre dans une colonne de type VARCHAR ou TEXT.

La table features_TEXT va nous permettre de comparer les performances des types JSON et TEXT.

Note: Dans cet exemple le type TEXT n’est pas suffisamment large pour géré nos données JSON . (ERROR 1406 (22001): Data too long for column ‘feature’ at row 17360). LONGTEXT fera donc l’affaire.

 

Insertion des données dans les tables

Note: Le temps d’exécution d’une même requête pouvant varier largement d’une exécution à l’autre, sur mon (vieux) portable avec une petite configuration pour MySQL (e.g. Buffer pool = 128Mo). J’ai donc exécuté les requêtes plusieurs fois en utilisant mysqlslap:

mysqlslap -c1 -i <N> { Concurrence = 1 / Itération > 20 (en fonction de la durée totale de la requête) }.

Le temps d’exécution sera donc représenté la plupart du temps sous la forme: « Minimum number of seconds to run all queries: 59.392 seconds » au lieu de « Query OK, 206560 rows affected (59.39 sec) ».

 

Copier les données JSON dans la table features

Minimum number of seconds to run all queries: 59.392 seconds

Copier les données JSON dans la table features_TEXT

Minimum number of seconds to run all queries: 39.784 seconds

Sur ma machine, charger 206560 enregistrements montre une différence de performance d’environ 40% en faveur du type TEXT par rapport au type JSON.

Cela s’explique par les fonctionnalités fournit par le type JSON de MySQL:

  • Validation automatique des documents JSON stockés. Tout document invalide produit une erreur.
  • Optimisation du stockage des données. Les documents JSON stockés dans des colonnes de type JSON sont convertis en un format interne qui permet un accès en lecture rapide.

Bien évidemment rien de comparable pour le type TEXT, ces fonctionnalités ont donc un coût lors de l’écriture dans la table, ce qui est plutôt logique.

Au niveau des méta-données:

Le point intéressant ici est que le type de données LONGTEXT consomme plus d’espace que le type JSON (au format de stockage optimisé) environ 20% plus.

 

Note: L’insertion des documents JSON peut également se faire avec une requête INSERT classique.

e.g. (le champs doc est de type JSON)

 

 

Récupérer des données d’un document JSON

MySQL 5.7 fournit un ensemble de fonctions JSON.

Par exemple, JSON_EXTRACT renvoi des données d’un document JSON. A noter que, depuis MySQL 5.7.9 vous pouvez utiliser la syntaxe inlined JSON path expressions qui rend plus lisible les requêtes qui manipulent des données JSON:

e.g.

JSON_EXTRACT(col, « $.json_field ») est similaire à col->« $.json_field »

 

Table avec type de données JSON

Minimum number of seconds to run all queries: 4.470 seconds

Table avec type de données TEXT

Minimum number of seconds to run all queries: 29.365 seconds

Remarques

Récupérer les documents JSON implique, sans surprise, un Full Table Scan (FTS).

Cependant on peut constater la puissance du format interne JSON de MySQL qui permet un accès en lecture particulièrement rapide et efficace.

Dans cet exemple  le temps d’exécution est environ 7 fois plus rapide (4.470 s vs 29.365 s) avec le type de données JSON comparé aux même données stockées dans une colonne de type TEXT.

 

Colonne générée (Generated Column)

Une colonne de type JSON ne peut être indexée. CEPENDANT il est possible de contourner cette restriction en créant un index sur une generated column qui permet d’extraire une valeur scalaire de la colonne JSON. Les generated columns peuvent être stockée / matérialisée (STORED) ou virtuelle / non matérialisée (VIRTUAL).

Créer une generated column virtuelle (VIRTUAL) est très rapide car les valeurs de la colonne ne sont pas stockées mais calculées à la volée lors de la lecture des enregistrements immédiatement après tout trigger BEFORE. Seules les méta-données sont modifiées en d’autres termes, il n’y a pas de reconstruction de la table.

En production, c’est en général une colonne générée virtuelle qui sera pertinente.

Note: Le désavantage de cette approche est que certaines données sont stockées 2 fois; dans la colonne générée et dans l’index.

Les nouvelles structures de tables sont:

Au niveau des méta-données:

Remarques

Identique !

Comme on le pressentait la taille des données n’a pas changée.

 

Y a t’il une différence de temps d’exécution entre récupérer des documents JSON à partir de la colonne virtuelle et à partir de la fonction JSON_EXTRACT ?

Minimum number of seconds to run all queries: 2.790 seconds

Minimum number of seconds to run all queries: 25.933 seconds

Remarques

Évidemment le plan d’exécution (QEP) est le même: FTS.

Cependant 2 commentaires:

  • Le type de données JSON de MySQL est encore plus efficace que le type de données TEXT, dans cet exemple le temps d’exécution est environ 8 fois plus rapide avec JSON.
  • Un FTS sur une generated column virtuelle (colonne: feature_type) est plus performant que l’utilisation, dans la clause du SELECT, de la fonction json_extract sur le document JSON (de 4.470 à 2.790).

 

Créer un index sur une colonne générée

A partir de MySQL 5.7.8, InnoDB supporte les index secondaires sur les colonnes virtuelles.

Ajouter ou supprimer un index secondaire dans une colonne virtuelle est une opération qui ne nécessite pas de recopier la table (in-place operation).

La nouvelle structure des tables est:

Au niveau des méta-données:

Remarque

L’index sur la colonne feature_type est matérialisé. Sa taille est approximativement 6 Mo.

Grâce à l’index, la requête devrait être plus efficace:

Minimum number of seconds to run all queries: 0.178 seconds

Minimum number of seconds to run all queries: 0.178 seconds

Comme prévu, l’optimiseur utilise l’index (feature_type) et la temps d’exécution de la requête est vraiment meilleur, et ce pour les 2 tables (de 2.790 à 0.178 pour la colonne JSON).

 

Pour conclure

MySQL 5.7 implémente le type de données JSON, ainsi qu’un ensemble de fonctions qui permet de Créer, Chercher, Modifier des valeurs JSON mais également de Renvoyer des valeur d’attributs JSON. C’est une superbe fonctionnalité et je suis persuadé que les développeurs sauront en faire bon usage.

La colonne générée (Generated Columns) est également une fonctionnalité très utile. Elle peut être utilisée, entre autre, pour indexer une fonction, ou comme cache pour expressions souvent utilisées, ou pour indexer du contenu XML… ou comme nous venons de le voir pour indexer des documents JSON.

MySQL 5.7 est vraiment une superbe version !  Essayez la, elle mérite définitivement plus de 30 minutes.

Vous voulez en savoir plus sur MySQL 5.7?

 

Pour aller plus loin

MySQL Documentation

The JSON data type

https://dev.mysql.com/doc/refman/5.7/en/json.html

JSON Functions

https://dev.mysql.com/doc/refman/5.7/en/json-functions.html

CREATE TABLE and Generated Columns

http://dev.mysql.com/doc/refman/5.7/en/create-table.html#create-table-generated-columns

MySQL Server Blog

Native JSON Data Type and Binary Format

http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

JSON functions

http://mysqlserverteam.com/json-labs-release-json-functions-part-1-manipulation-json-data/

http://mysqlserverteam.com/mysql-5-7-lab-release-json-functions-part-2-querying-json-data/

Inline JSON Path Expressions in MySQL 5.7

http://mysqlserverteam.com/inline-json-path-expressions-in-mysql-5-7/

Getting Started With MySQL & JSON on Windows

http://mysqlserverteam.com/getting-started-with-mysql-json-on-windows/

Effective Functional Indexes in InnoDB

http://mysqlserverteam.com/json-labs-release-effective-functional-indexes-in-innodb/

MySQL 5.7

What Is New in MySQL 5.7

https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html

Complete list of new features in MySQL 5.7

http://www.thecompletelistoffeatures.com/

2

Slides du meetup

septembre 25, 2015

Le 17 septembre j’ai été invité par le MySQL User Group Fr pour parler d’un retour d’expérience sur une migration MySQL 5.5 vers 5.6.

Voici ma présentation:

Upgrade to MySQL 5.6 without downtime from Olivier DASINI

 

0

Meetup MySQL à Paris

septembre 14, 2015

Ce jeudi 17 septembre 2015, à l’initiative du MySQL User Group France (lemug.fr),  je vais présenter un retour d’expérience sur une migration MySQL 5.5 vers 5.6 dans les locaux de Dailymotion à Paris.

Le programme :

  • Aurélien Lequoy – DBA MySQL et CEO de Esysteme – présentera PmaControl son outil pour administrer et superviser MySQL.
  • Serge Frezefond – Architecte Cloud chez MariaDB Corp – parlera des nouveautés MariaDB 10.1 liées à la sécurité.
  • Olivier Dasini – Sr. MySQL DBA – Upgrade to MySQL 5.6 without downtime.

 

Infos et inscriptions:

http://www.lemug.fr/2015/invitation-meetup-pma-control-securite-bonnes-pratiques-le-17-septembre/

 

Et c’est gratuit !!! 🙂

Merci à Dailymotion & MariaDB Corp

0