Hooba Studios » SQL

MongoDB et autres bases de données NoSQL, le début d’une nouvelle ère

Antoine Leclair — Mon, 07 Sep 2009 16:39:45 +0000

Depuis le printemps dernier, on entend parler de plus en plus du mouvement NoSQL. Pour ceux qui auraient eu la tête dans le sable pendant les derniers mois, il s’agit d’un mouvement qui cherche à trouver d’autres solutions pour la gestion des données que les RDBMS (bases de données relationnelles, à la MySQL / SQL Server). C’est donc le retour en force des bases de donnée key/value pair et autres formes de bases de données sans schéma.

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!

Bon code, Bad code

Antoine Leclair — Fri, 17 Jul 2009 03:19:15 +0000

Il n’y a pas si longtemps, j’ai eu à intégrer du code PHP qu’un autre programmeur avait déjà fait pour un autre site. Le client tenait à ce que j’utilise son « module » de nouvelles en pensant sauver de l’argent. La première fois que j’ai eu à intégrer ledit module, ç’a effectivement été plutôt rapide étant donné que le site était fait dans le même pattern que le site d’origine. Par contre, la deuxième fois, c’était une toute autre chose!

Du code non-réutilisable

J’espère ne rendre personne triste en publiant cet article, mais je vais vous faire un petit copier-coller d’une fonction pour illustrer mes points.

=".$date_start." AND date_news<".$date_end;
        }
    }
    if(!isset($query)){
        $query = " ORDER BY date_news DESC LIMIT 3";
    }else{
        $query .= " ORDER BY date_news DESC";
    }

    $query = "SELECT * FROM juris_news".$query;
    $result = mysql_query($query) or die(mysql_error());
    if(mysql_num_rows($result) > 0){
        for($i = 1; $row = mysql_fetch_array($result); $i++){
?>
    ">
    
    
    " id="news" />
Aucune actualité trouvée.");
    }
}

Il s’agit ici de la première fonction d’une dizaine de fonctions similaires qui constituent le fichier.

Premier péché: mélanger la logique avec la présentation

La principale force de PHP est aussi sa principale faiblesse: il est très facile de mélanger du PHP avec du HTML. On peut avoir une page entière en HTML et y insérer très facilement un peu de PHP. On peut par contre aussi avoir du PHP et y insérer du HTML. Le problème avec cette fonction, c’est qu’elle génère (et affiche) du HTML.

On peut voir très facilement que le code HTML affiché n’est pas réutilisable. Il y a des appels à des fonctions JavaScript et des images dont le chemin d’accès est hard coded. Par exemple, la fonction affiche:

// mauvais
" id="news" />

Il est fort peu probablement que j’aie à utiliser les mêmes fonctions JavaScript et que j’utilise les mêmes images. Aussi, le markup HTML généré ne conviendra générallement pas aux besoins d’un autre site. Par exemple, je doute que

puissent être réutilisé.

La meilleur façon aurait été de simplement arrêter la fonction à la fin de la requête SQL. La fonction aurait simplement pu retourner un array, un objet ou un itérateur. De cette manière, on sépare la logique de la présentation. Par exemple, si la fonction retournait un array $nouvelles, on pourrait l’intégrer dans la page directement.




    Nouvelles
    
    
    
    
    En savoir plus
    
    
    Aucune nouvelle

Deuxième péché: La fonction n’accepte aucun paramètre

De la façon dont la fonction est codée, on n’a aucun moyen externe (lire: aucun paramètre) d’affecter son déroulement. Si $_GET['search'] contient quelque chose, une recherche sera faite, sinon, les trois dernières nouvelles sont affichées.

Il serait bien de pouvoir appeler la fonction en lui demandant un certain nombre de nouvelles. Je ne veux pas avoir toujours les trois dernières nouvelles dans tous les sites que je dois faire.

Aussi, si je veux faire une recherche, je ne veux pas nécessairement utiliser $_GET['search'] comme chaine à chercher.

Le prototype de cette fonction aurait plutôt dû ressembler à ceci:

function fct_display_news_list($quantity = 3, $search = NULL)

