Journal NoSQL ou pas ?

Posté par Spack le 29 avril 2012 à 22:53. Licence CC By‑SA.

Étiquettes :

avr.

2012

Je cherche à faire quelques projets orientés Web. Pour donner une idée, je compte partir sur deux projets :

Un gestionnaire de noms de domaines genre Domain Portfolio Manager
Et un lecteur multimédia en ligne genre streeme

Le but est de redécouvrir les technologies Web, un monde qui bouge beaucoup ces derniers temps, et enfin de me lancer avec Django.

La nouvelle mode des bases NoSQL me pousse à réfléchir sur l'utilisation de celles-ci. Cependant, étant sûrement trop formaté au modèle relationnel, je n'arrive pas à me faire une idée précise des cas d'utilisations. Et je dois avouer que parcourir le Web ne m'a pas vraiment aidé à y voir plus clair.

La première chose à faire lorsque l'on prépare sa base relationnelle est d'établir les différents types de données puis de les lier par leurs relations. Avec MongoDB, on stocke le tout dans un document mais on perd le côté relationnel. De plus, un bon nombre de bases NoSQL s'affranchissant des propriétés ACID, selon moi, une certaine partie de la complexité se retrouve déléguée à la partie applicatif.

Exemple, en utilisant MongoDB, comment s'assurer que chaque artiste entré est unique ? Si je commence à mettre une référence vers le « document » artiste pour chaque fichier audio, je fais du relationnel et donc autant utiliser une base relationnel.

En bref, quels sont les cas d'usages de ces types de bases de données ?

# Forum

Posté par Spack le 29 avril 2012 à 22:59. Évalué à 7.

Bon ben, je pensais poster dans le forum mais je me suis trompé… :s
# Cas d'utilisations complémentaires

