De MariaDB à MongoDB ep1 : Concepts, objectifs

Cet article a été publié il y a 9 ans 5 mois 12 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Ma deuxième série, après la migration de mon laptop sous Linux. Histoire de faire évoluer à la fois mon application de collection de films, et mes connaissances vers d’autres domaines, j’ai décidé de complètement refaire ma base de données. Préparez vos valises, réservez votre billet, et commençons donc le voyage.

L’objectif, ou « c’est quoi une API » ?

Entre autres parce que c’est la mode, j’aimerais pouvoir créer ma propre API (Application Programming Interface) pour ma base de données de films. « A kewa ? » disait Kad Merad dans Qui a tué Pamela Rose ? Comprendre que plutôt que d’accéder « en brut » à la base de données, on passe par un intermédiaire au moyen de requêtes purement web. Autrement dit, pour ma collection de films, plutôt que d’interroger directement MariaDB, j’interrogerais une sorte de « micro site web » qui me renverra les informations de manière plus lisibles. Cela permet, entre autres, de pouvoir à la fois permettre un accès public à des données autrement « privées » (d’un point de vue de l’accès), mais surtout de contrôler cet accès, et aussi de normaliser le format des données pour que d’autres applications dans d’autres langages puissent y accéder.

Par exemple, dans le cadre de Domohouse, la météo utilise un accès libre aux données de Yahoo. J’appelle une adresse http://… avec des paramètres (ceux de la ville), et il me renvoie les résultats au format XML (du texte quoi). Ici, l’idée est la même, et dans le cadre de la collection, voilà comment on accéderait aux données de la fiche du film Casino Royale, de manière « standard » en interrogeant MySQL/MariaDB (les méthodes sont strictement identiques pour PHP), puis par l’API :

C’est donc bien plus court pour l’application, même si, on le verra dans les futurs épisodes, les différences entre les deux bases nous obligeront nécessairement à nous adapter. Et maintenant, plutôt que de consulter et manipuler les données brutes avec toutes les possibilités, on passe par une couche supplémentaire qui permet de choisir ce à quoi on peut accéder.

De nos jours la plupart des gros sites et services qui proposent d’utiliser les informations qu’ils récoltent le font au moyen d’une API. On parle aussi de « web service », car c’est par le protocole HTTP qu’on passe pour l’interroger. D’ailleurs, j’ai parlé d’interrogation, de consultation, mais il est évidemment possible d’ajouter/modifier/supprimer des informations.

Et MongoDB là-dedans ?

J’aime bien me compliquer la vie, et surtout curieux, et pour ça, j’ai décidé de grossir mes maigres connaissances en Python (langage de programmation) pour écrire ma propre API. J’aurais pu le faire en PHP notez bien, mais étant autodidacte, ça n’aurait pas été assez instructif car j’ai déjà suffisamment de connaissances dans ce langage pour le faire. Au mieux aurais-je pu essayer de manger un peu plus de programmation objet, et je n’en ai toujours pas envie.

Mais malheureusement pour moi, j’ai de grandes difficultés à exploiter (enfin surtout à afficher) correctement les informations depuis la base de données MySQL (enfin, MariaDB, puisque c’est lui que j’utilise maintenant). Et puis j’ai entendu parler de MongoDB, une base de données qu’on range dans le mouvement « noSQL » et qui repense complètement le stockage et l’organisation des données. Et paf, ma curiosité étant piquée, j’ai remarqué qu’à priori il était simple de l’utiliser, encore plus dans le cadre de la création d’API. Alors on va tenter le coup.

Un serpent comme outil

J’ai donc décidé de me tourner vers le langage Python, dans l’immédiat la version fournie de base dans Debian Wheezy (puisque ma VM où se trouve collect tourne avec). C’est donc Python 2.7, ce qui n’a pas grande importance, Python 3 est aussi supporté (ce qui m’arrange, car c’est la version par défaut de Manjaro, sur laquelle je pourrais éventuellement être amené à développer au cas où je n’aurais pas accès au serveur). En effet, je ne suis pas non plus masochiste, et j’ai décidé d’utiliser, par dessus Python, le « cadriciel » (pour pas dire framework) Bottle, qui est justement optimisé web, encore plus pour la création d’API. Donc je reste curieux, mais aussi feignant 🙂

A noter que dans le cadre pur de la migration, Bottle ne me sera d’aucune aide. J’utiliserais juste les modules MySQLdb et pymongo pour me connecter aux différentes bases (extraction de MariaDB puis importation dans MongoDB). Pour ceux qui voudraient démarrer en Python, je ne peux que conseiller l’excellent livre « Apprendre à programmer avec Python 3 » de Gérard Swinnen (je l’ai pris en version papier), qui m’a guidé vers mes premiers pas de Python. Ceux qui n’ont pas peur de l’anglais se tourneront vers « Learn Python the hard way« , plus costaud mais plus complet.

Stay tuned for the next episode

Au prochain épisode, on verra en quoi MongoDB est différent d’une base de données MariaDB (qui pour les amnésiques, est à 99% la même chose qu’une base de données MySQL, dont Maria est un fork, si ce n’est LE fork, encore une fois à cause d’Oracle), à quoi ressemble la base de données actuelle, et les prémices de comment la convertir. On fera donc un peu d’expériences à ce moment-là 🙂