Introduction

À l’occasion de la release 10.3 de MariaDB, le MariaDB Roadshow qui s’est tenu Place de Vosges à Paris le 06/06/2018 avait pour objectif principal de présenter les nouvelles solutions open source, leurs caractéristiques et cas d’utilisation.
Nous aborderons dans cet article les différentes sessions qui ont été dispensées, portant notamment sur les stratégies de haute disponibilité pour MariaDB, l’analyse de données avec MariaDB AX, ou encore la sécurité des données dans MariaDB.
Par ailleurs, MariaDB accueillait un intervenant de la société BlaBlaCar, venu discuter de leur migration récente vers les containers.

Slides
Les slides correspondant aux différentes présentations sont disponibles dans la dernière section de cet article et également en commentaire.

MariaDB aujourd’hui et dans le futur

Qu’est-ce que MariaDB ?

Tout d’abord, pour ceux qui ne le savent pas encore, MariaDB est un système de gestion de base de données édité sous licence GPL. Il s’agit d’un fork communautaire de MySQL : la gouvernance du projet est assurée par la fondation MariaDB, et sa maintenance par la société Monty Program AB, créateur du projet.
La fondation MariaDB s’occupe donc de construire une base de données qui soit simple à utiliser, simple à étendre et simple à déployer.

Pourquoi MariaDB ?

Considérer MariaDB, c’est tout d’abord bénéficier de coûts réduits : l’abonnement MariaDB a un coût plus bas que les autres bases de données. C’est également bénéficier d’une intégration simple au niveau de l’infrastructure, et avec du hardware moderne.

En 2018, 70% des nouveaux systèmes sont déployés avec des bases de données open source, et 50% des applications déjà existantes utilisent ou s’apprêtent à utiliser une base de données open source.

Il existe trois tendances dans l’univers des bases de données à ce jour :

• Distribution, modernité, grande liberté de management.
• Cloud et containers : DBaaS, microservices, séparation du computing et du stockage.
• Open source.

Aspect financier

• On premise : MariaDB coûte environ 80 fois moins qu’Oracle, ce qui se traduit finalement par une économie de 9 millions de dollars dans le meilleur des cas.
• Cloud : Sur AWS, Oracle coûte 145 fois plus cher que MariaDB, et Oracle Cloud est 69 fois plus coûteux.

Multiples entreprises

Beaucoup d’entreprises contribuent au développement de MariaDB, notamment Alibaba.com, Tencent, Taobao.com, Oracle, etc.
Beaucoup de clients également : Google, Facebook, Booking.com, Alibaba.com, DBS (Development Bank of Singapour), etc.

Le but de DBS était de migrer leurs applications internes vers MariaDB. La migration de leurs applications écrites originellement en Oracle prendrait plusieurs années, donc les développeurs de la fondation MariaDB ont eu l’idée de supporter la version de PL/SQL d’Oracle directement depuis MariaDB (version 10.3).

Différentes plateformes

Toutes les distributions de Linux gèrent maintenant MariaDB. Et par ailleurs, tous les grands fournisseurs de cloud possèdent déjà MariaDB comme base de données.

Un mode de pensée unique

Il existe trois problèmes avec l’Open Core :

• Par exemple, MySQL ne veut pas intégrer de modifications de la communauté, donc les innovations sont plus lentes.
• Le framework utilisé pour tester le logiciel doit aussi être ouvert pour que toute la communauté puisse tester la BDD et construise de nouvelles innovations.
• Un vrai “Open Core” implique un accès au code propriétaire.

Chez MariaDB, ils pensent un peu différemment :

• Ils accueillent volontiers le code communautaire.
• 100% Open Source.
• Ils fournissent des APIs et des exemples.

Aspect commercial

MariaDB a environ 12 millions d’utilisateurs répartis dans près de 45 pays.

