Quels sont les cas d'utilisation des bases de données graphiques (http://neo4j.org/)?
J'ai beaucoup utilisé les bases de données relationnelles et j'ai décidé de m'aventurer sur d'autres types disponibles.
Ce produit particulier semble bon et prometteur: http://neo4j.org/
Quelqu'un at-il utilisé des bases de données graphiques? Quels sont les avantages et les inconvénients d'une perspective d'utilisation?
Les avez-vous utilisés dans un environnement de production? Quelle exigence vous a incité à les utiliser?
J'ai utilisé une base de données graphique dans un travail précédent. Nous n'utilisions pas neo4j, c'était une chose interne construite au-dessus de Berkeley DB, mais c'était similaire. Il a été utilisé en production (il l'est toujours).
La raison pour laquelle nous avons utilisé une base de données graphique était que les données stockées par le système et les opérations que le système effectuait avec les données étaient exactement le point faible des bases de données relationnelles et étaient exactement le point fort des bases de données graphiques. Le système devait stocker des collections d'objets dépourvus de schéma fixe et liés entre eux par des relations. Pour raisonner sur les données, le système avait besoin de faire beaucoup d'opérations qui seraient quelques traversées dans une base de données de graphes, mais ce serait des requêtes assez complexes en SQL.
Les principaux avantages du modèle graphique étaient la rapidité de développement et la flexibilité. Nous pourrions rapidement ajouter de nouvelles fonctionnalités sans affecter les déploiements existants. Si un client potentiel voulait importer certaines de ses propres données et les greffer sur notre modèle, cela pourrait généralement être fait sur place par le représentant des ventes. La flexibilité a également aidé lors de la conception d'une nouvelle fonctionnalité, nous évitant d'essayer de compresser de nouvelles données dans un modèle de données rigide.
Avoir une base de données étrange nous a permis de construire beaucoup de nos autres technologies étranges, nous donnant beaucoup de sauce secrète pour distinguer notre produit de ceux de nos concurrents.
Le principal inconvénient était que nous n'utilisions pas la technologie de base de données relationnelle standard, ce qui peut être un problème lorsque vos clients sont en entreprise. Nos clients demanderaient pourquoi nous ne pouvions pas simplement héberger nos données sur leurs clusters Oracle géants (nos clients avaient généralement de grands centres de données). L'une des équipes a en fait réécrit la couche de base de données pour utiliser Oracle (ou PostgreSQL ou MySQL), mais elle était légèrement plus lente que l'original. Au moins une grande entreprise avait même une politique Oracle uniquement, mais heureusement, Oracle a acheté Berkeley DB. Nous avons également dû écrire de nombreux outils supplémentaires - nous ne pouvions pas simplement utiliser Crystal Reports par exemple.
L'autre inconvénient de notre base de données graphique était que nous l'avons construit nous-mêmes, ce qui signifiait que lorsque nous rencontrions un problème (généralement avec une évolutivité), nous devions le résoudre nous-mêmes. Si nous avions utilisé une base de données relationnelle, le vendeur aurait déjà résolu le problème il y a dix ans.
Si vous créez un produit pour les clients d'entreprise et que vos données s'inscrivent dans le modèle relationnel, utilisez une base de données relationnelle si vous le pouvez. Si votre application ne correspond pas au modèle relationnel mais qu'elle correspond au modèle graphique, utilisez une base de données graphique. Si cela ne correspond qu'à autre chose, utilisez-le.
Si votre application n'a pas besoin de s'intégrer dans l'architecture blub actuelle, utilisez une base de données graphique, ou CouchDB, ou BigTable, ou tout ce qui correspond à votre application et vous pensez que c'est cool. Cela pourrait vous donner un avantage et c'est amusant d'essayer de nouvelles choses.
Quoi que vous choisissiez, essayez de ne pas construire le moteur de base de données à moins que vous n'aimiez vraiment construire des moteurs de base de données.
Nous travaillons avec l'équipe Neo depuis plus d'un an maintenant et nous sommes très heureux. Nous modélisons des artefacts savants et leurs relations, ce qui est parfait pour un graphe db, et exécutons des algorithmes de recommandation sur le réseau.
Si vous travaillez déjà en Java, je pense que la modélisation à l'aide de Neo4j est très simple et qu'elle offre les performances les plus plates/rapides pour la R/W de toutes les autres solutions que nous avons essayées.
Pour être honnête, j'ai du mal pas à penser en termes de graphique/réseau parce que c'est tellement plus facile que de concevoir des structures de table alambiquées pour contenir les propriétés et les relations des objets.
Cela étant dit, nous stockons certaines informations dans MySQL simplement parce qu'il est plus facile pour le côté commercial d'exécuter des requêtes SQL rapides. Pour exécuter les mêmes fonctions avec Neo, nous aurions besoin d'écrire du code pour lequel nous n'avons tout simplement pas la bande passante pour le moment. Dès que nous le faisons, je transfère toutes ces données vers Neo!
Bonne chance.
Deux points:
Tout d'abord, sur les données avec lesquelles j'ai travaillé au cours des 5 dernières années dans SQL Server, j'ai récemment atteint le mur d'évolutivité avec SQL pour le type de requêtes que nous devons exécuter (relations imbriquées imbriquées ... vous savez ... graphiques ). J'ai joué avec neo4j et mes temps de recherche sont plus rapides de plusieurs ordres de grandeur lorsque j'ai besoin de ce type de recherche.
Deuxièmement, au point que les bases de données graphiques sont obsolètes. Um non. Au début, alors que les gens essayaient de comprendre comment stocker et rechercher efficacement les données, ils ont créé et joué avec des modèles de base de données de style graphique et réseau. Ceux-ci ont été conçus pour que le modèle physique reflète le modèle logique, donc leur efficacité n'était pas si grande. Ce type de structure de données était bon pour les données semi-structurées, mais pas aussi bon pour les données denses structurées. Ainsi, ce type IBM nommé Codd recherchait des moyens efficaces d'organiser et de stocker des données structurées et a eu l'idée du modèle de base de données relationnelle. Et c'était bien, et les gens étaient heureux.
Qu'avons-nous ici? Deux outils pour deux objectifs différents. Les modèles de base de données graphiques sont très bons pour représenter des données semi-structurées et les relations entre les entités (qui peuvent ou non exister). Les bases de données relationnelles sont bonnes pour les données structurées qui ont un schéma très statique et où les profondeurs de jointure ne vont pas très profondément. L'un est bon pour un type de données, l'autre est bon pour d'autres types de données.
Pour inventer la phrase, il n'y a pas de Silver Bullet. Il est très myope de dire que les modèles de bases de données graphiques sont obsolètes et, pour en utiliser un, abandonner 40 ans de progrès. C'est comme dire que l'utilisation de C abandonne tous les progrès technologiques que nous avons accomplis pour obtenir des choses comme Java et C #. Ce n'est pas vrai cependant. C est un outil qui est nécessaire pour certaines tâches. Et Java est un outil pour d'autres tâches.
J'utilise MySQL depuis des années pour gérer les données d'ingénierie, et cela a bien fonctionné, mais l'un des problèmes que nous avions (mais ne nous en rendions pas compte) était que nous devions toujours planifier le schéma à l'avance. Un autre problème que nous savions que nous avions était de mapper les données vers les objets du domaine et inversement.
Maintenant, nous venons de commencer à essayer neo4j et il semble que cela résout les deux problèmes pour nous. La possibilité d'ajouter des propriétés différentes à chaque nœud (et relation) nous a permis de repenser toute notre approche des données. C'est comme les langages dynamiques et statiques (Ruby contre Java), mais pour les bases de données. La construction du modèle de données dans la base de données peut se faire de manière beaucoup plus agile et dynamique, ce qui simplifie considérablement notre code.
Et puisque le modèle objet dans le code est généralement une structure graphique, le mappage à partir de la base de données est également plus simple, avec moins de code et par conséquent moins de bogues.
Et en bonus supplémentaire, notre code prototype initial pour le chargement de nos données dans neo4j est en fait plus rapide que la version précédente de MySQL. Je n'ai pas (encore) de chiffres solides à ce sujet, mais c'était une belle fonctionnalité supplémentaire.
Mais à la fin de la journée, le choix devrait probablement être basé principalement sur la nature de votre modèle de domaine. Correspond-elle mieux aux tableaux ou graphiques? Décidez en faisant quelques prototypes, chargez les données et jouez avec. Utilisez neoclipse pour regarder différentes vues des données. Une fois que vous avez fait cela, j'espère que vous savez si vous êtes sur une bonne chose ou non.
Je construis un intranet dans mon entreprise.
Je souhaite comprendre comment charger des données stockées dans des tables (Oracle, MySQL, SQL Server, Excel, Access, diverses listes aléatoires) et les charger dans Neo4J ou dans une autre base de données de graphiques. Spécifiquement, que se passe-t-il lorsque des données communes chevauchent des données existantes déjà dans le système.
Oui, je sais que certaines données sont mieux modélisées dans le SGBDR, mais j'ai cette idée qui me démange, que lorsque vous devez superposer plusieurs tables distinctes, le modèle graphique est meilleur que la structure de la table.
Par exemple, je travaille dans un environnement de fabrication. Il y a un projet majeur sur lequel nous travaillons et en raison de la complexité, chaque département a créé une feuille de calcul Excel séparée qui a une hiérarchie BOM (Bill Of Materials) dans une colonne de gauche, puis plusieurs colonnes des notes et des chèques faits par les personnes qui ont fait ces feuilles.
Ainsi, l'un des problèmes est de fusionner toutes ces notes dans une "vue" afin que quelqu'un puisse voir tous les problèmes qui doivent être traités dans une partie particulière.
Le deuxième problème est qu'une feuille de calcul Excel ne sert à rien à représenter une nomenclature hiérarchique lorsqu'un composant commun est utilisé dans plusieurs sous-assemblages. Cela signifie que, si quelqu'un écrit une note sur le relais P34 dans le sous-ensemble d'allumage, le même commentaire doit être associé aux relais P34 utilisés dans le sous-ensemble pilote de moteur. Cela ne se produira pas dans la feuille de calcul Excel.
Pour l'intranet de l'entreprise, je veux pouvoir rechercher facilement n'importe quoi. Telles que les données liées à un numéro de pièce, une structure de nomenclature, un numéro de téléphone, une adresse e-mail, une politique ou une procédure de l'entreprise. Je veux même étendre cela pour gérer les ressources matérielles informatiques et les logiciels installés.
J'imagine qu'une fois que le réseau d'information commence à être peuplé, vous pouvez commencer à faire des parcours sympas comme "Je veux écrire un e-mail à tous ceux qui travaillent sur le projet XYZ". Des personnes auront été associées au projet car elles seront marquées comme créant et modifiant les données dans le projet XYZ. Donc, en utilisant le projet XYZ comme clé de recherche, un énorme ensemble avec tout ce qui concerne le projet XYZ sera créé. Y compris des liens vers les personnes qui ont construit le projet XYZ. Les liens des personnes se connecteront à leurs adresses e-mail. Donc, par leur implication dans le projet XYZ, ils seront inclus dans mon email. Ceci est en contraste frappant avec un secrétaire essayant de maintenir une liste de personnes travaillant sur le projet. Nous générons beaucoup de listes. Nous passons beaucoup de temps à maintenir les listes et à nous assurer qu'elles sont à jour. Et la plupart d'entre elles n'ajoutent aucune valeur à nos produits.
Une autre traversée sympa pourrait signaler tous les ordinateurs sur lesquels un certain logiciel est installé, par version. Ce rapport pourrait être utilisé pour générer des tâches pour supprimer des copies supplémentaires d'anciens logiciels et pour mettre à jour les personnes qui ont besoin de la dernière copie. Il serait également utile pour le suivi des licences.
Voici un bon article qui parle des besoins que remplissent les bases de données non relationnelles: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
Il fait un bon travail en soulignant (à part le nom) que les bases de données relationnelles ne sont pas défectueuses ou erronées, c'est juste que de nos jours les gens commencent à traiter de plus en plus de données dans les logiciels et les sites Web traditionnels, et que les bases de données relationnelles ne vont pas évoluer pour ces besoins.
peut être un peu en retard, mais il y a un nombre croissant de projets utilisant Neo4j, les plus connus listés sur Neo4j . De plus, NeoTechnology, la société derrière Neo4j, a quelques références sur leur page clients
Remarque: je fais partie de l'équipe Neo4j