Posté par Jehan (site web personnel, Mastodon) le 30 avril 2012 à 05:26. É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 ]
- [^] # Re: Cas d'utilisations complémentaires
  
  Posté par claudex le 30 avril 2012 à 08:25. Évalué à 5.
  
  Merci pour ce commentaire très intéressant. J'aimerais cependant un complément d'information. Les deux exemples que tu donnes sont des exemples clef-valeur pour lesquels j'imagine très bien l'énorme avantage sur du SQL, aurais-tu d'autres exemple avec d'autres types de base de données NoSQl?
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Cas d'utilisations complémentaires
    
    Posté par claudex le 30 avril 2012 à 09:45. Évalué à 4.
    
    Bon, j'ai fais un peu de recherche, et, d'après ce que j'ai compris, les base de données orientées document sont destinées aux documents qui ont une partie de leur structure commune (sinon, ça n'a pas d'intérêt de les stocker de manière structurée) mais pas toute.
    
    Par exemple, on stocke différentes publications (articles, livre…) qui ont des attributs commun (nombre de pages, auteur…) mais aussi des différents (numéro de la revue…). (Mon exemple n'est pas très bien choisi, vu qu'il y a un nombre limité et restreint de type de documents et que les base de données orientées documents sont justement adaptées quand il y a beaucoup de type documents différent ou un nombre inconnu)
    
    Pour les base de données orientées colonnes, l'intérêt de stocker par colonne et non par ligne, ce qui permet de récupérer plus facilement les données d'une colonne (par exemple, tous les auteurs enregistrés dans la base de données).
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Cas d'utilisations complémentaires
      
      Posté par claudex le 30 avril 2012 à 11:19. Évalué à 7.
      
      Si ça intéresse des gens, j'ai commencé une dépêche pour essayer d'expliquer tout ça http://linuxfr.org/redaction/news/petit-etat-des-lieux-du-nosql
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Cas d'utilisations complémentaires
        
        Posté par Anthony Jaguenaud le 30 avril 2012 à 11:38. Évalué à 1.
        
        C’est une bonne idée, car moi, je ne vois pas trop la différence d’un NO-SQL version RAM avec clé—valeur et un objet MAP C++…
        
        [^] # Re: Cas d'utilisations complémentaires
        
        Posté par claudex le 30 avril 2012 à 11:43. Évalué à 3.
        
        Tu peux mettre ton memcached sur un serveur dédié (ou plusieurs), ça permet d'écrire la valeur par un serveur applicatif et de la récupérer par un autre, c'est très intéressant pour les sessions.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Cas d'utilisations complémentaires
        
        Posté par barmic le 30 avril 2012 à 13:57. Évalué à 2.
        
        En principe tu peux indiquer la durée de vie des données mises dans Reddis par exemple. Il y a aussi que ça peut être mutualisé entre plusieurs instance de ton application.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Cas d'utilisations complémentaires
    
    Posté par Jehan (site web personnel, Mastodon) le 01 mai 2012 à 04:35. Évalué à 1. Dernière modification le 01 mai 2012 à 04:37.
    
    Je cite les clés -> valeurs car c'est le principal point commun des NOSQL, de manière générale. Aussi j'ai surtout utilisé Redis, donc ceci explique cela.
    
    Mais oui certaines NOSQL permettent des formes de structures (les "documents"), et même une recherche SQL-like, a ce que j'ai lu. Ou bien ils ont d'autres formes de recherche (des "vues" dans couchdb).
    C'est donc vraiment dur de faire des généralités car il n'y a pas ou peu de "standard NOSQL". Si tu veux faire les choses bien, tu devrais en gros lire (en diagonal au moins) toutes les docs avant de te lancer.
    
    Pour parler du stockage par "document", un point souvent soulevé pour leur usage est en effet si ces documents ont des champs très variables.
    Par exemple, si tes livres ont tous un titre, un auteur, un numero de reference, et un style, c'est facile. Mais parfois tu veux plusieurs auteurs, tu veux un sous-titre, tu veux mettre plusieurs titres ou styles, voire certains livres n'ont pas d'auteur connu, ni de titre, etc. Et certains livres ont des caractéristiques uniques assez rares, mais on veut tout de meme avoir une structure pour ces données rares.
    On a vu de tout dans l'histoire de la littérature.
    
    C'est en effet souvent un avantage soulevé de certaines NOSQL. A toi de voir si tes données sont de ce genre. Et a toi de verifier tes besoins de recherche et les possibilites de recherche/vues que te donne la bdd.
    
    Enfin ne jamais oublier que mélanger les bdds est aussi un choix valable pour t'adapter a tes donnees.
    
    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
    - [^] # Re: Cas d'utilisations complémentaires
      
      Posté par Yves (site web personnel) le 02 mai 2012 à 10:31. Évalué à 0.
      
      Ce que dit Jehan sur les NOSQL orientées Documents me fait fortement penser à LDAP.
      LDAP serait-il un exemple de base NOSQL ?
      - [^] # Re: Cas d'utilisations complémentaires
        
        Posté par Sytoka Modon (site web personnel) le 03 mai 2012 à 14:03. Évalué à 2.
        
        LDAP est plutôt un exemple de base SNMP tellement le lien entre les deux est proche.
- [^] # Re: Cas d'utilisations complémentaires
  
  Posté par Spack le 30 avril 2012 à 09:26. Évalué à 4. Dernière modification le 30 avril 2012 à 09:28.
  
  Merci, j'y vois plus clair maintenant. Il faut juste pouvoir identifier chaque cas d'utilisation.
  
  Chaque NOSQL a ses propres avantages très différents les uns des autres. A toi d’enquêter. :-)
  
  Pas très daycideurpressé™ friendly tout ça. Avant il suffisait de dire : « on prend un SGBDR ça ira », et ce sans même connaître la signification de SGBDR. Maintenant on nous oblige à réfléchir à ce que l'on veut faire et étudier la bonne solution, ça va me coûter du j/h…
  - [^] # Re: Cas d'utilisations complémentaires
    
    Posté par Papey le 01 mai 2012 à 16:49. Évalué à 0.
    
    Tu veux sans doute parler de j*h plutôt que j/h
# Index

Posté par Duncan Idaho le 30 avril 2012 à 05:31. Évalué à 6.

Exemple, en utilisant MongoDB, comment s'assurer que chaque artiste entré est unique ?

ensureIndex est ton ami. C'est tres puissant et tu as meme des petites sucreries, notamment la recherche spatiale en deux dimensions.

D'une facon generale, tu as raison: la complexite se retrouve deleguee a la partie applicatif. En fonction de ton application ca peut etre un probleme ou pas.