Pour les professionnels, il existe MariaDB TX (transactional workload) et MariaDB AX (analytical workload).
Parmi les clients TX, on compte notamment Paybox, BlaBlaCar, Wikipedia et Booking.com.
Parmi les clients AX, on compte OTCMarkets, IHME, Bandwidth ou encore Qualcomm.

Les services apportés par MariaDB pour ses clients sont nombreux :

• Support technique
• Consulting
• Training
• Architecte entreprise
• Expérience en migration
• Administration de bases de données à distance

DBS a environ 400 applications internes, et environ 250 sont aujourd’hui migrées sous MariaDB. L’application la plus compliquée à migrer l’a été faite avec succès, donc on peut imaginer que toutes les autres le sont également. À noter que cette migration était un choix commercial plus que technique.

Les stratégies de haute disponibilité pour MariaDB

La haute disponibilité traduit le bon fonctionnement d’un système (de base de données) pendant une période de temps la plus grande possible, et cela se mesure en général en « nombre de 9 ».

Recherches de Gartner
Environ 80% des downtimes sont dûs à une erreur humaine.

Plus subtilement, un système peut être up mais pas accessible, ou encore down une seule fois par an mais sur une longue période. Dans les deux cas, on considère qu’il n’y a pas de haute disponibilité.

Les composants de la haute disponibilité sont les suivants :

• Monitoring et management.
• Switchover (= processus manuel pour switcher à un système redondant en cas de failure) ou failover (= switchover automatique, sans intervention humaine).
• Redondance des données : si on n’a pas une copie des données ailleurs, on n’est pas à l’abri d’une catastrophe.

Redondance des données

Réplication des données

Il existe trois types de réplication des données :

• La réplication asynchrone : le master n’attend pas le slave, il écrit ses events dans le binlog et les slaves requêtent les events  lorsqu’ils sont prêts.
• La réplication semi-synchrone.
• La réplication synchrone : tous les nœuds sont définis comme masters, et les applications peuvent lire/écrire depuis/vers n’importe quel nœud.

La haute disponibilité commence par la réplication des données. Celle-ci permet aux données d’un serveur MariaDB (le master) d’être répliquées à un ou plusieurs autres serveurs MariaDB (les slaves). La réplication MariaDB est notamment très simple à mettre en place.

Réplication asynchrone

La réplication asynchrone est utilisée par défaut dans MariaDB. Le slave détermine combien lire et depuis quel point dans le binlog. Par contre, si le master crash, on n’a pas de certitude que les transactions aient été transmises à un slave. L’avantage de cette méthode c’est qu’elle est bien pour le read scaling et que l’ajout de replicas n’impacte pas la latence.

MaxScale

Le proxy MaxScale fait le routage pour nous. Il y a possibilité de failover automatique depuis la version 2.2. MaxScale identifie master et slaves et si le master fail, il va détecter quel nœud est le plus à jour pour en faire la promotion.

Réplication semi-synchrone

Elle est gérée par MariaDB : le master ne confirme pas la transaction à l’application client tant qu’un slave n’a pas copié l’event du binlog.
Un ou plusieurs slaves peuvent être définis comme étant semi-synchrones.

MariaDB permet la réplication multi-sources : plusieurs masters agrègent des slaves. Cela implique une redondance des données. Cela ne pose pas de souci, cependant si deux modifications sont envoyées sur une même ligne, c’est le dernier arrivé qui impose sa modification (même si ce n’était pas l’ordre prévu à la base).

Il est alors possible de combiner des méthodes de réplication. Par exemple, combiner un master avec un master fail, un slave asynchrone et d’autres read-only.

Réplication synchrone (Galera)

Elle ne fonctionne qu’avec InnoDB.
Chaque composant du cluster (node) est un « share nothing server ».
Un cluster Galera minimal a besoin de 3 nœuds.
Les transactions sont réalisées sur tous les nœuds de manière synchrone.

Les avantages de la réplication synchrone :

