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

Question

J’ai beaucoup utilisé les bases de données relationnelles et j’ai décidé de choisir d’autres types disponibles.

Ce produit en particulier a l'air beau et prometteur: http://neo4j.org/

Quelqu'un at-il utilisé des bases de données à base de graphes? Quels sont les avantages et les inconvénients d’une perspective d’utilisation?

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

Answer 1

J'ai utilisé une base de données de graphes dans un travail précédent. Nous n’utilisions pas neo4j, c’était un système interne construit au sommet de Berkeley DB, mais similaire. Il a été utilisé en production (il l’est toujours).

La raison pour laquelle nous avons utilisé une base de données de graphes était que les données stockées par le système et les opérations effectuées par le système avec ces données étaient exactement le point faible des bases de données relationnelles et 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 devait effectuer de nombreuses opérations qui consisteraient en 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 le temps de développement rapide et la flexibilité. Nous pourrions rapidement ajouter de nouvelles fonctionnalités sans impacter les déploiements existants. Si un client potentiel souhaite importer certaines de ses propres données et les greffer sur notre modèle, cela peut généralement être fait sur site par le représentant des ventes. La flexibilité a également été utile lors de la conception d’une nouvelle fonctionnalité, nous évitant ainsi d’insérer de nouvelles données dans un modèle de données rigide.

