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 :
- Un package d'algorithmes classiques pour les graphes avec, par exemple, Dijkstra et A* ;
- La possibilité d’exécuter du code sur des événements comme un commit ;
- 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) ;
- Monitoring avec JMX ;
- Optimisation du kernel ;
- Amélioration de l'indexation avec Lucene ;
- 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.
Aller plus loin
- Neo4J (39 clics)
- Riak (13 clics)
- LinuxFr.org : annonce de la sortie de Riak 0.10 (6 clics)
- Kyoto Cabinet (21 clics)
- LinuxFr.org : Kyoto Cabinet 1.0 (8 clics)
- Graylog2 (27 clics)
# Directory DB
Posté par Itaapy . Évalué à 3.
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)
[^] # Re: Kyoto Cabinet
Posté par evaisse . Évalué à 1.
Amicalement,
[^] # Re: Kyoto Cabinet
Posté par bathizte (site web personnel) . Évalué à 4.
A vrai dire, je trouve cette évolution dans les noms amusant , mais c'est vrai que ça peut désorienter.
Tu peux trouver un rapide comparatif des caractéristiques ici :
http://fallabs.com/kyotocabinet/spex.html#features%20genealo(...)
D'après ce que j'ai compris et pour simplisiimifier : tokyo cabinet est plus rapide dans les opérations de lecture et de recherche, mais kyoto cabinet est plus portable, robuste, supporte mieux le multithread..
[^] # Re: Kyoto Cabinet
Posté par Sylvain Bertrand (site web personnel) . Évalué à 0.
Kyoto cabinet est en C++. Tokyo cabinet est en C.
# De la maturité des bases No SQL...
Posté par Maclag . Évalué à 10.
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!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: De la maturité des bases No SQL...
Posté par David Roon . Évalué à 10.
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 Antoine . Évalué à 6.
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 webdev . Évalué à 6.
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 Mimoza . Évalué à 4.
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 zaurus (site web personnel) . Évalué à 1.
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 Antoine . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.