D'un autre cote, le modele document offre une vraie facilite d'utilisation, ca torche un max et les requetes (acces/insertion/mise a jour) sont un bonheur a ecrire et a utiliser (la encore, je parle de MongoDB que j'utilise massivement pour un projet web).
# Inspiration

Posté par AhmetD (site web personnel) le 30 avril 2012 à 08:52. Évalué à 1.

J'ai été bluffé par le code de sebsauvage. Il encode tout en base 64 et stock tout en php (shaarli) ou json (zerobin). Tu devrais jeter un oeil sur son github https://github.com/sebsauvage ou directement son site.
En tout cas, pour mes futurs petites applis j'utiliserai son modèle.
Je ne connaissais pas MongoDB, merci !
- [^] # Re: Inspiration
  
  Posté par BohwaZ (site web personnel, Mastodon) le 30 avril 2012 à 15:40. Évalué à 1.
  Difficile de faire plus efficace et rapide que ça en PHP en tt cas :
```
file_put_contents('cache.php', '<?php $data = '.var_export($data, true).'; ?>');

include 'cache.php';
```
  « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
  - [^] # Re: Inspiration
    
    Posté par BohwaZ (site web personnel, Mastodon) le 30 avril 2012 à 16:24. Évalué à 3.
    
    Par contre pour stocker des données dans une vraie base de données, je conseille très fortement SQLite (objet SQLite3 ou PDO en PHP), c'est très rapide, très efficace et très pratique à utiliser (rien à configurer), et les données sont très facilement sauvegardables et réutilisables, au contraire d'un format bricolé genre base64 d'un tableau php… JSON est plus lent, et en PHP dès qu'il y a une erreur d'encodage dans le fichier source il est impossible de récupérer les données, ça retourne rien… Donc faut être super prudent.
    
    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Mon expérience...

Posté par case42 (site web personnel) le 30 avril 2012 à 11:38. Évalué à 4. Dernière modification le 30 avril 2012 à 11:40.

Je ne suis pas du tout expert en la matière mais voici tout de même quelques data points qui peuvent être intéressants.

Y a deux ans on utilisait Django+Postgres , et on a voulu essayer Django+NoSql (je sais plus laquelle, probablement couchdb) parce que le coté schema-less avait l'air de bien coller avec nos méthodes de développement agiles, ou plutôt, le paradigme "a schéma" de sql venait tout le temps nous ralentir parce qu'on changeait tout le temps de schéma, et donc on voulait voir si l'herbe était plus verte en face. A l'époque, c'était pas le cas, et on est vite vite revenu chez mémé.

Plus tard, on a bazardé Django et Postgres et on est passé a Node.js sans base de donnée du tout (pour ceux qui suivent pas, on fait un serveur de jeu temps-réel). Un beau jour on a voulut commencer a collecter des statistiques sur nos parties, et je me suis dit qu'une base NoSql serait pas mal pour ca. Donc j'ai mis en place une couchdb, et avec quelques lignes dans le serveur (sans même rajouter un module dédié vu que c'est une API REST) , celui-ci pousse un gros document JSON avec toutes les données de la partie dans le couchdb.

Ça avait été rapide et facile, j'étais plutôt content. Plus tard je me suis mis écrire des "vues" couchdb pour commencer a faire remonter des infos intéressantes du couchdb. Ça a été un peu galère au début, mais globalement j'ai réussi a faire ce que je voulais faire sans trop souffrir ( et quand t'écris ta première vue map/reduce qui marche, t'es content ;) ).

Et puis un jour, ca c'est mis a plus marcher. Le serveur continuant et bourrer la DB de documents, mais toutes les vues étaient cassées. A force de recherche je me suis rendu compte que suite a un changement dans le serveur, les documentes envoyées dans la DB avaient beaucoup grossis et dépassaient une limite interne de couchdb. Il fallut que j'applique un patch trouve au fin fond d'une obscure mailing-list pour que ca remarche. Autant dire que c'était pas très agréable et que ca donne pas énormément confiance.

Depuis ca re-marche bien sans aucun problème, si ce n'est un problème de performance qui était causé par la façon naïve dont j'avais écrit une de mes vues, un passage par #couchdb sur freenode a résolut le problème en quelques minutes.

Si c'était a refaire, je le referais, sauf que je pense que je prendrais plus de temps a peser le pour et le contre entre couchdb et mongodb . Je pense que mongodb aurait été plus adapté a cette application ou on ne fait que "bourrer" une DB de documents sans jamais les updater , mais j'aurais été obligé de rajouter une dépendance a mon serveur vu que mongodb n'a pas d'API REST.
- [^] # Re: Mon expérience...
  
  Posté par devnewton 🍺 (site web personnel) le 30 avril 2012 à 12:57. Évalué à 2.
  
  pour ceux qui suivent pas, on fait un serveur de jeu temps-réel
  
  Avec un tel teaser, une URL aurait été bienvenue!
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: Mon expérience...
    
    Posté par case42 (site web personnel) le 30 avril 2012 à 14:17. Évalué à 2.
    
    Désolé on est pas vraiment released encore, j'ai peur d'interférer avec la stratégie marketing de la boite qui n'est pas de mon ressort. Le jour ou on sera vraiment live, promis j'écris un journal :)