• Haute disponibilité assurée, resynchronisation incluse
• Pas de perte de données
• Tous les serveurs ont leurs données à jour (no slave lag)
• Très bien pour la read scalability

Les inconvénients de la réplication synchrone :

• Fonctionne seulement avec InnoDB
• S’il y a un rollback, la transaction doit être annulée sur tous les nœuds, ce qui est par conséquent plus long
• Le cluster possède la même performance que le moins performant des nœuds
• Un réseau peu performant implique une latence plus élevée, voire une désynchronisation dans le pire des cas

Cas d’utilisation de MaxScale : MBDE Cluster Synchronous Replication

MaxScale sélectionne un nœud qui prend le rôle de master et les autres le rôle de slaves. Si le master fail, un autre est sélectionné immédiatement.

Haute disponibilité MariaDB : MaxScale
Le binary log server a été développé pour Booking.com à l’origine. Il permet de faciliter la promotion d’un slave, car ils sont tous synchronisés.

Analyse de données avec MariaDB AX

Pourquoi s’attarder sur l’analyse de données ?

L’analyse de données :

• Donne de la valeur à nos données
• Accélère les processus de prise de décision de l’entreprise
• Réduit certains coûts
• Permet de développer de nouveaux produits et services

Différents types d’analyse

• Descriptive : que s’est-il passé ?
• Diagnostics : pourquoi il s’est passé ce qu’il s’est passé ?
• Predictive : Que peut-il se passer ?
• Prescriptive : Que doit-je faire de cette information ?

Cas d’utilisation de l’analyse de données

• En Finance :
  1. Identifier des patterns de trading
  2. Détecter des fraudes ou anomalies
  3. Prédire des revenus de trading
• En Healthcare :
  1. Faire du profiling/matching génétique
  2. Prédire des épidémies
• En Manufacturing :
  1. Faire des simulations pour améliorer le design/rendement d’un produit
  2. Prédire les pannes de machines
• En Telecom :
  1. Faire de l’analyse comportementale lors d’appels de clients
  2. Faire de l’analyse de réseau (performance et fiabilité)

Considérations liées à l’analyse de données

Lors du choix d’une solution d’analyse de données, il y a plusieurs considérations à avoir :

• Considérations techniques : est-ce que l’on maîtrise correctement l’outil ?
• Gestion de l’analyse des données en temps réel : rapidité lors du traitement de la donnée ou lors de la requête de données
• Outils préexistants : est-ce que l’outil inclut des fonctionnalités d’analyse de données ?
• Considération business : est-ce qu’il y a suffisamment de personnes qui maîtrisent l’outil ?
• Coût de déploiement et d’utilisation : hardware, ratio prix/performance, réservoir de talents large

Approches déjà existantes

Il existe d’ores et déjà différentes approches :

• Data Warehouses :
  1. Difficile à utiliser
  2. Limitation quant à l’analyse en temps réel
  3. Hardware et software chers
  4. Analyse construite plutôt que prédictive
• Hadoop / NoSQL :
  1. Support SQL limité
  2. Réservoir de talents faible
  3. Data lake sans management de données : quand on récupère une donnée, on ne sait pas trop ce que l’on va récupérer et si cela peut poser des problèmes de performance

Solution MariaDB : MariaDB AX et ColumnStore

MariaDB propose une solution Big Data simple, rapide, évolutif et open source : MariaDB AX et ColumnStore.

L’architecture de cette solution est globalement constituée d’une couche de ColumnStore storages, d’une couche de serveurs MariaDB contenant eux-même chacun un ColumnStore, et par-dessus un composant MaxScale (voir slides correspondantes pour le graphique).

MariaDB ColumnStore

Ce composant possède plusieurs qualités :

