il ne faut pas faire un choix technologique en ayant déjà décidé d'une technologie (parce que a la mode par exemple). C'est une erreur que font beaucoup pour NOSQL, mais aussi inversement de ceux qui étaient supra habitues au SQL et faisaient tout avec (ils n'avaient pas trop le choix ceci dit, mais maintenant ils l'ont).
En d'autres termes, si le schéma que tu en-visionnes pour ton application est fortement relationnel, alors oui va avec du SQL.
Exemples Courants d'utilisation
Second point, il faut aussi voir que SQL et NOSQL ne sont pas forcement a mettre en rapport de force. Ils peuvent être complémentaire et selon l'application, tu peux avoir tout intérêt a utiliser les 2 a la fois.
Exemple extrêmement commun d'un élément totalement non-SQL que l'on trouve sur la plupart des applis web: les sessions. Jusque la, il y avait deux principales facons de gérer les sessions: soit tout dans les cookies (mais cela pose des problèmes de sécurité, car même encryptées, on donne tout de même le temps et toutes les données a l'utilisateur pour s'amuser a décrypter et falsifier des données), soit en bdd. Or une session est en général lue a chaque requête HTTP, et parfois réécrite. Cela fait énormément de requête SQL lentes et non adaptées `a chaque requête HTTP. Les bases NOSQL (en particulier celles "tout en mémoire") sont particulièrement bien adaptes pour stocker les sessions. Et ce, même si le reste des données peut être ds une bdd SQL.
Autre exemple commun: le cache. Dans une application web, diverses données peuvent être mises en cache. Parfois on va même mettre en cache le résultat de requêtes SQL dont on est sur qu'elles sont très lentes a faire, ne changent pas rapidement, mais sont cependant souvent demandées. On la fait donc une fois toutes les X secondes, et on cache le résultat.
Parfois on cache aussi simplement des pages web entières sur le même principe. Cela évite d'avoir a les régénérer et a faire tourner l’interpréteur PHP/python/ruby alors qu'on sait qu'il va générer toujours a peu près la même page. Évidemment on ne va pas mettre en cache une page dont la réactivité au changement est primordiale, mais les pages qui changent relativement peu (sorte de "semi-statique").
Décision
Donc de manière générale, comment on décide si on utilise SQL, NOSQL ou les deux?
Très simple: exactement comme tu faisais jusque la:
* tu réfléchis d'abord a ton application et tu en fais le schéma.
* Si tu réalises que ton schéma est très relationnel (cad que les informations se recoupent sans arrêt d'une table a l'autre, par exemple que tes donnes d'artistes sont intéressantes surtout en les mettant en relation avec les données d’œuvres) et que tu as beaucoup de contraintes d’intégrités a faire (duplication de données, contrainte de valeur sur une colonne…) ou de recherche sur les donnees par divers criteres (recherche sur le nom, sur le style, sur l'age, etc.), alors SQL.
* Si tu réalises que tu as des données très individuelles, qui en général se limitent a être référées `a partir d'un index (recherche toujours sur cet index), alors NOSQL est surement bien plus efficace et logique.
Pour reprendre nos exemple: on cherchera (en général) des données de session par son identifiant (qui se trouvent dans le cookie); on cherchera un cache par la signature de sa requête (un hash de la requête SQL pour un cache de bdd, un hash de l'url pour un cache web, etc.).
Un autre exemple pourrait être le profil utilisateur (comment il a configure son espace perso) dans un site web par exemple. En général, tu vas juste chercher le profil de quelqu'un par son identifiant utilisateur. Tu ne cherches pas a recouper les données. On ne cherche pas trop a récupérer l'ensemble des profils de linuxfr qui utilisent telle CSS (on pourrait vouloir le faire pour des raisons statistiques, mais de manière pratique, cela n'aurait en général pas d’intérêt). On peut la aussi imaginer l'ensemble des données ds du SQL, excepte le profil utilisateur, les sessions, du cache.
Donc ne cherche pas `a faire rentrer du relationnel en NOSQL. Fais juste en sorte de rentrer les bonnes données dans les bons schémas.
Autres caractéristiques du NOSQL
Performances
Les avantages du NOSQL sont nombreux ensuite. Déjà elles sont souvent énormément plus efficaces. En particulier celles qui sont faites pour tourner en mémoire comme memcached ou redis. Cela peut être de l'ordre de 1000 fois plus rapide dans ces cas la (et selon l'utilisation qui est faite sur ton serveur).
Non-Persistance
Ensuite il y a parfois des données changeant énormément ou faite pour ne pas rester longtemps. Dans mes exemples, c’est le cas du cache ou des sessions. Typiquement a l'ancienne en bdd, on va régulièrement nettoyer le cache/sessions pour retirer tout ce qui est un peu trop vieux, par exemple avec un cron qui fait une requete sur la date de création: c'est lent, imprécis, imparfait, ralentit toute la base a intervalle régulier (et encore j'ai vu bien pire comme méthode de "garbage collection" dans une bdd). Alors que (en général) les NOSQL ont ce genre de fonctionnalités incorporées avec la possibilité de donner un "time to live" (ttl) a une donnée.
Par exemple, je crée une session pour un nouvel utilisateur avec un ttl de 1 mois. S'il se reconnecte régulièrement, je repousse son ttl pour rallonger la session. S'il ne se reconnecte plus pendant un mois, la bdd supprime automatiquement la vieille session (et la prochaine fois, l'utilisateur doit se reconnecter pour recréer une session). On donne ainsi la complexité de gestion des durées de vie de ce genre de données a la bdd.
Cela est donc aussi un point a prendre en compte: a quel point tes données doivent être persistantes? Note que si ce sont des données dont la survie n'a aucune importance (suite a un crash par exemple), comme du cache ou a moindre échelle (un peu embêtant, mais pas primordial) des sessions, alors tu peux encore plus accélérer ta bdd NOSQL en ne la sauvant pas sur disque.
Bien sur tu peux aussi être très persistent en NOSQL et sauver constamment tes donnes sur disque quand tu ne peux pas te le permettre, comme tu le fais en SQL. Je dis juste que tu as le choix et que NOSQL devient vraiment un outil de premier ordre quand tu tombes dans ce cas d'utilisation de données temporaires et que tu n'as pas besoin de sauver sans arrêt.
Etc.
Il y a de nombreux autres points qui rendent les NOSQL très intéressantes "pour certaines données". Je crois par exemple que certaines bdds sont capables de libérer automatiquement les données quand ça va dépasser la mémoire machine (de sorte qu'on peut s'arranger pour ne jamais aller en disque).
Aussi sur Redis, j'adore le fait que les donnes peuvent être typées: des listes, des sets, etc. Je pense qu'on peut tous voir a quel point cela peut être pratique, c'est comme pousser du code vers la bdd et rendre les données persistantes (sans avoir pour autant `a remodeler ces données dans une logique relationnelle).
Etc. Etc. Etc.
Chaque NOSQL a ses propres avantages très différents les uns des autres. A toi d’enquêter. :-)
Conclusion
Le NOSQL, c'est vraiment sympa pour certains cas d'utilisations et je pense que ce que l'on verra de plus en plus, c'est un mix de relationnel et de NOSQL.
Par contre pour des applis web très simplistes, je pense qu'on peut voir plus souvent du NOSQL utilise avec succès que du SQL, car souvent les applis simples, cela signifie que les données sont du type clé -> données.
P.S.: excusez moi pour les problèmes d'accent (le correcteur orthographique a pu en corriger certains, pas tous). Je n'ai pas encore configure de touche compose sur ma toute nouvelle machine.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Cas d'utilisations complémentaires
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal NoSQL ou pas ?. Évalué à 10.
Sommaire
Salut,
il ne faut pas faire un choix technologique en ayant déjà décidé d'une technologie (parce que a la mode par exemple). C'est une erreur que font beaucoup pour NOSQL, mais aussi inversement de ceux qui étaient supra habitues au SQL et faisaient tout avec (ils n'avaient pas trop le choix ceci dit, mais maintenant ils l'ont).
En d'autres termes, si le schéma que tu en-visionnes pour ton application est fortement relationnel, alors oui va avec du SQL.
Exemples Courants d'utilisation
Second point, il faut aussi voir que SQL et NOSQL ne sont pas forcement a mettre en rapport de force. Ils peuvent être complémentaire et selon l'application, tu peux avoir tout intérêt a utiliser les 2 a la fois.
Exemple extrêmement commun d'un élément totalement non-SQL que l'on trouve sur la plupart des applis web: les sessions. Jusque la, il y avait deux principales facons de gérer les sessions: soit tout dans les cookies (mais cela pose des problèmes de sécurité, car même encryptées, on donne tout de même le temps et toutes les données a l'utilisateur pour s'amuser a décrypter et falsifier des données), soit en bdd. Or une session est en général lue a chaque requête HTTP, et parfois réécrite. Cela fait énormément de requête SQL lentes et non adaptées `a chaque requête HTTP. Les bases NOSQL (en particulier celles "tout en mémoire") sont particulièrement bien adaptes pour stocker les sessions. Et ce, même si le reste des données peut être ds une bdd SQL.
Autre exemple commun: le cache. Dans une application web, diverses données peuvent être mises en cache. Parfois on va même mettre en cache le résultat de requêtes SQL dont on est sur qu'elles sont très lentes a faire, ne changent pas rapidement, mais sont cependant souvent demandées. On la fait donc une fois toutes les X secondes, et on cache le résultat.
Parfois on cache aussi simplement des pages web entières sur le même principe. Cela évite d'avoir a les régénérer et a faire tourner l’interpréteur PHP/python/ruby alors qu'on sait qu'il va générer toujours a peu près la même page. Évidemment on ne va pas mettre en cache une page dont la réactivité au changement est primordiale, mais les pages qui changent relativement peu (sorte de "semi-statique").
Décision
Donc de manière générale, comment on décide si on utilise SQL, NOSQL ou les deux?
Très simple: exactement comme tu faisais jusque la:
* tu réfléchis d'abord a ton application et tu en fais le schéma.
* Si tu réalises que ton schéma est très relationnel (cad que les informations se recoupent sans arrêt d'une table a l'autre, par exemple que tes donnes d'artistes sont intéressantes surtout en les mettant en relation avec les données d’œuvres) et que tu as beaucoup de contraintes d’intégrités a faire (duplication de données, contrainte de valeur sur une colonne…) ou de recherche sur les donnees par divers criteres (recherche sur le nom, sur le style, sur l'age, etc.), alors SQL.
* Si tu réalises que tu as des données très individuelles, qui en général se limitent a être référées `a partir d'un index (recherche toujours sur cet index), alors NOSQL est surement bien plus efficace et logique.
Pour reprendre nos exemple: on cherchera (en général) des données de session par son identifiant (qui se trouvent dans le cookie); on cherchera un cache par la signature de sa requête (un hash de la requête SQL pour un cache de bdd, un hash de l'url pour un cache web, etc.).
Un autre exemple pourrait être le profil utilisateur (comment il a configure son espace perso) dans un site web par exemple. En général, tu vas juste chercher le profil de quelqu'un par son identifiant utilisateur. Tu ne cherches pas a recouper les données. On ne cherche pas trop a récupérer l'ensemble des profils de linuxfr qui utilisent telle CSS (on pourrait vouloir le faire pour des raisons statistiques, mais de manière pratique, cela n'aurait en général pas d’intérêt). On peut la aussi imaginer l'ensemble des données ds du SQL, excepte le profil utilisateur, les sessions, du cache.
Donc ne cherche pas `a faire rentrer du relationnel en NOSQL. Fais juste en sorte de rentrer les bonnes données dans les bons schémas.
Autres caractéristiques du NOSQL
Performances
Les avantages du NOSQL sont nombreux ensuite. Déjà elles sont souvent énormément plus efficaces. En particulier celles qui sont faites pour tourner en mémoire comme memcached ou redis. Cela peut être de l'ordre de 1000 fois plus rapide dans ces cas la (et selon l'utilisation qui est faite sur ton serveur).
Non-Persistance
Ensuite il y a parfois des données changeant énormément ou faite pour ne pas rester longtemps. Dans mes exemples, c’est le cas du cache ou des sessions. Typiquement a l'ancienne en bdd, on va régulièrement nettoyer le cache/sessions pour retirer tout ce qui est un peu trop vieux, par exemple avec un cron qui fait une requete sur la date de création: c'est lent, imprécis, imparfait, ralentit toute la base a intervalle régulier (et encore j'ai vu bien pire comme méthode de "garbage collection" dans une bdd). Alors que (en général) les NOSQL ont ce genre de fonctionnalités incorporées avec la possibilité de donner un "time to live" (ttl) a une donnée.
Par exemple, je crée une session pour un nouvel utilisateur avec un ttl de 1 mois. S'il se reconnecte régulièrement, je repousse son ttl pour rallonger la session. S'il ne se reconnecte plus pendant un mois, la bdd supprime automatiquement la vieille session (et la prochaine fois, l'utilisateur doit se reconnecter pour recréer une session). On donne ainsi la complexité de gestion des durées de vie de ce genre de données a la bdd.
Cela est donc aussi un point a prendre en compte: a quel point tes données doivent être persistantes? Note que si ce sont des données dont la survie n'a aucune importance (suite a un crash par exemple), comme du cache ou a moindre échelle (un peu embêtant, mais pas primordial) des sessions, alors tu peux encore plus accélérer ta bdd NOSQL en ne la sauvant pas sur disque.
Bien sur tu peux aussi être très persistent en NOSQL et sauver constamment tes donnes sur disque quand tu ne peux pas te le permettre, comme tu le fais en SQL. Je dis juste que tu as le choix et que NOSQL devient vraiment un outil de premier ordre quand tu tombes dans ce cas d'utilisation de données temporaires et que tu n'as pas besoin de sauver sans arrêt.
Etc.
Il y a de nombreux autres points qui rendent les NOSQL très intéressantes "pour certaines données". Je crois par exemple que certaines bdds sont capables de libérer automatiquement les données quand ça va dépasser la mémoire machine (de sorte qu'on peut s'arranger pour ne jamais aller en disque).
Aussi sur Redis, j'adore le fait que les donnes peuvent être typées: des listes, des sets, etc. Je pense qu'on peut tous voir a quel point cela peut être pratique, c'est comme pousser du code vers la bdd et rendre les données persistantes (sans avoir pour autant `a remodeler ces données dans une logique relationnelle).
Etc. Etc. Etc.
Chaque NOSQL a ses propres avantages très différents les uns des autres. A toi d’enquêter. :-)
Conclusion
Le NOSQL, c'est vraiment sympa pour certains cas d'utilisations et je pense que ce que l'on verra de plus en plus, c'est un mix de relationnel et de NOSQL.
Par contre pour des applis web très simplistes, je pense qu'on peut voir plus souvent du NOSQL utilise avec succès que du SQL, car souvent les applis simples, cela signifie que les données sont du type clé -> données.
P.S.: excusez moi pour les problèmes d'accent (le correcteur orthographique a pu en corriger certains, pas tous). Je n'ai pas encore configure de touche compose sur ma toute nouvelle machine.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]