- [^] # Re: Mon expérience...
  
  Posté par barmic le 30 avril 2012 à 14:23. Évalué à 2.
  
  Si c'était a refaire, je le referais, sauf que je pense que je prendrais plus de temps a peser le pour et le contre entre couchdb et mongodb . Je pense que mongodb aurait été plus adapté a cette application ou on ne fait que "bourrer" une DB de documents sans jamais les updater , mais j'aurais été obligé de rajouter une dépendance a mon serveur vu que mongodb n'a pas d'API REST.
  
  Je ne sais pas pour mongo, mais couch ne fait jamais de mise à jour de manière automatique, il faut lancer régulièrement une commande pour que le fichier qui contient les document soit vidé des fichiers obsolète. Donc je pense que couch est tout de même très porté sur ce genre d'usage.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# entités

Posté par steph1978 le 30 avril 2012 à 14:39. Évalué à 5. Dernière modification le 30 avril 2012 à 14:41.

Le commentaire de Jehan est très intéressant mais il l'illustre par des cas d'usage très particuliers et plutôt techniques.

Pour ma part je partirai d'un raisonnement inverse: pourquoi faire du relationnel si je n'en ai pas besoin.
Le relationnel (premier réflexe de modélisation surtout chez les DBA) est très contraignant (jointures) et ne correspond que rarement à la réalité de ton application.
Beaucoup d'applications manipulent des entités riches (comprendre beaucoup d'attributs et des collections imbriquées) mais qui n'ont que très peu de relations entre elles.
Du coup, des bases de données type document ou objet sont tout à fait adaptées et évitent le calvaire du mapping relationnelobjet et de la mise à l'échelle.

J'ai eu un débat à ce sujet avec un DBA. Il soutenait que le modèle relationnel répondait très bien à tous les cas de figure en général. Je soutenais que le modèle relationnel était le modèle par défaut car poussé par les éditeurs (Oracle) et qui rassurait les décideurs mais qu'il ne résistait pas longtemps à l'analyse.
En posant le problème comme suit: quel est l'intérêt de stocker d'un côté (table) toutes les lignes de factures ensemble et d'un autre côté toutes les entêtes de factures ensemble alors qu'il y a une relation 1-N entre une entête et ses lignes.
Il n'a jamais répondu. En fait, si, il a répondu, après un grand blanc, que cela facilitait le compte des ventes par produit ! autrement dit cela facilite un autre cas d'usage (analyse décisionnel) que le cas métier principale (stocker et consulter des factures).

Bref, maintenant que de bon outils existent, MHA est qu'il ne faut pas raisonner "relationnel" par défaut. Et qu'il ne faut pas hésiter à multiplier les points de vues sur les données en fonction des cas d'usages.
- [^] # Re: entités
  
  Posté par claudex le 30 avril 2012 à 14:46. Évalué à 7.
  
  Un gros avantage du SQL, c'est la disponibilité de bibliothèque dans tous les langages (quand ce n'est pas inclus dans la lib standard), alors que pour le NoSQL, c'est plus aléatoire en fonction du langage et du système de base de données choisi.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: entités
    
    Posté par AhmetD (site web personnel) le 30 avril 2012 à 15:28. Évalué à 4.
