Les problèmes des RDBMS

Les bases de données relationnelles ont comme caractéristique principale d’être très structurées. C’est sans doute la raison derrière leur grande popularité. Par contre, ce ne sont pas tous les problèmes qui tombent dans le moule de ce type d’architecture.

Aussi, il devient plutôt difficile, dépassé un certain point, de continuer à scaler horizontalement avec ce type de bases de données. On met la base de donnée sur un autre serveur, ensuite on ajoute des réplications pour avoir des master/slaves, on optimise nos requêtes… ça peut nous mener très loin, mais pas assez loin pour les gros joueurs. Le problème des performances était donc aussi une des motivations pour chercher une autre solution.

The new kids on the block

Alors voilà qu’apparait toutes les nouvelles bases de données et que le sujet se met à bouillonner. Tokyo, CouchDB, MongoDB, HBase (du projet Hadoop), Redis, Cassandra, etc.

Ces projets sont pour la plupart orienté sur la distributivité de la base de donnée. Elles ont été conçues à la base pour scaler horizontalement.

Essai de MongoDB avec PHP

J’ai donc décidé d’essayer un de ces systèmes: MongoDB. Il s’agit d’une base de donnée sans schéma: on y stock les données à peu près comme on veut et chaque entrées peut avoir des champs différents. L’installation est plutôt simple (du moins sous Linux), les fichiers binaires ou le code source sont disponible sur le site web. Lorsque le serveur est installé, il faut installer les drivers pour chaque langage que l’on compte utiliser (PHP, Python, Ruby, Java, etc. C++, lui, est inclu). J’ai donc installé le driver pour PHP à partir du code source sur le site web. Seulement ensuite je me suis rendu compte que j’aurais pu me sauver un peu de compilation en faisant simplement sudo pecl install mongo (sous Ubuntu).

Voici un exemple de code tiré à peu près du site de MongoDB pour insérer des données:

$m = new Mongo();
$collection = $m->selectDB( "foo" )->selectCollection( "bar" );

$doc = array( "name" => "MongoDB",
   "type" => "database",
   "count" => 1,
   "info" => (object)array( "x" => 203,
       "y" => 102),
   "versions" => array("0.9.7", "0.9.8", "0.9.9")
);

$collection->insert( $doc );

On les récupère ensuite:

$m = new Mongo();
$collection = $m->selectDB( "foo" )->selectCollection( "bar" );

$obj = $collection->findOne();

Ou on peut faire une requête pour plusieurs résultats:

$m = new Mongo();
$collection = $m->selectDB( "foo" )->selectCollection( "bar" );

$cursor = $collection->find( array('name' => 'MongoDB') );

while( $cursor->hasNext() ) {
    var_dump( $cursor->getNext() );
}

Simple, trop simple?

Avec les bases de données relationnelles, le simple apprentissage du SQL permettait de bien comprendre le paradigme des RDBMS et de bien s’en servir. Maintenant, avec les nouvelles bases de données qui apparaissent, nous avons beaucoup plus de flexibilité: on y met à peu près ce qu’on veut. Le prochain objet qu’on y insère n’a pas besoin de ressembler au précédent. Cette flexibilité est bienvenue et très puissante (par exemple, on peut faire rouler plusieurs version de la même application en même temps, selon le client, avec la même base de donnée, comme Google le fait avec Gmail).

Cette flexibilité et simplicité vient par contre au prix d’être complètement laissés à nous-même. Les RDBMS sont vieilles et son fonctionnement bien connu de tous. Des tonnes de livres ont été écrites sur MySQL, SQLite, SQL Server et l’architecture avec les RDBMS. Les fonctionnalités des nouvelles bases de données sont généralement bien documentées. C’est très simple (beaucoup plus simple qu’avec du SQL) d’y insérer et récupérer des entrées. Par contre, la façon de penser l’architecture d’applications qui utilisent ces bases de données est plutôt nébuleuse. Je n’ai pas encore vu de livre qui traitent de l’utilisation de ces systèmes et les blogs qui en glissent un mot parlent plutôt de l’architecture matérielle utilisée, des raisons qui ont poussés la migration et des raisons de leur choix particulier parmi les nouvelles bases de données.

