Journal A quoi peut servir couchdb ?

Posté par .
Tags :
13
18
fév.
2010
Bonjour.

Depuis quelques temps, je vois beaucoup d'articles cà et là à propos de couchdb. Pour ma part, j'ai un peu de mal à voir dans quel cas ce type de base de données peut servir. En effet, si j'ai bien compris, on peut stocker un peu tout et n'importe quoi de façon plus ou moins structuré .... Or c'est une façon de faire que je ne maitrise pas trop. Et vous, voyez-vous dans quels cas ce gestionnaire de bases de donnéres pourrait avoir son utilité ? Le premier truc qui me vient à l'esprit et de loin, c'est la GED, mais bon, je n'ai pas trop d'expérience dans ce domaine ....
  • # Moi, j'ai bien une idée...

    Posté par . Évalué à 10.

    on peut stocker un peu tout et n'importe quoi de façon plus ou moins structuré
    Ça pourrait s'interfacer comme base de stockage pour un projet LA RACHE !
  • # J'ai trouvé un site plein de références

    Posté par . Évalué à 2.

    Ce site [1] est plein de références sur CoucheDB. Bonne lecture !

    [1] http://nicolas.steinmetz.fr/journal/post/2009/06/14/CouchDB-(...)

    Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

    • [^] # Re: J'ai trouvé un site plein de références

      Posté par . Évalué à 4.

      Merci, mais j'avais déjà vu ces slides, et ça ne répond pas spécialement à ma question: Si quand même : c'est l'outil idéal pour un wiki. Sinon, je ne vois pas trop.
      • [^] # Re: J'ai trouvé un site plein de références

        Posté par . Évalué à 6.

        Pour répondre de manière plus générale, le gros intérêt de couchDB et autres MongoDB, Riak, etc ... C'est de se séparer du schéma fixe des bases de données relationnelles classiques.

        En gros, tu peux tout à fait modéliser tes données sous forme de hash pour ton application métier et il se trouve que ces DB visent à stocker sous cette forme tes données.

        C'est plus souple, plus simple et en plus ce genre de DB vise à s'héberger facilement sur du cloud. Par contre, c'est assez déroutant après autant d'années de SQL, pas rassurant pour les clients.

        Faut imaginer un peu sur une application genre au hasard hein, un truc social kikoo communautaire, qui évolue énormément le coût d'un changement de schema, qui ici est inexistant du coup. FriendFeed par exemple utilise une couche ORM schema-free au dessus de MySQL.

        Par contre, dans tout ce qui est grosse base de données au sens classique du terme ( banques et autres ) c'est tout sauf adapté. Pour le reste, mon avis personnel est que cela a clairement du sens.

        Après ya une grosse hype autour du mouvement NOSQL, il faut rester pragmatique et bien cerner les besoins avant de s'orienter vers ce genre de solutions.
        • [^] # Re: J'ai trouvé un site plein de références

          Posté par . Évalué à 3.

          En gros, tu peux tout à fait modéliser tes données sous forme de hash pour ton application métier et il se trouve que ces DB visent à stocker sous cette forme tes données.
          Un peu comme Berkeley DB ? A ceci près que couchdb est en plus concu pour gérer efficacement les accès concurents ainsi que, si j'ai bien compris la gestion "distribué" de la base.

          C'est plus souple, plus simple et en plus ce genre de DB vise à s'héberger facilement sur du cloud. Par contre, c'est assez déroutant après autant d'années de SQL, pas rassurant pour les clients.

          Je pense surtout que c'est pas adapté pour la plupart des bases stockées actuellement en SGBDR, mais que ça peut être utile pour des cas ou le SGBDR/SQL montre ses limites et oblige à avoir un schéma de base de données ultra complexe.

          Après ya une grosse hype autour du mouvement NOSQL, il faut rester pragmatique et bien cerner les besoins avant de s'orienter vers ce genre de solutions.
          C'est d'ailleurs la raison de mon post : de toutes mes lectures sur le sujet je n'ai jamais vu vraiment de cas ou un tel gestionnaire s'imposerait naturellement, mais peut-être que si un jour je veux implémenter mon propre moteur de wiki, j'y viendrai naturellement.
          • [^] # Re: J'ai trouvé un site plein de références

            Posté par . Évalué à 2.

            Je pense que nous sommes dans le même cas. SQL on connait, on sait travailler avec, on réfléchis en fonction de ça et je pense que pour ma part je vais mettre un peu de temps à voir les intérêts de CouchDB.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: J'ai trouvé un site plein de références

          Posté par (page perso) . Évalué à 3.

          > Par contre, dans tout ce qui est grosse base de données au sens classique du terme ( banques et autres ) c'est tout sauf adapté.

          Au contraire, pour les vraiment grosses bases de données, les bases NoSQL conviennent bien. De ce coté, on parle beaucoup moins de CouchDB, MongoDB, Riak, mais hbase/hadoop, cassandra et voldermort ont clairement la côte. J'ai entendu parler d'une société française dans le monde de la finance qui utilise voldemort pour traiter des petabytes de données.
    • [^] # Re: J'ai trouvé un site plein de références

      Posté par (page perso) . Évalué à 1.

      Il y a aussi une video d'un talk du FOSDEM, je ne l'ai pas regardée mais en général ce qui sort du FOSDEM n'est pas inintéressant.

      http://www.youtube.com/watch?v=Bfje5csISQ8
  • # Plus de partie serveur

    Posté par (page perso) . Évalué à 4.

    Dans mes appli récentes (Ajax toussa...), on a:
    1) Une partie "cliente", en JS, qui GET/POST/PUT/DELETE des objets en Json avec le serveur
    2) Une partie serveur (en Django, Turbogears, Ruby on rails, Grails...) qui offre une api REST en Json au niveau Controlleur, utilisant des objets metiers, mappé tant bien que mal sur une base de donnée relationnelle.

    L'interet de couchdb, c'est qu'on peut potentiellement zapper toute la partie 2, le javascript interroge directement la base.
    • [^] # Re: Plus de partie serveur

      Posté par . Évalué à 3.

      Oui mais ..... ce qui me gène un peu dans couchdb, c'est le manque de structuration apparente des documents stockés.

      A priori pour un wiki, par exemple c'est l'idéal : la base stocke directement les documents, et on interroge directement la base pour les récupérer/les mettre à jour, etc .... Je vois aussi bien ce genre de base pour stocker des documents (j'ai un tas de docs techniques PDF divers et variés). En réfléchissant plus loin, on pourrait aussi s'en servir pour stocker des photos .... Par contre, je me demande comment organiser tout ça, en raison du manque de structuration apparente de l'engin.
      • [^] # Re: Plus de partie serveur

        Posté par . Évalué à 4.

        Tu peux aussi avoir des documents très structurés très proche du modèle relationnel (en python ça marche comme un ORM) et l'avantage c'est donc la flexibilité car tu as soit du quasi relationnel soit quelque chose de moins structuré (ça dépends de ce que tu veux faire).
      • [^] # Re: Plus de partie serveur

        Posté par . Évalué à 2.

        En même temps ça a l'air d'être fait exactement pour stocker des documents ;)

        En fait ça a l'air d'être un peu comme XML : c'est fait pour le semi-structuré.

        Si tu reprends l'exemple de tes images, ça doit pouvoir permettre de les organiser en album / sous albums, de rajouter des commentaire et de placer les photos un peu comme tu veux pour avoir un truc sympa et moins rigide que le classement en album/tag à la picasa par exemple ...

        La structure, c'est l'utilisateur qui peut la faire comme il le veut, comme sur un wiki, c'est ça le principal intérêt que je peux y voir ... tout en gardant la possibilité de faire des requêtes sur les photos ?
        • [^] # Re: Plus de partie serveur

          Posté par . Évalué à 6.

          En même temps ça a l'air d'être fait exactement pour stocker des documents ;)
          Oui, mais un SGBDR aussi peut être utilisé pour stocker des documents :).
          En fait ça a l'air d'être un peu comme XML : c'est fait pour le semi-structuré.
          Oui, un peu comme le XML quoique je le vois même un peu moins rigide que le XML.

          Si tu reprends l'exemple de tes images, ça doit pouvoir permettre de les organiser en album / sous albums, de rajouter des commentaire et de placer les photos un peu comme tu veux pour avoir un truc sympa et moins rigide que le classement en album/tag à la picasa par exemple ..
          C'est effectivement comme ça que je le vois. Mais j'ai l'impression que ce genre de gestionnaire de BDD est l'outil idéal pour "perdre" des documents dans la base (perdre dans le sens ou je ne saurais plus y accéder, parce que le document en question utilise des clés qui ne sont plus utilisées par les autres documents du même type, et que j'ai oublié comment à l'origine celui-ci était défini).
          La structure, c'est l'utilisateur qui peut la faire comme il le veut, comme sur un wiki, c'est ça le principal intérêt que je peux y voir ... tout en gardant la possibilité de faire des requêtes sur les photos

          Oui mais le risque au fil du temps c'est de se retrouver avec des photos que l'on ne "trouverait plus" parce que les critères de sélection/rangement auraient changé ... Je me trompe peut-être mais c'est un des inconvénients que je note. En gros ce genre de système de BDD me fait penser à la pile de documents non classés que j'ai sur mon bureau : ce sont des feuilles de papier qui trainent sur mon bureau. Après pour savoir ce qu'il y a dedans, je suis obliger de fouiller pour identifier ce que c'est..
          • [^] # Re: Plus de partie serveur

            Posté par . Évalué à 2.

            De ce que je vois, c'est fait pour faire de l'indexation de documents aussi.

            Si tu changes les critères de rangements, deux choses : à mon avis tu peux faire le changement de critères automatiquement avec un script par exemple, et tu peux archiver la version d'avant au besoin.


            De plus : le fait que l'information soit "en contexte" dans un document fait que pour le retrouver t'as pas forcément besoin de te souvenir exactement ou il est, mais de te rappeler du/des contextes dans lesquels tu aurais pu l'utiliser, par association d'idée tu devrai retrouver ton document sans trop de soucis en cherchant le contexte approprié.

            Pour le bureau, effectivement ça peut être le bordel, sauf que là si tu te démerde bien tu peux faire des requêtes sur ton bureau sans déplacer toutes tes piles de papiers, et que tu peux placer un document dans plusieurs contextes différents si tu veux.
            • [^] # Re: Plus de partie serveur

              Posté par . Évalué à 2.

              Je commence à voir un peu plus à quoi ça peut servir, et c'est typiquement le genre de problème que j'ai à traiter en ce moment .

              Je cherche à référencer les serveurs que je gère. Les serveurs ont un certain nombre de caractéristiques "logiques" identiques (hostname, adresse IP, disques, etc ..."), par contre le côté physique du serveur peut pêtre totalement différent. Un serveur peut être une machine standalone, une partition d'un complexe partitionnable (exemple les superdomes HP, ou les serveurs SUn style 25k), ça peut être une VM, et si on veut représenter la couche physique, on se retrouve avec des modèles totalement différents et qu'on ne peut représenter de façon simple dans un SGBDR. Je cite ce qui m'a fait tilter (voir http://www.couchdb-fr.net/introduction pour l'exemple ) :

              Contrairement aux bases de données SQL qui sont conçues pour stocker et rendre compte de données très structurées et liées entre elles, CouchDB est conçu pour stocker et rendre compte de grandes quantités de données semi-structurées, orientées document. CouchDB simplifie grandement le développement d'applications orientées document, qui constituent l'essentiel des applications web collaboratif.

              Le schéma évolue avec les besoins et dans une base de données SQL, le stockage des données existantes doit être mis à jour pour coller au schéma. Cela provoque souvent des problèmes dès que de nouveaux besoins apparaissent qui n'étaient tout simplement pas prévu dans le design initial de la base de données, et, pour les systèmes distribués, cela rend les mises à jour problématiques pour chaque hôte qui doit passer par une mise à jour du schéma.

              Avec CouchDB, aucun schéma n'est appliqué, de sorte que de nouveaux types de documents, avec un sens nouveau, peuvent être ajouté en toute sécurité aux côtés des anciens. Le moteur de vue, en utilisant Javascript, est conçu pour manipuler facilement des nouveaux types de documents, des documents disparates… mais qui restent de simples documents.


              Faut que je creuse ça ..... Avec Ruby et sa possibilité de créer/modifier des classes à la volée, ça risque d'être intéressant.
              • [^] # Re: Plus de partie serveur

                Posté par . Évalué à 4.

                J'ai entendu parler d'un projet utilisant la technologie REST, de XML. Alors, je vais y aller de mon point de vue.
                Je n'avais jamais entendu parler de couchDB, je pense que je me documenterai rapidement à son sujet. Par contre, je pratique un peu la philosophie REST + XML sur mon projet actuel, et pour peu que ça se rapproche un minimum du sujet du journal, voici ce que j'en pense...

                Le projet, c'est une application web. On récupère des flux en entrée, on en affiche un formatage à l'écran, l'utilisateur les enrichit éventuellement, on crache un flux en sortie. En gros, c'est juste un projet informatique de SSII.
                L'architecture nous a imposé de faire du REST, avec un SILO (partie données) et un PILOTE (IHM / BATCHs). Les données transitant entre les deux sont un flux ATOM / xHTML. Voilà pour le contexte.

                Dans la pratique, on a une base de données MySQL qui stocke les ATOM dans un champ BLOB, avec une colonne idtech et une autre dateMiseAJour. Basta. On souhaite faire évoluer le modèle de données? Aucun problème de changement de modèle à coups d'ALTER TABLE. La reprise de données? De toute manières, on est plus ou moins obligé d'utiliser un langage de haut niveau, on peut donc appliquer des règles métier évoluées sans "trop" s'embêter (XML parsing inside, SQL souvent insuffisant). Voilà pour les avantages.
                En ce qui concerne les inconvénients, on retrouve une complexité accrue à mettre en place des objets métier (avec getter et setter par champ; toutes les données étant gérées dans du XML, beaucoup de xPath, pas mal de DOM; technologie peu maîtrisée (uniquement sur le projet???)). Et puis en général, qui dit IHM dit tris ou rechercher. On se retrouve donc peu à peu à "externaliser du BLOB" certains champs xPath dans des colonnes de la base de données. D'où duplication d'information, difficulté accrue à maintenir la cohérence des données qui sont dupliquées, etc.

                J'y vois effectivement une grosse plu-value quant l'objectif de l'application utilisant cette base de données est principalement de restituer des données, peu modifiées. Il suffit alors de faire un select, une petite XSL, et c'est tout.

                En espérant que ce que j'ai raconté ait un quelconque intérêt et / ou rapport avec la choucroute...
              • [^] # Re: Plus de partie serveur

                Posté par (page perso) . Évalué à 1.

                Un serveur peut être une machine standalone, une partition d'un complexe partitionnable (exemple les superdomes HP, ou les serveurs SUn style 25k), ça peut être une VM, et si on veut représenter la couche physique, on se retrouve avec des modèles totalement différents et qu'on ne peut représenter de façon simple dans un SGBDR.

                Dans ce genre de cas, on peut toujours modéliser de façon classique avec une entité des caractéristiques et une entités des valeurs associées aux caractéristiques. Au niveau des tables, ça peut revenir simplement à avoir une table permettant de stocker des paires (caractéristiques, valeurs), comme on pourrait le faire dans une structure XML, tout en ayant l'avantage de pouvoir la manipuler et la requêter en SQL.
        • [^] # Re: Plus de partie serveur

          Posté par . Évalué à 4.

          Disons qu'avec CouchDB, c'est ton code qui est responsable de la structure de tes données.

          Avec une couche SQL, c'est normalement à la base de données t'imposer la structure à ton code. Ce qui était particulièrement utile pour les grosses DB centralisées d'entreprise, où chaque service tape dedans à sa guise sans forcément consulter ses petits copains avant. Fut un temps, le SQL était l'interface, et chacun développait dessus. L'utilisateur était développeur, en un sens.

          Sauf qu'aujourd'hui, le SQL disparaît de plus en plus derrière des couches d'abstraction, on voit des bases de données servir de manière complètement mono-utilisateur - et je ne parle pas du serveur de DB, mais bien de la DB elle-même : quand une application PHP est la seule à taper sur sa base de données, que le développeur est obligé de faire le grand écart pour conserver une cohérence de schéma entre sa base et son code, on peut légitimement se demander l'intérêt du SQL.

          On n'est plus au XXè siècle : le SQL n'est plus une interface frontale, mais tend plutôt à se voir reléguée aux arrière-boutiques. Dans ces conditions, c'est peut-être à la fois une bonne raison et une bonne occasion pour regarder ce qui se fait à côté, non?
  • # Erreur

    Posté par . Évalué à 5.

    En fait c'est couchbb.
  • # Les perfs.

    Posté par . Évalué à 2.

    Les bases de données à la MapReduce, dont CouchDb semble le plus abouti des systèmes libres, permettent certes plus de flexibilité, mais facilitent surtout le passage à l'échelle.

    Grosso modo, dans le monde classique, si un serveur d'application ramait, il suffisait d'en mettre un second en parallèle pour avoir des perfs proches de ce que l'on avait fois deux. Pour les serveurs de base de données, par contre, c'est beaucoup moins évident... Les données doivent être répliquées, rendant le tout moins intéressant.

    Avec une base de données CouchDb, les perfs de deux serveurs s'approchent du fois 2... Ce n'est pas pour rien que de nombreux sites avec de très nombreuses connexions simultanées utilisent un système de ce type (gmail, amazon, linkedin...)

    Et puis, faire des requêtes en Javascript, c'est quand même bien plus marrant que de faire du SQL ;-)
    • [^] # Re: Les perfs.

      Posté par . Évalué à 4.

      Claire que j'aimerais bien voir un site qui se passe complètement du CGI et du serveur web. Directement le javascript de la page qui discute avec la base de données, par contre j'ai peur pour le moteur javascript (que ce soit gecko ou webkit).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Base de Données Orienté OBJET

    Posté par . Évalué à 3.

    de ce que j'en ai lu, tu stocke simplement des "objets" dans ta base de donnée

    un objet a un identifiant,
    ensuite il a simplement des propriétés

    tu te fous de savoir si c'est un utilisateur (à stocker dans la table des utilisateurs), un post (à mettre dans la table des posts)...

    tu envoie ton objet à la base.

    ensuite pour lire les infos, tu cherches les objets qui ont la propriété "utilisateurs"
    pour trouver les utilisateurs
  • # La question que je me pose

    Posté par . Évalué à 2.

    entre autres, Il y a le principe d'index ou pas?? Car pour ce que j'en ai lu, quand tu fais une recherche, ca va parcourir tout les objets et y appliquer tes critères...
    Cela me parait incroyablement gourmand. Hors null part j'ai vu parler de champs indexable.
    • [^] # Re: La question que je me pose

      Posté par . Évalué à 1.

      Oui, les objets sont indexés en b-stress (la traduction serait structure de données en arbre?). Et il est possible d'indexer les vues (et peut être d'autres choses, mais j'ai juste joué avec couchdb 1 jour ou deux)

      Le fait de parcourir la base n'implique pas une instanciation des objets, donc c'est pas forcement plus gourmand. Ou j'ai rien capté...
    • [^] # Re: La question que je me pose

      Posté par (page perso) . Évalué à 3.

      > Il y a le principe d'index ou pas?

      Oui et non. Il n'y a pas à proprement parler d'index, mais les views remplissent un rôle similaire et permettent d'avoir des performances tout à fait correctes.
      • [^] # Re: La question que je me pose

        Posté par (page perso) . Évalué à 2.

        Chaque document a quand même un id unique, donc tu peux y accéder en temps unitaire (ce qui est l'intérêt d'un index) à condition de savoir ce que tu veux.
        • [^] # Re: La question que je me pose

          Posté par . Évalué à 2.

          C'set quoi le temps unitaire ? Je dirai comme ça qu'un index permet d'accéder à une donnée en temps logarithmique (par rapport à la taille de la base), mais le temps unitaire, connais pas.
          • [^] # Re: La question que je me pose

            Posté par (page perso) . Évalué à 2.

            Indépendant de tout ce que tu veux (donc tout accès prend "le même temps", indépendamment de la taille de ta base). Bon, ça dépend de l'implémentation effectivement. Mais si tu as quelque chose basé sur des tableaux, l'accès est direct (début du tableau + index = ta donnée).
            • [^] # Re: La question que je me pose

              Posté par . Évalué à 2.

              J'aurai dit accès en temps constant perso. Cela dit ça ne vaut que si tu as une fonction de hash de ta donnée qui permette de retrouver l'indice de la donnée, ou si tu connais à priori l'index de ta donnée (dans ce cas effectivement la recherche n'est pas très compliquée), ce qui n'est pas gagné.

              Ou si tu connais l'identifiant que tu recherche, et que sa position dans la base dépend uniquement de cet identifiant, ce qui n'est pas forcément gagné non plus.
  • # Mongo sapin

    Posté par . Évalué à 4.

    Je me pose la même question.
    Par contre avec MongoD http://www.mongodb.org/ , car Mongo me semblait plus abouti lors de mon étude préalable. Et surtout des drivers sont disponibles pour de nombreux langages de toutes sortes (typé statiquement, dynamiquement, etc.)

    Donc, je fais joujou avec mongo. Mes premieres impression:

    - c'est simple ...: pas de prises de tête, installation facile, utilisable sans peine après installation du driver pour son langage favoris.
    - mais pas simpliste : on peut poser ses propres index, le langage de requête est assez riche.

    Comme intérêt, ça reste flou pour moi. Mais j'entrevois quelques points à mons avis interessants.

    Cela permet facilement de distribuer ses données, voir de répartir la charge sur plusieurs machines. Ca n'est qu'une intuition.

    Le côté non structuré est déstabilisant. Mon premier réflexe fut de créer un mini mapper typé, pour avoir quelque part une sécurité dans le typage. Et puis j'ai réfléchi, et je me suis dit que c'était aller à l'encontre de l'esprit. Donc j'ai créé un petit utilitaire qui me permet de créer un proxy sur un objet Mongo, lorsque je veut l'utiliser de manière plus structurée, tout en gardant le côté générique lorsque c'est utile.

    La généricité, c'est aussi un point qui me semble important. Mongo permet des traitements génériques beaucoup plus simplement qu'une base SQL. Si vous avez déjà utiliser JSON, ou bien même Scheme ou Lisp, vous devez avoir une idée de quoi je parle.
    De plus le mismatch entre Mongo et les langages objet me semble moins important qu'avec une base SQL.


    En résumé, je dirai l'impression pour le programmeur doit être assez proche lorsqu'il passe d'une base relationnelle à Mongo, que lorsqu'il passe de Java à Python ou Ruby.

    On y gagne une grande souplesse et puissance, et donc aussi une grande responsabilité.
    • [^] # Re: Mongo sapin

      Posté par (page perso) . Évalué à 4.

      Pour avoir tester les deux (MongoDB et CouchDB) sur des applications wev, je recommande très fortement de commencer par MongoDB. C'est plus proche du monde SQL et, du coup, beaucoup plus facile à prendre en main. En plus, je n'ai pas trouvé de gros avantages à CouchDB par rapport à MongoDB.

      Pour ce qui est des avantages du MongoDB sur les bases de données relationnelles, ils sont nombreux et je ne vais en citer que quelques uns :
      - pas de schéma, et donc pas de migrations pour modifier le schéma
      - les types composés (tableau et hash) sont bien pratiques
      - c'est impressionnant de rapidité (en comparaison MySQL se traîne comme un escargot)
      - on peut ajouter des index sans tout bloquer pendant des heures (http://www.mongodb.org/display/DOCS/Indexing+as+a+Background(...)
      - ça supporte bien de grosses quantités de données.

      Pour encore plus d'avantages, vous pouvez lire ce retour d'expérience : http://www.businessinsider.com/how-we-use-mongodb-2009-11

      Et pour ceux qui ont envie de tester, il existe une démo en ligne : http://mongo.kylebanker.com/

      Je me permets également de citer un billet écrit par un de mes collègues sur le sujet : http://dev.af83.com/mongodb/pourquoi-choisir-mongodb/2010/01(...)
      • [^] # Re: Mongo sapin

        Posté par . Évalué à 1.

        Je crois que tu n'as pas souvent posté de lien sur linuxfr! ;)

        Mongo plus proche de SQL? Tu peux développer?

        Pas de migration pour le schema, certe, mais j'imagine que tes données, tu dois les migrer quand même? Sinon je n'imagine même pas la tête du code applicatif pour gérer le bordel!

        Bon ok, quand tu ne fait qu'ajouter des champs, tu peux t'en tirer sans migration, mais sinon?
        • [^] # Re: Mongo sapin

          Posté par (page perso) . Évalué à 2.

          > Je crois que tu n'as pas souvent posté de lien sur linuxfr! ;)

          Ça se discute. Il y en a un paquet sur http://linuxfr.org//2009/05/05/25414.html.

          > Mongo plus proche de SQL? Tu peux développer?

          Quand on veut aller chercher des données dans MongoDB, on écrit une requête qui ressemble à une requête SQL. Par contre, pour CouchDB, il faut d'abord comprendre le système de map-reduce (et rereduce). Quand j'ai commencé à utiliser MongoDB, au bout de 5 minutes, j'avais compris comment faire des requêtes assez simples. Par contre, il m'a fallu un paquet de temps pour comprendre le map-reduce de CouchDB (et encore, je ne l'ai toujours pas totalement assimilé).

          > Pas de migration pour le schema, certe, mais j'imagine que tes données, tu dois les migrer quand même?

          Oui, bien sûr, mais ça reste un cas assez rare. Dans beaucoup de cas, les migrations SQL que je fais consistent surtout à ajouter une nouvelle table ou à ajouter une nouvelle colonne avec NULL comme valeur par défaut. Et pour faire l'équivalent à MongoDB, il y a juste rien à faire.

          C'est aussi particulièrement agréable pendant la phase de développement.
          • [^] # Re: Mongo sapin

            Posté par . Évalué à 1.

            Ok, tu faisais référence implicitement à couchDB et son Map/Reduce. Je te rejoins ici, le langage de requête de Mongo est en effet assez facile à comprendre et élégant, mais par contre je le trouve assez différent de SQL, surtout dans la syntaxe. Un truc sympa c'est qu'une requête se présente sous la forme d'un object Mongo.

            Au sujet des liens, je te suggère d'essayer de cliquer sur les liens de tes posts précédents! ;)
            • [^] # Re: Mongo sapin

              Posté par (page perso) . Évalué à 2.

              > Au sujet des liens, je te suggère d'essayer de cliquer sur les liens de tes posts précédents! ;)

              Rah, bien vu. C'est parti pour aller corriger ça dans la base de données...
  • # Un exemple

    Posté par (page perso) . Évalué à 4.

    Dans la société où je travaille, on développe des applications web, et on a eu l'occasion d'utiliser CouchDB sur un de nos projets. Le projet en question vise à devenir une sorte de wikipedia de l'art.

    Nous avons donc des artistes, des fiches sur les œuvres d'arts, des périodes historiques, des lieux, et des relations entre tous ces objets (du genre tel tableau a été inspiré par le travail de tel artiste). Chaque fiche comporte des informations qui doivent notamment permettre des recherches. Ces informations rentrent plus ou moins bien dans des champs. Par exemple, si on prend le champ 'dimensions', il ne sera pas rempli de la même façon pour un tableau (2 dimensions) que pour une statue (3 dimensions). Pour les dates, nous avons parfois quelque chose de très précis (le 11/02/1827) ou au contraire de très imprécis (environ 400 ans avant JC). Enfin, il y a une multitude de champs possibles, mais généralement qu'une petite partie de ceux-là sont remplis. Cela vient notamment du fait que selon le type de l'œuvre, de nombreux champs ne sont pas pertinents : le champ "encadrement" s'applique bien à un tableau, mais pas vraiment pour une statue. Il arrive également qu'un champ est généralement une seule valeur, mais que dans certains cas ait plusieurs valeurs. Par exemple, on pourrait avoir plusieurs dimensions pour une œuvre qui serait en plusieurs parties.

    Au final, si on avait essayé de faire rentrer toutes ses informations dans une base de données SQL, je vous laisse imaginer le nombre monstrueux de tables qu'il aurait fallu (ou alors, une quantité folle de colonnes et de NULL dans ces colonnes), et récupérer une fiche aurait nécessiter une requête SQL d'une complexité que je ne préfère pas imaginer. Nous nous sommes tournés vers CouchDB qui nous a permis de faire ça efficacement. Nous ne regrettons absolument pas ce choix, mais si nous avons rencontrés quelques défauts de jeunesse de CouchDB.
    • [^] # Re: Un exemple

      Posté par . Évalué à 2.

      Juste par curiosité, avez-vous aussi regardé du cote des outils de type semantic web (la description du projet me rappel beaucoup freebase) ?
      Si oui, qu'est-ce qui a fait pencher la balance vers couchdb ?
      • [^] # Re: Un exemple

        Posté par (page perso) . Évalué à 2.

        On a regardé rapidement du coté RDF, mais ça n'a pas donné grand chose. Pour certains outils, nous n'avons même pas réussi à les installer. Pour les autres, nous n'avons pas été convaincus par l'utilisation : rien que des cas simples comme récupérer toutes les informations pour la fiche d'une œuvre d'art semblaient déjà très complexes avec ces outils. Donc, on a assez rapidement laisser tomber cette possibilité.
  • # Persevere

    Posté par . Évalué à 3.

    A chaque fois que j'entends parler de NoSQL, j'entends parler de MongoDB, CouchDB et autres stockages basés sur Hadoop...

    C'est drôle comme personne ne parle de persevere, qui fonctionne très bien, et permet à une appli web de dialoguer directement (via une API REST) à une base de données.

    Bon, ok, par rapport aux autres y'a un peu un schéma de données (facultatif, suivant JSON Schema), mais ça marche du feu de dieu!

    http://www.persvr.org/
    • [^] # Re: Persevere

      Posté par . Évalué à 3.

      Je veux pas lancer un troll, mais il me semble que couchDB le fait aussi.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Sécurité coté client

    Posté par (page perso) . Évalué à 2.

    Et coté sécurité ?

    Comment sont effectués les contrôles de sécurité, le filtrage des données ?

    Le code javascript étant coté client, il peut être modifié par le client ?

    C'est la base de données qui fait les contrôles ?
    • [^] # Re: Sécurité coté client

      Posté par . Évalué à 2.

      En même temps tu peux mettre tes requêtes côté serveur aussi (confère Adapter ActiveRecord pour Rails par exemple, ou autre) donc c'est ton application intermédiaire qui fait le contrôle.

      De toute façon quelle que soit la technologie utilisé ne jamais mettre d'accès directes au DATA. Toujours mettre une couche tampon pour gérer entre autre la sécurité mais aussi tout autre chose.
  • # Question bête

    Posté par . Évalué à 2.

    J'avais lu un article intéressant dans un linuxmag sur le sujet et j'avais été bien séduit pas le concept.

    Par contre, j'avoue ne pas avoir compris comment on pouvait faire des requêtes un peu complexes. Genre, je voudrais les entrées d'un blog du 1 janvier au 12 janvier de la catégorie 'linux' et de l'auteur 'edouard'.

    J'avais vu que l'on devait faire des vues et des clefs 'tableaux' mais cela m'avait semblé complexe (enfin relativement).

    Est-ce que quelqu'un pourrait m'orienter un peu sur le sujet ?

    Merci.
    • [^] # Re: Question bête

      Posté par (page perso) . Évalué à 4.

      Une manière de faire :

      Une vue (ie un index) avec comme clé : [ categorie , auteur, date ]

      map = function(doc) {
      emit( [doc.Category, doc.Author, doc.Date] , null);
      }

      et pas de reduce

      appel avec start_key=["Linux", "Edouard", "2010-01-01"]&end_key=["Linux", "Edouard", "2010-01-12"]


      Il faut se dire qu'on va créer un index, cad un ensemble de couple (clé,valeur) et ça sera stocké trié par clé. Donc quand on requête sur la vue (cad sur l'index) on requête par rapport à la clé.
      C'est la seule manière de faire qui soit efficiente. Une vue temporaire est souvent inadmissible (car ça va tout reparcourir les documents, alors que dans une vue normal, à chaque appel on parcourt que ce qui a changé, donc c'est potentiellement très très très rapide).

      Donc, dans la plupart des cas, faut penser un peu en mode je dois faire une requête SQL qui utilise complètement UN index.

      (Faudrait que je finisse cette page : http://www.couchdb-fr.net/decouvrir/exemple-blog )

      --------------------

      Pour les autres qui se pose des questions de l'intérêt, je vais donner le mien (entres autres) :

      Par exemple, comment stocker en base une facture ?

      MySQL : 1 table facture + 1 table facture_lignes + clés étrangères

      CouchDB :
      {
      ...
      "client": "Bill Gates",
      "lignes": [
      { "Produit": "Support Linux (1/2j)", "Quantité": 10, "Prix": 500 },
      { "Produit": "Porte clé Manchot", "Quantité": 1, "Prix": 2.99 }
      ],
      "Total": 5002.99
      }

      (Tout ce qui est mettable en JSON est enregistrable dans CouchDB...)
      • [^] # Re: Question bête

        Posté par . Évalué à 3.

        Tu ne serais pas tombé par hasard dans le piège d'avoir trouvé un marteau et de considérer que tous les problèmes sont des clous ;-) ?
        • [^] # Re: Question bête

          Posté par (page perso) . Évalué à 2.

          ;-)

          La tentation est grande quand on se met à un outil de vouloir tout faire avec (et de vouloir évangéliser à tout prix).
          CouchDB n'est pas le Saint Graal loin de là.

          Des exemples de "vis" :
          - numéros séquentiels (le genre auto_increment)
          - requêtes SQL : on se rend vraiment compte du confort de MySQL quand on a à faire des requêtes "dynamiques" du genre lister des trucs avec des filtres activables (contient, commence par, de ... à ... , ...) ou non sur chaque champs, plus un tri choisi sur n'importe lequel des champs

          Ce qui peut séduire vraiment c'est :
          - l'aspect document : toujours pour ma facture : en un document je stocke ma facture avec tout ce qui la compose (les lignes.... et aussi par exemple des infos clients (adresse...) puisqu'une facture est censée être figée une fois validée*) plus l'historique des modifications (qui a fait quoi, qui à validé...) plus éventuellement le PDF généré (vu qu'on peut attacher des fichiers).
          - les vues : sortons des factures. Je peux avoir une vue (indexée donc) qui me donne un état de stock à partir des mouvements réalisés. Car on peut vouloir ne connaître l'état du stock qu'à partir des mouvements sans stocker la quantité dispo dans une table (après il y a des contraintes d'intégrité...). Avec une bonne vue, on a ce qu'on veut, de manière indexée. Et le recalcul est partiel à chaque appel, on ne reparcourt que les doc modifiés.
          - la réplication : parfait pour des applis avec un mode déconnecté...

          Après, il faut faire un choix conscient, considérer ses besoins et évaluer la portée (niveau atomicité par exemple...)

          Les vues peuvent être une très grosse contrainte. Il faut faire ça bien dès le départ. Avec MySQL, on peut faire des requêtes de malade qui vont très bien tourner jusqu'à 10000 enregistrements (avec du parcours complet...), mais qui dès 100000 enreg va commencer à devenir longue... Et donc on peut être amené à repenser la requête pour utiliser des index qu'on va créer spécialement pour cette requête... Je vais pas entrer dans les détails, je dirais que cet extraordinaire moteur de requête de MySQL** peut être à double tranchant.
          Je dirais que pour les vues, il manque encore du map-reduce en série. Pour l'instant on ne peut en faire qu'un seul.

          * : avec le principe de la clé étrangère seule, on peut avoir des surprises.
          Un exemple simplet mais parlant : imaginons que dans les lignes de la facture j'ai un champs produit avec une clé étrangère. Je récupère le prix (via une jointure ou pas) dans la table produit. Je crée une facture, avec le produit X qui a le prix Y. Je la valide. Plus tard je modifie le prix du produit X, disons Z. Quand je réaffiche ma facture, j'ai le nouveau prix.
          Ce type de comportement peut être très emmerdant, si non désiré.

          ** : tout le long, je dis MySQL, mais ya aussi PostgreSQL....
        • [^] # Re: Question bête

          Posté par (page perso) . Évalué à 3.

          Marrant, j'entends souvent cette remarque, mais dans l'autre sens. Les personnes impliquées dans le mouvement NoSQL considère que le SQL, ça permet de faire pas mal de choses, mais pas tout, et pas toujours très bien. Il est donc important d'avoir le choix dans le type de sa base de données, et de pouvoir choisir la base qui conviendra le mieux à ses besoins.

          On peut alors être facilement effaré par ceux qui choisissent systématiquement des bases SQL sans se poser de questions, et essaye d'y mettre de force toutes leurs données même quand ça s'y prête très mal. J'ai déjà vu des gens utiliser MySQL pour des blobs binaires, des files d'attente, des données faiblement structurées (avec des tables 'objects', 'attributes', 'relations', 'contexts'...), et ça donne vraiment l'impression de considérer tous les problèmes comme des clous que le marteau SQL pourra enfoncer...
          • [^] # Re: Question bête

            Posté par (page perso) . Évalué à 2.

            Pour des petites quantités de données, une base SQL s'en tirera toujours. Par contre quand ça commence à grossir, ça peut faire très mal...

            Ce qui est bien, c'est que maintenant on a un vrai choix. Ça devrait lever l'automatisme base de donnée = relationnelle.
            • [^] # Re: Question bête

              Posté par (page perso) . Évalué à 5.

              Ce qui est bien, c'est que maintenant on a un vrai choix. Ça devrait lever l'automatisme base de donnée = relationnelle.

              Je veux... un "ballot screen"!
            • [^] # Re: Question bête

              Posté par . Évalué à 3.

              Pour des petites quantités de données, une base SQL s'en tirera toujours. Par contre quand ça commence à grossir, ça peut faire très mal...

              Peut-être pour des cas bien particuliers, je doute que l'on puisse généraliser comme ça (c'est un FUD !). Est-ce qu'il y a par exemple des benchs couchdb vs postgresql avec insertions atomiques, quelques contrôles d'intégrités, d'unicité et validité des données (une date est bien une date), le tout pendant qu'il y a des requêtes en lecture en parallèle ?

              Sur le site de couchdb c'est assez clair : What it is Not : A replacement for relational databases.

              Rien que le passage obligatoire par json ça ne doit pas être gratuit sur de grandes quantités de données. Si on prend une date par ex, j'imagine que c'est stocké en texte ? Qu'en est-il de l'occupation disque et mémoire ?

              Autant je peux imaginer l'intérêt d'un tel système sur un cluster pour fournir des documents très différents en lecture seule, autant pour des données genre facturation je doute, surtout sur un grand nombre de données...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.