```
mongodb.org Supported :
C
C++
Erlang
Haskell
Java
Javascript
.NET (C# F#, PowerShell, etc)
Node.js
Perl
PHP
Python
Ruby
Scala
```
- [^] # Re: entités
  
  Posté par Sytoka Modon (site web personnel) le 30 avril 2012 à 15:42. Évalué à 1.
  En programmation objet (un peu le standard de nos jours), tu as des classes ayant des attributs. Il y a en gros deux manières d'enregistrer cela dans un langage :
  - soit sous forme classique de type. N objets donnent N version en mémoire du type T
  - soit sous forme inside/out. Chaque attribut est enregistré dans une structure propre et l'objet y accède via une clef.
  http://search.cpan.org/~dagolden/Class-InsideOut-1.10/lib/Class/InsideOut/Manual/About.pod
  
  L'utilisation d'une base de données SQL pour faire de l'objet est un mode de pensée très clairement inside/out alors que les base NoSQL sont dans le schéma classique.
- [^] # Re: entités
  
  Posté par Jehan (site web personnel, Mastodon) le 01 mai 2012 à 04:13. Évalué à 5. Dernière modification le 01 mai 2012 à 04:15.
  
  Salut,
  
  comme je disais, cela dépend beaucoup de ton usage. Pour les factures, cela dépend donc si tu veux juste les stocker, puis les lister ensuite dans l'ordre par exemple, ben oui du NOSQL fait l'affaire. Par contre, si ton but est ensuite de faire des recherches dedans (ce que je peux parfaitement imaginer pour des factures) selon divers critères, alors SQL peut sembler plus adapté.
  Néanmoins certains bdd NOSQL ont aussi des possibilités de requêtes avancées (MongoDB apparemment par exemple), autre que sur la clé.
  Mais si le programme est plus évolué que le stockage de factures, car il liste aussi les utilisateurs, et des produits, etc. En gros, on crée des relations entre les diverses données. SQL semble de plus en plus adapté.
  
  Je dirais donc que cela dépend énormément de ton application, ou de ce que tu la vois devenir (car elle peut être simple au début, mais si tu as des plans pour le futur, autant ne pas te mettre des bâtons dans les roues au début).
  
  Enfin pour reprendre ta réponse a ton DBA qui te dit a juste titre que SQL facilite le compte de vente par produit, tu sembles penser que c'est une réponse a cote de la plaque. Mais je pense au contraire que c’était une excellente réponse. L'analyse décisionnel, les statistiques ou la recherche d'information peut être le but même de l'application. Tu ne peux pas dire "ah non, le métier d'une bdd, c'est juste de stocker bêtement! On va pas se mettre a analyser les données non plus!" Donc si ton application requiert ce genre d'usage et que ta bdd NOSQL ne le permet pas (encore une fois, certaines ont des fonctionnalités de recherche avancées, donc certaines le peuvent peut-être), alors c'est un mauvais choix.
  Il n'y a pas de "cas métier principale". Il y a juste une décision logique suivie par applicative.
  
  Comme je disais, il ne faut pas se borner a un choix technologique avant même d'avoir mis a plat tes besoins. On doit faire l'inverse: décrire les besoins et les choix technologiques en découlent.
  
  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: entités
    
    Posté par steph1978 le 01 mai 2012 à 10:57. Évalué à 2.
    
    Comme je disais, il ne faut pas se borner a un choix technologique avant même d'avoir mis a plat tes besoins. On doit faire l'inverse: décrire les besoins et les choix technologiques en découlent.
    
    Nous sommes au moins d'accord sur le méthode: c'est le besoin qui doit guider le modèle et la techno et pas l'inverse.
    
    Je t'assure que sur le projet auquel je me référais, le modèle relationnel nous faisait suer sang et eau au quotidien. Et je pense toujours que c'est un mauvais réflexe.
# Top !

Posté par rakoo (site web personnel) le 30 avril 2012 à 23:24. Évalué à 8.

Comme tout le monde, je suis la mode et je m'intéresse aux bases de données NoSQL. Celle que je connais le mieux pour l'avoir déjà utilisée est CouchDB. Je ne vais pas te présenter cette solution, mais je peux te donner un petit retour de ce que j'ai vu, et de ce que j'aime:

REST

L'interface par défaut de CouchDB, c'est tout simplement du HTTP utilisée REST tout proprement. Pour déposer un document, un simple PUT suffit; pour en obtenir un autre, GET.

CouchDB fait l'effort de marcher avec du HTTP de base, sans ajouter de surcouche qu'il serait le seul à comprendre. Du coup, n'importe quel langage sait parler à CouchDB si il sait parler le standard. En fait, tout ce que tu fais, c'est du CRUD standard, le fameux Web 2.0 (enfin c'est l'explication la plus rationnelle que je vois à cette appellation)