On va continuer d’en entendre parler

Ceci dit, tout ce que j’ai lu à date sur le sujet est très positif. Est-ce révolutionnaire ou bien avait-on simplement besoin d’air frais? Une chose est sûr c’est que les bases de données « non-relationnelles » sont là pour rester. Par contre, elles n’écraseront pas les RDBMS pour toutes les situations de si tôt: elles ne sont pas (et ne tentent pas d’être) ACID. On continuera donc sans doute à utiliser les RDBMS pour les utilisations comme les transactions financières, où l’intégrité des données et l’utilisation de transactions (dans le sens SQL du terme) sont importantes.

Encore faut-il que nos universités abordent le sujet. Parions qu’ils n’en parleront pas avant un bon 10 ans!

Si vous connaissez une source (livre, blog, wiki, etc.) où on peut en apprendre sur la conception d’application et d’architecture avec ces nouvelles bases de données, laissez-moi savoir!

Malgré le hype qu’il y avait pour Git, Google a tout de même choisi Mercurial, que je ne connaissais pas vraiment. J’ai donc décidé de l’essayer.

Distribué vs centralisé

Tout d’abord, Mercurial est comme Git, dans le sens où il s’agit d’un système de contrôle de version distribué. Subversion, lui, est centralisé.

Concrètement, Subversion a son repository à un endroit (générallement sur un serveur). Chaque utilisateur va chercher les fichiers (checkout), fait ses modifications et les renvoit au serveur (commit).

Mercurial, étant distribué, fonctionne de façon légèrement différente. Lorsqu’un utilisateur va chercher les fichiers, il va en fait faire une copie entière du repository. Le scénario classique est qu’un utilisateur va chercher les fichiers sur le serveur (clone), fait ses modifications et les « commet » (commit) seulement dans son repository local. Ensuite, il peut envoyer ses changement dans le repository d’où il a pris ses fichiers (push).

Avec Mercurial, on ne fait pas un checkout et un commit. On fait une branche (clone), et on la merge (push) après avoir fait un ou des changements (commit). Ça comporte plusieurs avantages pour certains types de projets, mais je n’en parlerai pas dans cet article.

Dossier .hg vs dossiers .svn

Subversion utilise plusieurs dossiers .svn. Lorsque vous travaillez dans votre checkout, il y a un dossier .svn par dossier ou sous-dossier de votre projet. Ils ne sont (supposément) pas très nuisibles.

Par contre, j’ai souvent fait face à un problème avec ces dossiers. Un client me dit qu’il veut avoir les fichiers pour montrer à son propre client. Il veut les avoir par FTP. La méthode idéale serait simplement de lui envoyer mon dossier de travail. Par contre, mon dossier de travail est infesté de .svn! Non seulement ces fichiers n’ont pas d’affaires là, mais imaginez le temps que ça prendrait mettre tout ces petits dossier en ligne! Croyez-moi, c’est trop long.

Je pourrais supprimer les dossiers .svn de tout mon projet avec un tour de passe-passe bash:

find ./ -name ".svn" | xargs rm -Rf

Mais faire ça « détruirait » mon checkout. J’aurais besoin de faire un autre checkout avant de continuer à travailler. Je pourrais faire une copie de mon dossier et faire cette commande sur ma copie. Mais copier tous ces sous-dossiers prend parfois bien du temps!

Je pourrais aussi (la solution que j’utilisais) faire un export à partir de mon repository. Il y a quelques points tannants avec cette méthode. Premièrement, Subversion est plutôt lent pour faire un export ou un checkout. Surtout que certains projets deviennent pesant assez rapidement avec les fichiers Flash et toutes les images (les PNG 24-bits ça monte vite!). Deuxièmement, lorsque le client me demande d’avoir les fichiers, j’ai parfois fait certaines modifications que je n’ai pas encore envoyées dans le repository. Je dois donc en premier faire un commit et ensuite je peux faire le export. Troisième chose, lorsque j’ai terminé d’envoyer les fichiers à mon client, je dois supprimer le dossier que je viens de créer. Pas grand chose vous direz, mais c’est quand même une étape de plus, qui n’a pas sa place à mon avis.