• Manager les quatre typologies d’analyse de données vues précédemment
• Meilleur ratio prix/performance (environ 90,3% moins cher que la norme par terabyte par an) : il a à la fois le pouvoir du SQL et la liberté de l’open source
• Facilités à analyser des données d’entreprise : interface simple, facile à manager, évolutif
• Plus rapide et plus efficace lors de requêtes : processing de requêtes en parallèle pour environnements distribués, ce qui donne de bons résultats de performance
• Option de déploiement flexible : cloud et on-premise, fonctionne sur du hardware commun, open source, pricing basé sur de la souscription
• Pas besoin de maintenir une plateforme tierce : l’analyse se fait sur le même front-end SQL, pas de nécessité de mettre à jour le code de l’application, force de l’architecture extensible MariaDB
• Meilleure compression de données : plus efficace lors du stockage de données multiples, moins de hardware nécessaire

Les requêtes sont également plus rapides et plus efficaces :

• Optimisation pour le stockage en colonnes : le stockage en colonnes réduit les entrées/sorties sur le disque, lecture de données rapide, importation de données ultra-rapide
• Environnement d’analyse très accessible : redondance incluse, failover automatique

Plus de précisions sur les facilités à analyser des données d’entreprise :

• Interface SQL simple et unique : englobe les fonctionnalités de sécurité de MariaDB – encryptions de données en mouvement, accès basé sur des rôles, audit
• SQL full-ANSI : plus de requête « SQL-like », gestion de joins complexes, fonction de fenêtre et d’agrégation
• Facile à manager et à faire évoluer : élimine les besoins d’index et de vues, partitioning horizontal/vertical automatique, évolution linéaire grâce à l’ajout de nouveaux nœuds lorsque la quantité des données augmente

Enfin, OLTP vers OLAP : on s’assure que les données analytiques sont à jour et viables.

Cas d’utilisation

IHME

IHME a commencé avec 4,2 TB de données et avec pour objectif 30 TB de données. La solution MariaDB AX leur a permis d’obtenir sensiblement les mêmes résultats qu’avant mais pour moins cher.

CIM

Les analystes de CIM n’arrivaient pas à faire des requêtes suffisamment complexes pour obtenir les résultats escomptés (via Oracle). Et maintenant, via MariaDB, ils n’ont plus qu’une seule table de 248 colonnes et près de 2,5 millions de lignes. Grâce au ColumnStore, ils sont maintenant capables de faire une vingtaine de requêtes sur des colonnes en quelques secondes seulement (contre quelques minutes auparavant).

Genus

Auparavant, ils étaient obligés de convertir tous leurs fichiers en .csv via des cron jobs.
Maintenant, ils possèdent un adaptateur de données en Python qui s’occupe de streamer les données dans le ColumnStore. Cela permet de supprimer des étapes intermédiaires, et donc de potentielles erreurs ; cela raccourcit également considérablement les délais. Par ailleurs, il est possible d’importer de la donnée sur demande et d’avoir un accès client immédiat.

Pinger

Cette entreprise s’occupe d’analyser le comportement des personnes selon leurs appels et sms. Près de 3 millions d’appels et 30 millions de sms par jour sont à analyser, ce qui correspond à 1,5 milliard de lignes de log par jour, celles-ci s’ajoutant chaque jour au travail restant.
Elle a migré vers MariaDB AX et peut depuis processer environ 24 mois de données contre seulement 6 avant.

Sécurité des données

Best Practices

Une des best practices les plus essentielles, c’est d’avoir conscience qu’il y a énormément d’attaques sur des outils populaires tels que WordPress, PHPMyAdmin, etc. Ce n’est pas parce que c’est populaire que c’est complètement sécurisé.

Différents niveaux d’attaque

Premier niveau d’attaque : Internet

Il existe trois types de sources d’attaques sur Internet :

• Les virus
• Les hackers
• Le spoofing

Pour se défendre, le mieux est entre-autres de garder un OS à jour et d’utiliser son firewall correctement.

MariaDB conseille vivement de ne pas autoriser de connexion TCP à sa plateforme.

Deuxième niveau d’attaque : les applications

On y retrouve le déni de service, la surcharge d’applications, les attaques par injection (dont injection SQL), etc.