Oh, bien sûr, ce n'est pas la seule base de données à le faire, mais puisque c'est son interface par défaut, j'ai tendance à penser que c'est lui qui le fait le mieux (Note : je n'ai testé aucune alternative, donc ce que je viens de dire peut très bien être pris à la légère). Le corollaire de ça, c'est :

Futon, l'interface d'administration

Elle est directement dans la base de données, et accessible avec un simple navigateur Web. Et quand je dis administration, c'est autant administration du serveur qu'administration des différentes bases de données. En fait, si tu veux te servir de couchDB pour stocker tes données personnelles (Ce qui était le but de desktopcouch), tu peux même aller directement les éditer à la main dans cette interface, ou en ajouter de nouvelles. Ceci avec la version de base de CouchDB, sans rien installer de plus.

Les CouchApps

Un site web, finalement c'est quoi ? C'est juste une ou plusieurs pages HTML avec quelques N'images. Et pour récupérer des documents dans CouchDB, tu fais un GET sur une base de données, c'est à dire exactement la même chose que quand tu vas sur DLFP pour troller dans la joie et la bonne humeur.

Partant de là, les couchapps sont une collection de fichiers placés dans une base de données, avec quelques subtilités (vraiment, rien de compliqué), et qui te font un vrai site web tout plein en 2 coups de cuillères à pot ! Et une fois que t'as bien prototypé ton site, tu le répliques sur une instance de chez iriscouch, et tu distribues au monde entier le plus simplement du monde.

Map/Reduce

Le principe est assez connu aujourd'hui, et je ne vais pas te faire l'affront de t'expliquer ce que c'est; je rappelle juste au futur lecteur qu'il s'agit d'un moyen de distribuer le travail sur des agents de travail indépendants, qui mettent ensuite tout leur travail en commun de manière distribuée pour retourner les informations. Bon en pratique ya un machine qui fait tourner CouchDB, mais cette distribution des tâches dans la VM Erlang peut te monter ton CPU à 100% et donc l'utiliser à fond.

Et bien CouchDB repose grandement là-dessus: l'un des intérêts quand on construit une base de données avec est d'utiliser les vues pour avoir une information qui sera souvent demandée (comme l'âge moyen des utilisateurs par exemple). Une vue dans CouchDB est en fait un processus de MapReduce mis en cache (enfin, c'est le résultat qui est mis en cache) que CouchDB va mettre à jour automatiquement à chaque modif.

Replication

Très clairement, LE point fort de CouchDB, bien que je ne l'ai que peu utilisé. Pour faire simple, CouchDB est construit depuis le début pour être répliqué le plus simplement (un appel HTTP) et le plus efficacement (résolution primitive des conflits) possible.

Ca, c'est l'approche statique; là où ça devient intéressant, c'est quand on GET la ressource _changes, qui stocke séquentiellement TOUS les changements faits dans la DB, et permet de synchroniser efficacement 2 db qui se suivent l'une l'autre, par exemple.

Performances

Aha ! Tu as cru que les performances étaient un point fort de CouchDB ? Raté ! En général on constate plutôt que les perfs sont pas nécessairement meilleurs que le SQL. Plusieurs raisons à ça, les deux que je vois le plus sont la (dé)sérialisation en JSON et l'overhead du HTTP par dessus. Mais disons que pour les points forts du dessus, "ça suffit"

Espace disque

Qu'on se le dise tout de suite : CouchDB est extrêmement vorace. Il prend des Giga et des Giga octets de ton pauvre disque. A mon avis, le postulat de base c'est storage is cheap. Malheureusement, c'est pas aussi cheap que ça (Je pense par exemple aux téléphones).

Conclusion

J'aime bien CouchDB, mais c'est peut-être parce que je ne m'en sers pas encore sérieusement (ie en prod).

En tout cas, voilà un petit tableau qui m'a évité pas mal de recherches :
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
# scalabilité

Posté par Joris Dedieu (site web personnel) le 02 mai 2012 à 15:46. Évalué à 2.

D'un point de vue d'adminsys l'un des grands intérêt des logiciels de la famille nosql est la facilité d'une scalabilité horizontale (ajouter de nouveau serveurs) globalement mieux prévue et beaucoup moins complexe que sur les services de base relationnelle type mysql / postgresql.