Mercurial, lui, ne parsème pas ses dossiers un peu partout au travers du répertoire de travail. Il n’y a qu’un dossier .hg à la racine du repository (rappelez-vous que le dossier de travail est un repository en soit). Donc, tous les problèmes énoncés ci-haut disparaissent. Je peux directement envoyer mon répertoire de travail, en prenant la peine de désélectionner le dossier .hg (et les autres fichiers, s’il y a lieu, comme .hgignore).

Commit local

Avec Subversion, lorsqu’on fait un commit, on envoie les modifications au serveur, car c’est lui qui contient le repository. Avec Mercurial, lorsqu’on fait un commit, il n’y a aucune utilisation du réseau. Le repository est local. On peut donc faire plusieurs commit sans envoyer les modifications au repository où on a pris les fichiers. Lorsqu’on est prêt, on push les commit qu’on a fait.

Vitesse

Je ne peux pas garantir que Mercurial est plus rapide que Subversion, mais je dois avouer que je trouve l’expérience beaucoup plus fluide avec Mercurial qu’avec Subversion.

Facilité

J’avais jeté un oeil rapidement à Git il y a quelque temps, mais je ne m’y était pas attardé. La première impression que j’avais eu était que ça semblait compliqué. Comme les projets sur lesquels je travaille ne profitent pas vraiment du fait que ce soit extrêmement facile de brancher-merger avec les systèmes distribués, j’avais simplement laissé Git de côté. Je n’étais peut-être pas dû pour changer de système à ce moment…

Par contre, lorsque j’ai essayé (et maintenant adopté) Mercurial, j’ai eu une toute autre impression! Il est facile à comprendre et, à mon avis, bien conçu. La courbe d’apprentissage est très légère.

Ajout de fichiers

Avec Subversion, il faut ajouter les fichiers un par un. Encore une fois, ce serait sûrement possible de faire un tour de passe-passe avec grep, mais ça serait plutôt tannant. Si on crée 8 nouveau fichiers, il faut ajouter les 8 fichiers un après l’autre.

Avec Mercurial, la même commande (add) ajoute tous les nouveaux fichiers. Pas de perte de temps. Si on veut ne pas ajouter certains fichiers (exemple: ceux se terminant avec ~), il suffit de se faire un fichier .hgignore dans la racine de notre projet, et le tour est joué.

Hébergement

Premièrement, de la façon dont est conçu Mercurial, il est beaucoup plus facile de ne simplement pas utiliser d’hébergeur. On se fait un repository avec hg init mon_projet et on peut déjà commencer à travailler dans le dossier! Pas besoin de faire un checkout et de travailler dans le dossier du checkout.

Ensuite, comme Subversion, on peut simplement fonctionner par SSH (si vous avez accès à un autre ordinateur/serveur par SSH). hg push ssh://user@example.com/chemin/vers/repo. C’est simple et rapide.

Vous pouvez aussi configurer Mercurial pour fonctionner par HTTP si votre projet a un peu d’envergure. Par contre, ce n’est probablement pas la solution idéale si vous faites parti d’une petite compagnie qui travaille sur plusieurs petits projets.

Sinon, il y a un certain nombre d’hébergeur. Le plus gros est probablement bitbucket. Ils offrent l’hébergement gratuit pour les projets open source, mais aussi de l’hébergement privé. Ils sont un peu le GitHub de Mercurial.

Essayez-le!

Tout ça pour vous dire que ça vaut la peine de l’essayer! Si vous avez peur du command-line, je crois qu’il y a même des GUI plutôt bien faits pour Windows, OS X et Linux.