Avec une base de données étrange, nous avons pu construire beaucoup de nos autres technologies étranges et beaucoup de secrets 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 poser problème lorsque vos clients sont des entreprises. Nos clients nous demandaient pourquoi nous ne pouvions pas simplement héberger nos données sur leurs grappes Oracle géantes (nos clients disposaient généralement de grands centres de données). L’un des membres de l’équipe a 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’originale. Au moins une grande entreprise avait même une politique exclusivement Oracle, mais heureusement, Oracle a acheté Berkeley DB. Nous avons également dû rédiger 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’avions construite nous-mêmes. En d’autres termes, lorsque nous rencontrions un problème (en général 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 construisez un produit pour les clients professionnels 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 au modèle graphique, utilisez une base de données graphique. Si cela ne fait que quelque chose d'autre, utilisez-le.

Si votre application n'a pas besoin de s'intégrer à l'architecture de blub actuelle, utilisez une base de données graphique, ou CouchDB, ou BigTable, ou tout ce qui convient à votre application et que vous jugez cool. Cela pourrait vous donner un avantage et c'est amusant d'essayer de nouvelles choses.

Quoi que vous ayez choisi, essayez de ne pas créer le moteur de base de données vous-même, à moins que vous n'aimiez vraiment créer des moteurs de base de données.

Answer 2

Nous travaillons avec l’équipe Neo depuis plus d’un an et nous sommes très heureux. Nous modélisons les artefacts scientifiques 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 graphe / réseau car c’est beaucoup plus facile que de concevoir des structures de tables compliqué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 les entreprises de lancer 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. Dès que nous le faisons cependant, je transfère toutes ces données vers Neo!

Bonne chance.

Answer 3

Deux points:

Premièrement, en ce qui concerne les données sur lesquelles je travaille depuis 5 ans avec SQL Server, j'ai récemment touché le mur de l'évolutivité avec SQL pour le type de requêtes que nous devons exécuter (relation imbriquée ... vous savez. ..graphes). Je joue 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. Dès le début, alors que les gens essayaient de comprendre comment stocker et rechercher des données efficacement, ils ont créé et utilisé des modèles de base de données de graphes et de réseaux. Celles-ci ont été conçues 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 IBM nommé Codd était à la recherche de moyens efficaces pour organiser et 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 bases de données graphiques sont très utiles pour représenter des données semi-structurées et les relations entre entités (qui peuvent ou non exister). Les bases de données relationnelles conviennent aux données structurées ayant un schéma très statique et où les profondeurs de jointure ne sont pas très profondes. L’un est bon pour un type de données, l’autre pour d’autres types de données.

Pour inventer cette phrase, il n’ya pas de Silver Bullet. Sa vision très courte de dire que les modèles de bases de données de graphes sont périmés et que l’on en utilise un cède 40 ans de progrès. Cela revient à dire que l’utilisation de C, c’est abandonner tous les progrès technologiques que nous avons accomplis pour obtenir des éléments 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.

Answer 4

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 avons rencontrés (mais que nous n'avions pas compris) était que nous devions toujours planifier le schéma à l'avance. Un autre problème que nous savions avoir était la mise en correspondance des données avec des objets de domaine et inversement.

Nous venons tout juste 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 à chaque relation) nous a permis de repenser toute notre approche des données. C'est comme les langages dynamiques versus statiques (Ruby versus Java), mais pour les bases de données. La création du modèle de données dans la base de données peut être réalisée de manière beaucoup plus agile et dynamique, ce qui simplifie considérablement notre code.

Et comme le modèle d’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 bugs.

De plus, notre prototype de code initial pour le chargement de nos données dans neo4j fonctionne plus rapidement 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 à la fin de la journée, le choix devrait probablement être basé principalement sur la nature de votre modèle de domaine. Mappe-t-il mieux les tableaux ou les graphiques? Décidez de faire 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, nous espérons que vous saurez si vous faites une bonne chose ou non.

Answer 5

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 graphes. 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 cette idée me démange: lorsque vous devez superposer plusieurs tables distinctes, le modèle de graphique est meilleur que la structure de la table.

Par exemple, je travaille dans un environnement de fabrication. Nous travaillons sur un projet majeur et, en raison de la complexité de ce dernier, chaque service a créé un tableur Excel séparé comportant un BOM (Bill Of Materials) " dans une colonne à gauche, puis plusieurs colonnes de notes et de contrôles effectués par les personnes qui ont réalisé 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 abordés dans une partie particulière.

Le deuxième problème est qu’une feuille de calcul Excel réussit à représenter une nomenclature hiérarchique lorsqu'un composant commun est utilisé dans plusieurs sous-assemblages. Ce qui 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 d'entraînement du moteur. Cela ne se produira pas dans le tableur Excel.

Pour l'intranet de la société, je souhaite pouvoir tout rechercher facilement. Telles que des données liées à un numéro de pièce, une structure de nomenclature, un numéro de téléphone, une adresse électronique, une stratégie d'entreprise ou une procédure. Je souhaite même étendre cela à la gestion des actifs matériels et des logiciels installés.

Je pense qu’une fois que le réseau d’information commence à se peupler, vous pouvez commencer à faire des parcours intéressants tels que "Je souhaite écrire un courrier électronique à toutes les personnes travaillant 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 ensemble énorme contenant tout ce qui concerne le 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 électroniques. Donc, par leur implication dans le projet XYZ, ils seront inclus dans mon email. Cela contraste vivement avec le fait qu'une secrétaire essaye 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. Et la plupart n’ajoute aucune valeur à nos produits.

Une autre bonne traversée pourrait signaler tous les ordinateurs sur lesquels un logiciel est installé, par version. Ce rapport peut être utilisé pour générer des tâches permettant de supprimer des copies supplémentaires d’anciens logiciels et de mettre à jour les personnes qui doivent disposer de la copie la plus récente. Cela serait également utile pour le suivi des licences.

Answer 6

Voici un bon article sur les besoins des bases de données non relationnelles: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

Il fait du bon travail en soulignant (à part le nom) que les bases de données relationnelles ne sont pas erronées ou fausses, mais que de nos jours, les gens commencent à traiter de plus en plus de données dans des logiciels et des sites Web grand public, et que des bases de données relationnelles simplement pas à l'échelle pour ces besoins.

Answer 7

est peut-être un peu en retard, mais il y a de plus en plus de projets utilisant Neo4j, les plus connus étant listés sur Neo4j . NeoTechnology, la société à l'origine de Neo4j, a également des références sur la page de leurs clients

.

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