De cette manière, on aurait pu avoir des comportements par défaut si on ne passe aucun argument tout en ayant un certain contrôle en cas de besoin. Si je voulais à ce moment utiliser la fonction en utilisant la valeur de $_GET['search'] comme clé de recherche, j’aurais pu l’appeler ainsi:

fct_display_news(3, $_GET['search'])

Troisième péché: la fonction fait trop de choses

La fonction « raboute » des morceaux de requêtes SQL en créant la fin de la requête ("WHERE ...") en premier. Je trouve étrange d’avoir commencé par la fin sans raison apparente. Ça ne fait que complexifier le code.

En plus, pourquoi ne pas avoir simplement séparé la fonction en deux fonctions? Chaque fonction aurait été beaucoup plus claire et facile à maintenir. Exemple:

// mieux
function get_news($quantity = 3, $search = NULL){
    if ($search == NULL)
        return get_latest_news($quantity);
    else // $search != NULL
        return get_searched_news($quantity, $search);
}

function get_lastest_news($quantity = 3){
    // fonction qui retourne les $quantity dernières nouvelles
    // ...
}

function get_searched_news($quantity = 3, $search = NULL){
    // fonction qui retourne les $quantity dernières nouvelles trouvées selon la clé de recherche
    // ...
}

Si on regarde la liste des fonctions du fichier, on se rend vite compte qu’une approche orienté objet aurait très bien fait la job. Une classe News aurait grandement simplifié le tout.

Quatrième péché: des noms qui ne veulent rien dire

Si on retourne dans le code au début de l’article, on peut voir qu’il y a plusieurs noms encombrés d’abréviations superflues ou qui ne veulent rien dire aux yeux de la prochaine personne qui touche le code.

Est-ce que j’ai vraiment besoin de spécifier dans le nom d’une fonction qu’il s’agit d’une fonction en y préfixant fct? Aussi, un fichier nommé img_c_btn_savoir_up.gif: un fichier gif est une image, pas besoin de préfixer img à son nom. Dans le même nom de fichier, que veut dire le « c« ?

Une fonction devrait avoir un nom qui permet de savoir ce qu’elle fait tout en étant concis. display_news_list aurait été suffisant.

Cinquième péché: être vulnérable aux injections SQL

Étant donné que la fonction n’accepte aucun paramètre, le programmeur a utilisé la valeur de $_GET['search'] directement dans sa fonction. Le problème que je veux souligner ici c’est la manière dont il l’a utilisée. Il l’a mis directement dans une requête sans la filtrer:

// mauvais
$query = " WHERE title LIKE CONVERT(_utf8 '%".$_GET['search']."%' USING latin1) OR content LIKE CONVERT(_utf8 '%".$_GET['search']."%' USING latin1)";

En insérant directement des valeurs fournies par l’utilisateur (ici, dans la barre d’adresse) sans les avoir filtrés au préalable est une mauvaise pratique car elle ouvre très grand les portes aux attaques par injection SQL.

En conclusion

Quand on programme, c’est important de toujours penser à la réutilisabilité du code. Il faut bien sûr parfois faire du code « quick and dirty« , mais les choses importantes que je viens d’énumérer ne sont pas compliqués à respecter. D’ailleurs, le programmeur aurait en fait sauvé du temps s’il avait fait du code réutilisable, car il a eu à reprogrammer un autre ensemble complet de fonctions pour le côté administrateur. S’il avait dès le départ fait une nouvelle classe ou simplement mieux conçu ses fonctions, il aurait facilement pu sauver beaucoup de temps en réutilisant lui-même son propre code à l’intérieur du même projet.

Prévenir les injections SQL avec PHP et MySQL

Antoine Leclair — Tue, 20 Jan 2009 19:12:44 +0000

Tout d’abord, pour ceux qui ne savent pas ce qu’est une attaque SQL, je vous fais une brève explication.

Exemple d’attaque par injection SQL