Aujourd’hui je continue là où je vous avais laissé, c’est-à-dire: vous venez d’installer Apache, MySQL, PHP et phpMyAdmin et avez vérifié que le tout fonctionnait bien. Votre dossier web est /var/www. Le but de l’article d’aujourd’hui est de vous permettre d’utiliser un autre dossier. En fait, vous pourrez utiliser un dossier différent pour chaque projet et y accéder avec des noms de domaines différents. Je vous introduis donc aux serveurs virtuels.

Serveurs virtuels

Un serveur virtuel, c’est quoi? C’est ce qui permet à Apache de servir plusieurs domaines ou sous-domaines à partir du même serveur. Par exemple, Apache peut servir www.example.com et blog.example.com en même temps. Chacun ayant son propre serveur virtuel.

Le dossier d’Apache

Tout d’abord, dans le dossier de configuration d’Apache, /etc/apache2, il y a, entre autres, les dossiers sites-available et sites-enabled.

Le dossier sites-available contient tous les fichiers de configurations de vos sites web. Pour l’instant, il n’en contient qu’un seul: default, qui dirige vers le dossier /var/www. Nous partirons de ce default pour se créer d’autres serveurs virtuels.

Le dossier sites-enabled contient des symlinks vers les fichiers de configurations contenus dans sites-available. Ces symlinks existent uniquement lorsque ces sites sont actifs. Lorsqu’Apache s’initialise, il vérifie les fichier dans sites-enabled.

Pour activer ou désactiver un site, on utilise les commandes a2ensite et a2dissite.

Créer un serveur virtuel

On commence par aller dans le dossier où les fichiers de configuration se situent:

cd /etc/apache2/sites-available

Ensuite, on se fait une copie du fichier default pour notre premier projet:

sudo cp default projetun

Et on modifie le nouveau fichier:

sudo gedit projetun

Première chose à modifier, c’est le DocumentRoot, c’est à dire, le dossier racine à partir duquel Apache va servir les pages pour ce site web. J’utilise générallement un dossier dans mon home. Quelque chose comme /home/hooba/web/projetun/htdocs. Remplacez donc /var/www par le dossier de votre choix pour ce projet. Remplacez aussi le nom du dossier dans la configuration du dossier en tant que tel quelque lignes plus bas (<Directory /var/www/>).

Ensuite, on veut ajouter le nom de domaine du serveur virtuel. Par défaut, Apache utilisait localhost. Après l’ouverture du tag VirtualHost, ajoutez le nom du serveur que vous voulez utiliser avec ServerName. Par exemple: ServerName projetun.dev.

Le haut de votre fichier devrait donc ressembler à:

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	ServerName projetun.dev
	DocumentRoot /home/hooba/web/projetun/htdocs
	<Directory />
		Options FollowSymLinks
		AllowOverride None
	</Directory>
	<Directory /home/hooba/web/projetun/htdocs>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
	</Directory>
	# ...

Vous pouvez donc sauvegarder le fichier et fermer gedit.

Activer le serveur virtuel

Vous avez maintenant un fichier de configuration prêt à être utilisé dans sites-available. Il faut maintenant laisser savoir Apache qu’il a un nouveau site à servir.

Pour commencer, aller créer un fichier index.html dans le dossier que vous avez spécifié à l’étape précédente. Un fichier très simple suffira. Par exemple:

<html><body>
<h1>Tadam!</h1>
</body></html>

Si vous allez à http://projetun.dev/, vous devriez avoir une erreur du genre « Serveur introuvable ». C’est, en premier lieu, parce qu’Apache n’est pas au courant qu’il doit servir quelque chose à partir de cette URL. On va donc l’avertir qu’il y a un nouveau site:

sudo a2ensite projetun

Cette commande crée le symlink nécessaire dans le dossier sites-enabled. Si vous n’utilisez pas le site default, vous pouvez égallement en profiter pour le désactiver avec:

sudo a2dissite default

Lorsque vous avez fait les modifications nécessaires, vous pouvez dire au daemon Apache qu’il doit recharger sa configuration:

