NoSQL : Neo4J, Riak, Kyoto Cabinet et Graylog2

Posté par (page perso) . Modéré par Nÿco.
17
3
août
2010
Base de données
Petite compilation de brèves autour de divers projets de type NoSQL :

Neo4J est une base de données de type graphes sous licence AGPLv3. La version 1.1, sortie fin juillet, apporte 7 grandes nouveautés :
  1. Un package d'algorithmes classiques pour les graphes avec, par exemple, Dijkstra et A* ;
  2. La possibilité d’exécuter du code sur des événements comme un commit ;
  3. Une bibliothèque de traversée de graphes (vous donnez des instructions comme l'ordre de parcours dans le graphe ou les types d'arcs à suivre et Neo4J vous renvoient les chemins parcourus) ;
  4. Monitoring avec JMX ;
  5. Optimisation du kernel ;
  6. Amélioration de l'indexation avec Lucene ;
  7. Inclusion de l'outil de sauvegarde à chaud.

Riak est une base de données distribuée de type clé-valeur, sous licence Apache 2. Depuis la précédente dépêche sur LinuxFr.org, deux versions sont sorties : la 0.11 et la 0.12. Bitcask est maintenant le moteur de stockage par défaut. Pour le reste, pas de grands changements, mais un bon nombre de corrections de bogues et de petites améliorations diverses.

Kyoto Cabinet est une base de données très rapide de type clé-valeur. Un nouveau type de stockage a été introduit dans la version 1.1.0 : Directory Database. Celui-ci n'est qu'une fine abstraction au-dessus des systèmes de fichiers et fonctionne particulièrement bien avec Ext3 et ReiserFS pour stocker des valeurs très grosses.

La version 1.2.0 a également été l'occasion d'introduire un nouveau type de stockage : ForestDB. Son implémentation est un B-tree au-dessus de DirDB et dont les performances sont étonnamment bonnes.