Pour se défendre contre ces attaques, il faut installer le strict nécessaire au niveau des packages. Aussi, il ne faut pas lancer l’application sur le serveur MariaDB car on risque de laisser un accès à un fichier de configuration contenant login et mot de passe par exemple, ou même à un fichier de données sensibles autre.

Troisième niveau d’attaque : la confiance excessive

On peut entre-autres faire face à des employés mécontents ou à des erreurs humaines.

Par exemple, un ancien employé d’AirFrance avait copié et effacé les données client de l’entreprise par mécontentement. Il s’est fait attraper par les services secrets parce que ces données étaient partagées avec d’autres services. Pour une entreprise privée, cela aurait pu être catastrophique car la personne aurait pu la faire chanter.

Pour se défendre de ce genre d’attaque, il existe plusieurs recommandations, comme par exemple ne pas mettre le processus MariaDB en root, éviter les « full-wildcards » (e.g.  » connexion_from: *  » : si l’on autorise une connexion de partout dans le monde et que l’on se fait piquer notre PC, c’est très embêtant…), limiter les accès utilisateur, limiter les privilèges aux applications/utilisateurs, et ne jamais donner l’accès à la base de données MySQL (personne n’en a besoin, il s’agit de la base de données système).

Solutions chez MariaDB

Pour les applications, le plugin simple_password_check permet d’éviter les mots de passe trop simples tels que ‘1234’ ou ‘password’.
Par ailleurs, MariaDB gère la connexion via SSO, LDAP (plugin PAM).

Anthentification MariaDB PAM

Fonctionne sous Windows et Linux.
Active Directory est disponible sous Windows. Techniquement, il est aussi disponible sous Linux en bidouillant un peu.

Role based access

MariaDB travaille avec des rôles pour autoriser les accès. Cela permet d’éviter de gérer tous les droits pour chaque utilisateur individuellement.

Encryption de données

Données en mouvement

• Connexions sécurisées
• Authentification externe : on peut encrypter les données (et non le fichier dans lequel sont stockées les données) qui sont présentes sur le disque. C’est sélectif, on peut encrypter l’ensemble ou une partie des données.

Données au repos

• Management interne des clés dans MariaDB
• Gestion des services de management de clés : Amazon, Eperi (optionnel)

Protection avec MariaDB MaxScale

• Firewall de base de données : nouveau niveau d’autorisation qui est géré en dehors de la base, avant même d’y accéder, fichier multi-règles (i.e. il n’est pas obligé de tout écrire en une seule ligne)
• Protection contre un déni de service : MaxScale manage ses propres connexions vers la base (connection pooling)

Surcharge de serveur

MaxScale limite le nombre de connexions, et n’ouvre pas une connexion par requête.
Il est protégé des DDOS par la limitation de remontée de lignes ou la limitation de taille.

Injection SQL

L’utilisation du fichier de règles permet l’identification des patterns. Ainsi, on peut fonctionner :

• Par whitelist : on spécifie explicitement ce qu’on a le droit de faire, cela simplifie la gestion des droits au niveau de la base et on gère d’éventuelles restrictions sur une colonne d’une table par exemple
• Ou bien par blacklist : on explicite ce qui est interdit

Firewall de base de données

Il permet notamment de faire des matchs en fonction de la date et de l’heure. Cela évite par exemple le requêtage d’un petit malin qui resterait tard au travail pour faire ses opérations.

Data masking

En lien notamment avec GDPR.
On peut anonymiser entièrement ou partiellement une colonne par exemple (typiquement le numéro de carte de crédit).

Sécurité MariaDB
La sécurité chez MariaDB ne cesse de progresser. Il existe un repo CVE avec toutes les informations sur les mises à jour faites, aussi disponibles sur le site de MariaDB.

The expendables: Les containers chez BlaBlaCar

La session a été présentée par Maxime Fouilleul, Lead Database Engineer chez BlaBlaCar.

