Quels sont les cas d'utilisation des bases de données graphiques (http://neo4j.org/)? [fermé]

J'ai beaucoup utilisé des 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 a-t-il utilisé des bases de données graphiques? Quels sont les avantages et les inconvénients du point de vue de la convivialité?

Les avez-vous utilisés dans un environnement de production? Quelle est l'exigence qui vous a incité à les utiliser?

J'ai utilisé une base de données de graphiques dans un emploi précédent. Nous n'utilisions pas neo4j, c'était un truc en interne construit sur 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 de graphiques était que les données stockées par le système et les opérations que le système faisait 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 de 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 devait faire beaucoup d'opérations qui seraient quelques traversées dans une base de données de graphes, mais ce seraient des requêtes assez complexes en SQL.

Les principaux avantages du modèle graphique étaient le temps de développement rapide et la flexibilité. Nous pourrions rapidement ajouter de nouvelles fonctionnalités sans affecter les déploiements existants. Si un client potentiel souhaitait importer certaines de ses propres données et les greffer sur notre modèle, cela pouvait généralement être fait sur place par le commercial. La flexibilité a également aidé lors de la conception d'une nouvelle fonctionnalité, nous évitant d'essayer de regrouper 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 secret-sauce 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 professionnels. Nos clients se demandaient 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'un des membres de l'équipe a en fait réécrit la couche de base de données pour utiliser Oracle (ou PostgreSQL ou MySQL), mais c'était légèrement plus lent 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 de graphes était que nous l'avons construit nous-mêmes, ce qui signifiait que lorsque nous rencontrions un problème (généralement avec l'évolutivité), nous devions le résoudre nous-mêmes. Si nous avions utilisé une base de données relationnelle, le fournisseur 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'intègrent 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 de graphique, utilisez une base de données de graphiques. 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 de graphiques, ou CouchDB, ou BigTable, ou tout ce qui convient à votre application et que 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 créer vous-même le moteur de base de données, sauf si vous aimez vraiment créer des moteurs de base de données.

Nous travaillons avec l'équipe Neo depuis plus d'un an maintenant et nous en sommes très heureux. Nous modélisons les artefacts savants et leurs relations, ce qui est parfait pour une base de données graphique, 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 / les plus rapides pour R / W de toutes les autres solutions que nous avons essayées.

Pour être honnête, j'ai du mal à ne pas penser en termes de graphique / réseau car 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 dont nous n'avons tout simplement pas la bande passante pour le moment. Dès que nous le faisons, je déplace toutes ces données vers Neo!

Bonne chance.

Deux points:

Tout d'abord, sur les données avec lesquelles j'ai travaillé ces 5 dernières années dans SQL Server, j'ai récemment atteint le mur de l'évolutivité avec SQL pour le type de requêtes que nous devons exécuter (relations imbriquées ... vous savez ... graphiques ). J'ai joué avec neo4j, et mes temps de recherche sont de plusieurs ordres de grandeur plus rapides 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 des 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, de sorte que 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 d'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 à deux fins différentes. Les modèles de base de données de graphes sont très bons pour représenter des données semi-structurées et les relations entre les entités (qui peuvent exister ou non). 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 loin. L'un est bon pour un type de données, l'autre est bon pour d'autres types de données.

Pour inventer l'expression, il n'y a pas de balle d'argent. Il est très myope de dire que les modèles de bases de données graphiques sont obsolètes et d'en utiliser un renonce à 40 ans de progrès. C'est comme dire que l'utilisation de C renonce à tous les progrès technologiques que nous avons traversés pour obtenir des choses comme Java et C #. Ce n'est pas vrai cependant. C est un outil 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 que nous n'avions pas réalisé) était que nous devions toujours planifier le schéma à l'avance. Un autre problème que nous savions avoir é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 différentes propriétés à chaque nœud (et relation) nous a permis de repenser l'ensemble de notre approche des données. C'est comme les langages dynamiques contre 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 être effectuée de manière beaucoup plus agile et dynamique, ce qui simplifie considérablement notre code.

Et comme 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 comme bonus supplémentaire, notre code prototype initial pour charger 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 fonctionnalité supplémentaire intéressante.

Mais en fin de compte, le choix devrait probablement être basé principalement sur la nature de votre modèle de domaine. Correspond-il mieux aux tableaux ou aux graphiques? Décidez en faisant des prototypes, chargez les données et jouez avec. Utilisez neoclipse pour examiner 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 suis intéressé à 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. Plus précisément, 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 de nomenclature (Bill Of Materials) dans une colonne à gauche, puis plusieurs colonnes de notes et de vérifications effectuées par des individus qui a fait ces feuilles.

L'un des problèmes est donc de fusionner toutes ces notes en une seule «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 parvient pas à 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 de commande de moteur. Cela ne se produira pas dans la feuille de calcul Excel.

Pour l'intranet de l'entreprise, je veux pouvoir rechercher n'importe quoi facilement. 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 d'entreprise ou une procédure. Je veux même étendre cela pour gérer les actifs matériels informatiques et les logiciels installés.

J'imagine qu'une fois que le réseau d'information commence à se peupler, vous pouvez commencer à faire des traversées intéressantes telles que «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. Ainsi, en utilisant le projet XYZ comme clé de recherche, un ensemble énorme avec tout ce qui est lié au projet XYZ sera créé. Y compris des liens vers les personnes qui ont construit le projet XYZ. Les liens de 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 une certaine 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 à tenir des listes et à nous assurer qu'elles sont à jour.

Un autre parcours intéressant pourrait rapporter 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. Cela 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 grand public, et que les bases de données relationnelles ne sont tout simplement pas à l'échelle pour ces besoins.

peut être un peu en retard, mais il y a un nombre croissant de projets utilisant Neo4j, les plus connus répertoriés sur Neo4j . Aussi NeoTechnology, la société derrière Neo4j, a quelques références sur sa page clients

_{Remarque: je fais partie de l'équipe Neo4j}