Enfin, Graylog2 est une implémentation Open Source de syslog qui enregistre les logs dans MongoDB. Il se compose d'un serveur en Java qui accepte les logs en TCP ou UDP et les enregistre dans la base de données, et d'une interface de consultation des logs écrite en Ruby on Rails. Les captures d'écran montrent les possibilités de configuration et de filtrage des messages de cet outil.
  • # Directory DB

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

    Très intéressant ces news.

    Le directory DB résonne particulièrement bien avec notre philosophie d'approche des données (encapsuler au minimum, utiliser les infrastructure existantes et leur myriade d'outils). Si certain sont intéressés par ces sujets je vous invite à venir participer à la conférence "Une base de donnés versionnée en Python : itools.database" qui aura lieu lors de Pyconfr. http://www.pycon.fr/talk/1962 (29/08/2010, 11h30, cité des sciences)
  • # De la maturité des bases No SQL...

    Posté par . Évalué à 10.

    J'ai peut-être un très gros à-priori sur les bases de données, mais pour moi, ce sont des choses extrêmement compliquées à développer et surtout à optimiser.

    On voit très régulièrement des infos sur une myriade de bases No SQL.

    Ai-je raison de penser (sachant que je ne suis pas expert en la matière!) que cette foultitude de projets traduit un énorme manque de maturité dans le secteur?

    Je veux bien qu'on ait beaucoup de gestionnaire de fenêtres, mais c'est beaucoup plus "simple" (au moins à commencer...), et ça a fini par donner quelques environnements de bureau ultra-dominants les autres.

    Les bases SQL, on voit bien qu'il n'y en a pas 10 dominantes sur le marché...

    Alors, serait-il urgent d'attendre que les projets fusionnent, disparaissent, ou autre avant de devenir un peu dépendant de l'un d'eux??

    Signé: quelqu'un qui n'en a pas l'utilité de toute façon, ha! ha! ha!
    • [^] # Re: De la maturité des bases No SQL...

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

      Attention malheureux, tu va t'attirer tout les évangéliste du NoSQL et tout l'attirail AJAX/JSON/etc. !
    • [^] # Re: De la maturité des bases No SQL...

      Posté par . Évalué à 10.

      Si on regarde plus attentivement les différentes solutions NoSQL, on se rend compte qu'elles sont très différentes. Cela implique que chaque solution est bonne dans une certaine situation et dans d'autres non.

      Perso je trouve très intéressant ces différents projets car cela donne enfin la possibilité aux développeurs de se poser la question :"Est-ce qu'une RDBMS est la meilleure solution pour moi ou bien est-ce qu'il y a une application plus adapté à mes besoins de persistance?".

      Parce que les pros et cons vont dans les deux sens. Et sur n'importe quel article digne de ce nom sur le NoSQL ils répèteront que le NoSQL n'est pas meilleur que les base de données classiques mais simplement il répond différemment à la question de la couche persistance et que cela peut vous apporter quelque chose. D'habitude les deux points forts sont la rapidité à l'écriture et la scalabilité. Si maintenant les perfs en écriture (surtout en update) dans ta base te vont très bien et que tu n'auras jamais plus d'une machine pour ton serveur SQL alors en effet passe ton chemin. Mais sinon regarder ce que cela vaut ne fait pas de mal.

      Voilà mon petit commentaire sur le sujet. Bonne journée
      • [^] # Re: De la maturité des bases No SQL...

        Posté par . Évalué à 6.

        D'habitude les deux points forts sont la rapidité à l'écriture et la scalabilité.

        Mais de façon systématique la rapidité à l'écriture est obtenue en ignorant les contraintes ACID. On doit pouvoir faire la même chose en changeant quelques attributs de configuration dans PostgreSQL (par exemple en désactivant fsync...).

        Quant à la scalabilité, il faut vraiment y aller pour avoir besoin de plus d'un serveur de bases de données de nos jours (sachant que même des serveurs d'entrée de gamme peuvent avoir 8 ou 16 coeurs, et que les disques SSD sont de plus en plus abordables). Les architecture astronauts du Web 2.0 aiment bien s'imaginer que n'importe quel site Web va recevoir le même trafic qu'un Twitter, un SourceForge ou un Facebook.
    • [^] # Re: De la maturité des bases No SQL...

      Posté par . Évalué à 6.

      Le "NoSQL" est plus un mouvement en réaction au quasi monopole du SQL dans les années 90 qu'une technologie en soi. C'est un retour à la normale après un monopole anormal. On ne peut pas stocker les photos de millions d'utilisateurs dans un cluster MySQL, du moins ce n'est pas la solution idéale. Amazon S3 et Riak sont optimisés pour cela. D'autres bases "NoSQL" sont optimisées pour d'autres usages. Certaines peuvent répartir leurs données sur plusieurs serveurs (Cassandra, CouchDB), d'autres non (Kyoto Cabinet, Redis). Certaines ont des indexes secondaires (ou les vues de CouchDB), d'autres non (Riak, Voldemort).

      Les bases non-SQL sont très utilisées, puisque Memcached en est une (optimisée pour le cache). D'après ma petite expérience, le gros problème de ces nouvelles bases est leur manque de maturité (fonctionnalités, stabilité) et surtout de documentation, à part pour GAE et AWS (heureusement, vu leurs tarifs) et Memcached. La meilleure documentation que j'ai trouvé est celle de CouchDB, la pire était celle de Cassandra. Disons qu'en utilisant une base NoSQL aujourd'hui, on se retrouve dans la même position que ceux qui utilisait MySQL fin 1990/début 2000.

      Pour un petit site de e-commerce ou la vitrine d'une PME, il est clair qu'une solution LAMP est suffisante. Les solutions NoSQL sont destinées principalement aux applications web plus ambitieuses. Commencer avec MySQL et envisager de tout réécrire lorsque l'application aura du succès est une erreur, à mon avis.
      • [^] # Re: De la maturité des bases No SQL...

        Posté par . Évalué à 4.

        Manque de compétence aussi, non ?
        Je suis quasi-certain qu'en demandant a une population de développeur/chef de projet/architecte seule une toute petite partie a entendue parler des bases NoSQL, une fraction de ce nombre sais exactement de quoi il s'agit. Quand a ceux qui en ont déjà utilisé je n'ose prédire le % ...

        Personnellement cela doit faire moins d'un an que je commence a en entendre parler et principalement sur ce site. Je ne pense pas que le renversement du monopole SQL soit pour tout de suite.
  • # Et Berkeley DB?!

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

    Coucou,

    Personne n'en parle ici mais c'est la BD persistante sans SQL
    dont j'ai entendu parler en premier.
    Genre, ca permet de stoquer une table de hachage sur disque
    et les performances ne sont pas mauvaises du tout.

    A+,
    F.
    • [^] # Re: Et Berkeley DB?!

      Posté par . Évalué à 2.

      C'est parce Berkeley DB est ringard (rien que le nom fait années 70) alors que NoSQL est à la mode (ça permet de se donner un air rebelle et anti-conformiste). Voilà tout.

Suivre le flux des commentaires

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