Le vrai titre de la présentation est : Scalability via Expendables Resources : Containers at BlaBlaCar.

Il y a un peu plus de 2 ans, l’entreprise a décidé de migrer tout son workload vers des containers.

La traduction de ‘expendable’ donne le mot ‘sacrifiable’ : c’est exactement ça l’idée, c’est casser l’importance d’une ressource, la rendre futile, remplaçable.

BlaBlaCar en chiffres

• 60 millions d’utilisateurs
• Fondée en 2006
• 1 million de tonnes de CO₂ en moins
• 30 millions de téléchargements pour l’application mobile

Écosystème

Production

Les principaux outils utilisés sont les suivants : MariaDB, Cassandra, Redis, ElasticSearch, PostgreSQL.

Infrastructure

Chez BlaBlaCar, il existe un seul type de serveur sur lequel vont tourner des containers (pas sur Docker mais sur Rocket).

Un rocket pod va héberger plusieurs containers ayant le même contexte. Si un container meurt dans un pod, tout le pod meurt.

L’orchestrator est un cluster Fleet (« distributed init system »).
Kubernetes a été intégré récemment et tourne côte-à-côte avec Fleet.

Les autres composants de l’infrastructure sont le hardware, le service codebase et le service discovery.

Service Discovery

Il est composé de 3 produits :

• Service registry : Zookeeper
• Nerve : du côté du pod back-end, vérifie la santé du service et envoie des rapports à Zookeeper
• Synapse : du côté du pod client, surveille une ou plusieurs clés Zookeeper et met à jour HA Proxy en fonction de ce qu’il se passe dans Zookeeper. Synapse possède deux services : read et write.

Piliers de la haute disponibilité en backend

Pilier 1: Abolish Slavery. Everyone’s the same

Tous les nœuds d’un même service sont identiques. Cette idée permet d’enlever un poids de réflexion énorme.

Asynchrone vs. Synchrone

En master/slave, si on perd le master on crée une « downtime » obligatoirement.

En Galera (cluster MariaDB), pas de point unique de défaillance (SPOF en anglais), pas de lag de réplication, les transferts d’état sont automatiques, mais le cluster est aussi rapide que le nœud le plus lent.

Pilier 2 : Be Quiet! Come gently into prod

Service Discovery weight system.
Natif dans HA Proxy.

Pilier 3: Die in Peace… Get out when you are ready

Gracefully Disabling Pipeline.

DBaaS – Construire une infrastructure sans friction

Le déploiement est simplifié :

• Pull requests sur le repo du service
• Pas de paramétrage technique à surcharger
• Les services sont auto-initialisés. Pas de maintenance à faire sur la création de nouveaux services

L’outil GGN est utilisé pour le déploiement (open source).
Il génère des unités systemd basées sur des templates et les envoie à l’environnement en utilisant Fleet.

Le monitoring et l’alerting sont simplifiés :

• Monitoring orienté service
• On monitore le strict nécessaire, c’est-à-dire que tout ce qui n’est plus en prod n’est plus monitoré

Écosystème de monitoring

Il est constitué de :

• Nerve : service discovery
• Prometheus
• Grafana
• Poder Duty (PD)

Relabeling via Prometheus

Les informations sur les services sont poussées dans Zookeeper via Nerve et Prometheus s’occupe de la suite. Il fait une requête unique, peu importe le nombre de nœuds, et obtient une réponse pour chaque nœud. De cette manière, avec un même dashboard, il est possible de monitorer toutes les topologies de son infrastructure.

Troubleshooting

Le troubleshooting est également simplifié, les vérifications de santé basiques sont faites rapidement, en temps réel, ce qui évite les erreurs humaines.

Ce dernier est fait avec la commande « bbc » qui est une commande interne à BlaBlaCar. Les avantages de cette commande sont les suivants :