sudo /etc/init.d/apache2 reload

Hosts

Si vous allez à l’adresse http://projetun.dev/, vous aurez la même erreur que tout à l’heure. La raison, c’est que votre navigateur demande à des serveurs DNS « à quelle adresse IP dois-je faire ma requête pour le domaine projetun.dev? ». Comme ces serveurs ne sont pas au courant que vous venez de créer un serveur virtuel, il faut empêcher la demande d’avoir lieu et spécifier immédiatement à quel ordinateur (à quelle adresse IP) on doit faire la requête.

Heureusement, c’est plutôt simple. Il suffit d’ajouter une ligne dans le fichier hosts. Il se situe dans le dossier /etc.

sudo gedit /etc/hosts

Ajoutez simplement une ligne à la fin qui indique votre adresse IP, ainsi que le domaine que vous venez de créer. L’adresse 127.0.0.1 correspond toujours à l’ordinateur sur lequel s’exécute le code. La ligne ajouté ressemblera donc à:

127.0.0.1	projetun.dev

Sauvegardez le fichier et quittez gedit.

Un serveur virtuel fonctionnel

Si vous avez bien suivi les étapes, lorsque vous allez à l’adresse http://projetun.dev/ vous devriez voir le contenu du fichier index.html que vous avez créé tout à l’heure. Vous pouvez donc répéter l’opération pour chacun de vos projets.

Si ça ne fonctionne pas, voici quelques pistes afin de trouver votre problème: avez vous réinitialiser Apache (sudo /etc/init.d/apache2 reload)? Vous pouvez peut-être essayer de le redémarrer au complet avec sudo /etc/init.d/apache2 restart. Est-ce qu’Apache a les droits nécessaires pour accéder au dossier que vous avez spécifié? Est-ce que le fichier projetun existe bel et bien dans /etc/apache2/sites-enabled? Sinon, il faudrait simplement activer le site avec sudo a2ensite projetun. Si le fichier n’apparrait pas (ce n’est pas supposé), vous pourriez toujours essayer de directement faire un symlink vers le fichier dans sites-available.

Logiciel de contrôle de version

Concrètement, ce que ça apporte, c’est de pouvoir toujours modifier notre code sans avoir à se soucier de briser « pour toujours » notre programme. Le fonctionnement de base, c’est qu’on a nos fichier dans un repository. On les télécharge sur notre ordinateur (checkout) pour travailler dessus. Quand on est prêt, on fait un commit: ça met à jour notre repository. Si on continue à travailler sur nos fichier, et qu’on gaffe, on a qu’à reprendre les fichiers du repository.

Jusqu’à date, ça sonne comme un simple backup. Là où le logiciel de contrôle de version prend toute sa force, c’est qu’on a accès à tous les commits qu’on a fait dans le passé. Disons que ça fait 2 jours que je vais dans une direction et que je me rends compte que c’est complètement fou, je peux retourner à l’état où j’étais avant de m’aventurer dans cette branche, même si j’ai fait 2-3 commits depuis ce temps.

Il y a bien d’autres avantages, comme le travail en équipe, la taille TRÈS réduite (comparativement à tous les backups qu’on aurait à faire), les branches et tags.

Subversion gratuit

Subversion est un logiciel gratuit. Donc, si vous voulez, vous pouvez l’installer sur votre ordinateur (pour un accès local) ou sur votre serveur (pour y accéder de partout et avoir la possibilité de partager les repositories). Par contre, ce n’est pas tout le monde qui a accès à un serveur. Et même lorsqu’on y a accès, on ne veut pas toujours s’encombrer de ces fichiers.

Il y a donc quelques compagnies qui offrent l’hébergement gratuit. Entre autres, Google Code et Sourceforge offrent l’hébergement gratuit pour les projets open source. Pour les projets privés, les seuls que je connaissais offrent un seul repository gratuitement (il faut payer pour en avoir plus). Mais aujourd’hui, je suis tombé sur xp-dev.com.

XP-Dev.com