Une personne mal intentionnée peut tenter d’abuser votre code PHP en insérant des morceaux de SQL à des endroits que vous vous n’y attendez pas sur votre site web. Par exemple, une page qui montre les produits d’une certaine catégorie à l’aide d’un paramètre GET. Une version simplifiée de votre code pourrait ressembler à ceci:

query($query);
// ... suite du code ...
?>

Avec $_GET['category']='rasoirs', la requête ressemblerait à ceci:

SELECT * FROM products WHERE category="rasoirs"

Si l’utilisateur réussi à passer $_GET['category']='rasoirs" OR 1=1', la requête se fait transformer en quelque chose du genre:

SELECT * FROM products WHERE category="rasoirs" OR 1=1

L’exemple ici n’est pas si dangereux, mais on peut facilement imaginer des requêtes du genre:

UPDATE products SET en_special="1" WHERE category="rasoirs"

devenir des requêtes du genre:

UPDATE products SET en_special="1" WHERE category="rasoirs" OR 1=1

Regardez cet exemple concret d’une attaque par injection SQL .

Comment on faisait pour éviter ce problème

Une pratique encore valide aujourd’hui est de ne jamais mettre directement des données entrées par un utilisateurs à des endroits qui pourraient affecter de manière nuisible le programme. Dans l’exemple précédent des catégories, on aurait pu faire quelque chose qui ressemble à:

switch($_GET['category']){
  case 'rasoirs':
    $query = 'SELECT * FROM products WHERE category="rasoirs"';
    break;
// etc.
}

Bien sûr, on doit souvent utiliser les entrées de l’utilisateurs pour fabriquer des requêtes. Il faut alors filtrer ce que l’utilisateur envoie, avec des fonctions du genre mysql_real_escape(). Mais cette fonction peut maintenant être compté comme désuette grâce à la compilation des requêtes.

Nouvelle façon

Grâce aux nouveaux (okay, pas si nouveau) compiled statements (requêtes compilées), on peut désormais être certain que l’utilisateur ne réussira pas à déborder hors de ce qu’on avait prévu initiallement. Voici un exemple:

$query = 'INSERT INTO users (name, password, date_added) '
        .'VALUES (?, ?, ?);
$stmt = $mysqli->prepare($query);
if ($stmt){
  $stmt->bind_param('ssi', $name, $password, $date_added);
  // s pour string, i pour integer
  $stmt->execute();
}

La requête SQL est donc compilée avant même de savoir ce qui se tiendra à la place des ?. On ne fait qu’assigner plus tard ce qui les remplacera.

Premier avantage, qui est le sujet de mon article, est que ça prévient les attaques SQL. Dans l’exemple des catégories de produits ci-haut, même si l’utilisateur réussissait à assigner une valeur du genre rasoirs" OR 1=1 à notre variable qui ira dans notre requête SQL, la requête était déjà compilée. La requête aura donc l’effet de celle-ci:

SELECT * FROM products WHERE category="rasoirs\" OR 1=1"

Elle cherchera donc RÉELLEMENT les produits appartenant à la catégorie rasoirs" OR 1=1 (qui n’existe pas).

Deuxième avantage des requêtes précompilées, c’est que si vous avez à exécuter plusieurs requetes dont seulement certain paramètres changent, en ne compilant qu’une seule fois la requête et en l’exécutant avec différentes variables, vous sauver du temps-machine. Lorsque vous y allez « à l’ancienne », le requête est compilée à chaque fois.

Conclusion et liens

La plupart des bases de données offrent aujourd’hui la possibilité de compiler ses requête à l’avance et je trouve que c’est une excellente pratique de profiter de cette fonctionnalité.

Les PDO (PHP Data Objects) n’offrent qu’une abstraction très mince au-dessus des bases de données. Ils n’offrent générallement pas de fonctionnalités ajoutées. Pourtant, les concepteurs ont décidé d’implémenter dans les PDO la possibilité de compiler ses requêtes même lorsque la base de donnée utilisée ne l’accepte pas! Ils s’en chargent pour nous. Pour vous dire à quel point c’est important.

Si vous voulez un peu plus d’information sur les attaques SQL, vous pouvez lire cette page de Wikipedia et cette page web.