• Il s’agit d’un set de scripts bash
• Elle est designée pour leurs propres besoins
• Elle est branchée à leur service discovery
• Elle pratique les vérifications de santé basiques rapidement
• Elle manage toutes les backends de la même manière
• Elle peut être utilisée par des non-spécialistes

BlaBlaCar dans le futur

Fleet est devenu déprécié. L’entreprise a déjà commencé à se tourner vers Kubernetes. Cependant, Fleet est assez orienté sur les nœuds, ce qui n’est pas le cas pour Kubernetes.

Ils vont certainement se tourner vers Docker, parce que Kubernetes et Rocket (rktnetes, rktlet) n’est pas la meilleure combinaison.

Enfin, la question du cloud est également considérée. L’idéal serait de migrer toutes les applications vers le cloud.

MariaDB 10.3 – Les nouveautés

La version 10.3 de MariaDB inclut beaucoup de nouvelles fonctionnalités. Les plus importantes sont :

• Le support de données temporelles : il s’agit d’une nouvelle forme de moteur de stockage de MariaDB. Elle est telle que lorsque l’on supprime les dates, les données restent en base.
• La compatibilité Oracle : le but est de simplifier, faciliter la migration d’Oracle vers MariaDB. Il y a aussi des paquets, séquences. Fonctionnalités sur la théorie des ensembles. Gestion de champs invisibles.

Niveau flexibilité : les opérations mathématiques telles que SUM, COUNT, MAX, MIN, etc. sont maintenant gérées.

Une nouvelle version de Spider permet une meilleure évolutivité.

Il existait des limitations qui ont été corrigées : par exemple on ne pouvait pas avoir un DELETE avec une sous-requête contenant une clause WHERE. De même, il n’était pas possible d’avoir un UPDATE avec un sous-requête requêtant la même table.

La compatibilité Oracle inclut notamment la compatibilité PL/SQL qui permet dans l’idée de simplifier la migration des applications écrites sous Oracle pour pouvoir les utiliser sous MariaDB.

Génération de clés primaires uniques par SEQUENCES :

• Utilisée pour créer une séquence de valeurs numériques
• Une alternative à l’option d’auto-incrémentation lors de la création d’identifiants uniques – offre plus de contrôle sur la création de tels nombres
• Utilise des fonctions pour récupérer les valeurs précédentes et suivantes

Les opérations INTERSECT et EXCEPT sur des sets de résultats sont maintenant gérées.

Ce n’est pas gratuit de stocker toutes les dates, ça coûte de la performance. C’est pourquoi ce n’est pas utile d’utiliser des tables versionnées partout. Une table versionnée se crée grâce à un « with system versioning » au moment de la création de la table (mot-clé AS OF).

D’autres mots-clés (ROW, TYPE OF, ROW TYPE OF, etc.) sont disponibles sur la release note de MariaDB 10.3 ou bien sur les slides associées.

Conclusion

En conclusion, de mon point de vue, cette journée était assez technique. Ne possédant qu’une très faible connaissance du fonctionnement d’une base de données d’entreprise, je pense sincèrement que de très nombreux aspects m’ont échappé et je n’ai pas pu profiter de la présence des collaborateurs de MariaDB pour poser des questions ou même m’entretenir avec eux entre les sessions.

Cependant, j’ai gagné un peu de visibilité sur cet aspect « donnée » lorsque l’on développe une application. Cette montée en compétence aurait pu être catalysée si j’avais eu une certaine connaissance au préalable de MariaDB.

Si ce n’est pas déjà le cas, les slides de cette journée seront attachées à cet article dès qu’elles auront été récupérées. Ainsi, il sera plus simple d’assimiler les informations de cet article qui sont très certainement peu claires à première vue.

Ressources

Slideshare :

• MariaDB aujourd’hui et dans le futur
• Les stratégies de haute disponibilité pour MariaDB
• Analyse de données avec MariaDB AX
• Sécurité des données
• The expendables: Les containers chez BlaBlaCar
• MariaDB 10.3 – Les nouveautés