Ils offrent un nombre illimité de repositories, jusqu’à 1500Mo. Ils peuvent être open source ou privés (closed source). Ils offrent aussi une application web pour le suivi de projet, que je n’ai pas encore essayé. Tout ça est gratuit. Vous n’avez donc plus de raison de ne pas utiliser Subversion!

En savoir plus

Pour l’installer sous Ubuntu, vous n’avez qu’à entrer dans votre terminal:

sudo apt-get install svn

Sous Windows ou Mac OS X, je ne l’ai jamais installé, mais je sais qu’il existe des version GUI assez conviviales!

Pour plus de détails visitez ces pages:

• Site officiel de Subversion
• Subversion sur Wikipedia
• Livre gratuit sur Subversion

Méthode GUI

1. Allez dans le panel du haut. System → Administration → Synaptic Package Manager. Vous devrez probablement entrer votre mot de passe.
2. Dans Synaptic Package Manager, dans la toolbar, cliquez sur le bouton Search (ou Edit → Search, ou Ctrl+F).
3. Faite une recherche avec apache comme mot-clé.
4. Dans la liste des résultats, avec le bouton de droit, cliquez sur apache2 → Mark for Installation.
5. Une fenêtre de confirmation risque d’apparraître, avec les paquets nécessaires pour faire marcher Apache. C’est ce qu’on appelle les dependencies. Confirmez l’installation de ces paquets en cliquant sur Mark.
6. Faites une nouvelle recherche avec mysql.
7. Dans la liste, le paquet à installer est mysql-server. Le paquet d’en dessous, mysql-server-5.0, est celui qui installe la version 5.0 spécifiquement, tandis que le paquet mysql-server inclue toujours la version la plus récente (actuellement mysql-server-5.0). Présentement, on veut donc installer mysql-server.
8. Recherchez php.
9. Installez le paquet php5.
10. Recherchez phpmyadmin (un GUI pour MySQL à partir d’un browser).
11. Installez phpmyadmin.
12. Les paquets sont maintenant tous prêts à être installés. Dans la toolbar, cliquez sur Apply.
13. Une fenêtre apparaît pour vous informer des paquets à être téléchargés et installés. Confirmez en cliquant sur Apply.
14. Les paquets seront téléchargés et installés.
15. MySQL vous demandera sans doute un mot de passe pour l’utilisateur root. Entrez un mot de passe que vous n’oublirez pas.
16. phpMyAdmin vous demandera peut-être pour quel serveur le configurer, choisissez apache2.

Méthode Terminal

Si vous optez plutôt pour la méthode (plus rapide) avec le terminal, vous pouvez tout installer d’un coup avec la commande:

sudo apt-get install apache2 mysql-server php5 phpmyadmin

Comme vous le voyez, c’est beaucoup plus rapide. Vous auriez pu procéder individuellement avec sudo apt-get install suivit du nom du paquet que vous voulez installer.

Comme avec la méthode GUI, mysql-server devrait vous demander un mot de passe pour l’utilisateur root, et phpMyAdmin vous demandera pour quel serveur vous voulez le configurer (cochez apache2).

Vérifications

Alors, pour vérifier que tout fonctionne, ouvrez un browser à l’adresse http://localhost/. Vous devriez voir « It works! ». Ensuite, sur le browser d’un autre ordinateur sur le LAN, allez sur http://192.168.0.4/ (remplacez l’adresse IP par l’adresse IP interne de votre nouveau serveur). Vous devriez voir la même page.

Question de sécurité, il serait également intelligent de vérifier que que votre routeur ne permet pas d’accéder à votre serveur à partir de l’extérieur de votre réseau. Pour une vérification simple, dans votre browser, allez à votre adresse IP externe. Si aucune page ne se charge, le tour est joué.

La suite

Le dossier dans lequel Apache va actuellement puiser est /var/www/. Vous êtes maintenant prêts à travailler sur la conception de votre prochain site internet. Dans un prochain article, je vous montrerai comment utiliser un autre dossier et comment gérer ses sites web en développement.