Quels sont les cas d'utilisation des bases de données basées sur des graphiques (http://neo4j.org/)? [fermé]
j'ai beaucoup utilisé des DB 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 basées sur des graphiques? Quels sont les avantages et les inconvénients d'une convivialité prespective?
Avez-vous utilisé dans un environnement de production? Quelle était l'exigence qui vous a incité à les utiliser?
7 réponses
j'ai utilisé une base de données graphique dans un emploi précédent. Nous n'utilisions pas neo4j, c'était une chose maison construite au-dessus de Berkeley DB, mais c'était similaire. Il a été utilisé dans la production (c'est toujours).
la raison pour laquelle nous avons utilisé une base de données de graphe é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 graphe. Le système nécessaire pour stocker collections d'objets qui n'ont pas de schéma fixe et qui sont reliés entre eux par des relations. Pour raisonner au sujet des données, le système a dû faire beaucoup d'opérations qui seraient un couple de Travers dans une base de données de graphe, mais ce serait des requêtes assez complexes dans 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 leurs propres données et les greffer sur notre modèle, il pourrait généralement être fait sur place par le représentant des ventes. La flexibilité nous a également aidés lorsque nous avons conçu une nouvelle fonctionnalité, nous empêchant ainsi d'essayer d'intégrer de nouvelles données dans un modèle de données rigide.
ayant une base de données bizarre nous permet de construire beaucoup de nos autres technologies bizarres, nous donnant beaucoup de sauce secrète pour distinguer notre produit de ceux de nos concurrents.
Le principal inconvénient était que nous n'étions pas l'utilisation de la technologie de base de données relationnelle standard, qui peut être un problème lorsque vos clients sont entreprenants. 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). Une des équipes a 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-seulement, mais heureusement Oracle acheté Berkeley DB. Nous avons également dû écrire beaucoup d'outils supplémentaires - nous ne pouvions pas utiliser Crystal Reports pour exemple.
l'autre inconvénient de notre base de données graphique était que nous l'avons construite nous-mêmes, ce qui signifie que lorsque nous avons un problème (généralement avec évolutivité) nous avons dû 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 construisez un produit pour les clients d'entreprise et 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 graph, utilisez une base de données graph. Si ça ne va qu'à autre chose, utilisez ça.
si votre application n'a pas besoin de s'adapter à l'architecture blub actuelle, utilisez une base de données de graphiques, ou CouchDB, ou BigTable, ou tout ce qui convient à votre application et vous pensez est cool. Il peut vous donner un avantage, et son plaisir à essayer de nouvelles choses.
Peu importe ce que vous avez choisi, essayez de ne pas construire le moteur de base de données vous-même à moins que vous aimez vraiment construire des moteurs de base de données.
nous travaillons avec L'équipe Neo depuis plus d'un an et nous sommes très heureux. Nous modélisons les artefacts savants et leurs relations, qui est spot on pour un graphique 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 en utilisant Neo4j est très simple et il a la plus faible / la plus rapide performance pour R/W de toutes les autres solutions que nous avons essayées.
Pour être honnête, j'ai un hard time not penser en termes de graphe / réseau parce que c'est tellement plus facile que de concevoir des structures de table alambiquées pour tenir les propriétés de l'objet et les relations.
cela dit, Nous stockons certaines informations dans MySQL simplement parce qu'il est plus facile pour les entreprises D'exécuter des requêtes SQL rapides contre. Pour effectuer les mêmes fonctions avec Neo, nous aurions besoin d'écrire du code que nous n'avons tout simplement pas la bande passante pour l'instant. Dès que nous le ferons bien que, je déplace toutes ces données à Neo!
bonne chance.
deux points:
tout d'abord, sur les données que j'ai travaillé avec les 5 dernières années dans SQL Server, j'ai récemment frappé le mur de l'évolutivité avec SQL pour le type de requêtes que nous avons besoin d'exécuter (rapports imbriqués...vous savez...graphique.) J'ai joué avec neo4j, et mes temps de recherche sont de plusieurs ordres de grandeur plus rapides quand j'ai besoin de ce genre de recherche.
deuxièmement, au point que les bases de données graphiques sont dépassées. Euh...non. Dès le début, comme les gens essayaient de comprendre comment stocker et rechercher des données efficacement, ils ont créé et joué avec des modèles de base de données de style graphe et réseau. Ceux-ci ont été conçus de sorte que le modèle physique reflétait 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. Donc, ce type D'IBM nommé Codd recherchait des moyens efficaces pour organiser et stocker des données structurées et est venu avec l'idée pour le relationnel modèle de base de données. Et c'était bon, et les gens étaient heureux.
Qu'est-ce qu'on a là? Deux outils pour deux buts différents. Les modèles de base de données graphiques sont très bons pour représenter les 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 profond. On est bon pour un type de données, l'autre est bon pour les autres types de données.
pour reprendre l'expression, il n'y a pas de balle en argent. Sa très courte vue pour dire que les modèles de base de données de graphe sont périmés et d'utiliser on renonce à 40 ans de progrès. C'est comme dire qu'utiliser C c'est renoncer à tout le progrès technologique que nous avons traversé pour obtenir des choses comme Java et C#. Ce n'est pas vrai. 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 nous ne savions pas que nous avions) était que nous devions toujours planifier le schéma à l'avance. Un autre problème que nous savions que nous avions était le mappage des données vers les objets de domaine et retour.
maintenant nous venons de commencer à essayer neo4j et il semble que cela résolve les deux problèmes pour nous. La possibilité d'ajouter des propriétés différentes à chaque nœud (et lien) 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. Construire le modèle de données dans la base de données peut être fait d'une manière beaucoup plus agile et dynamique, et cela simplifie considérablement notre code.
et comme le modèle d'objet en code est généralement une structure de graphe, la cartographie à partir de la base de données est également plus simple, avec moins de code et donc moins de bogues.
et en prime supplémentaire, notre le code prototype initial pour charger nos données dans neo4j fonctionne en fait plus rapidement que la version précédente de MySQL. Je n'ai pas de solides chiffres sur cette (encore), 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. Est-ce qu'il correspond mieux aux tableaux ou aux graphiques? Décider en faisant quelques prototypes, charger les données et jouer avec elle. Utilisez neoclipse pour examiner différentes vues des données. Lorsque tu l'as fait, j'espère que tu sais si tu es sur une bonne voie ou pas.
je construis un intranet dans mon entreprise.
je suis intéressé à comprendre comment charger des données qui ont été stockées dans des tables (Oracle, MySQL, SQL Server, Excel, Access, diverses listes aléatoires) et le chargement dans Neo4J, ou une autre base de données de graphe. Plus précisément, que se passe-t-il lorsque des données communes chevauchent des données déjà présentes dans le système?
Oui, je sais que certaines données sont mieux modélisées en RDBMS, mais j'ai cette idée me démangeant, que lorsque vous besoin de superposer plusieurs tableaux distincts, le modèle de graphique est meilleur que la structure de tableau.
Par exemple, je travaille dans un environnement de fabrication. Il y a un grand projet sur lequel nous travaillons et en raison de la complexité, chaque ministère a créé un tableur Excel séparé qui a un BOM (Bill of Materials) hiérarchie dans une colonne à gauche et puis plusieurs colonnes de notes et de vérifications faites par les personnes qui ont fait ces feuilles.
ainsi, l'un des problèmes est de fusionner toutes ces notes en une seule" vue " afin que quelqu'un puisse voir toutes les questions qui doivent être abordées dans une partie particulière.
le deuxième problème est qu'un tableur Excel craint à représenter un BOM hiérarchique quand un composant commun est utilisé dans plus d'un sous-ensemble. Cela signifie que, si quelqu'un écrit une note sur le relais P34 dans le sous-ensemble d'allumage, le même commentaire devrait être associé avec les relais P34 utilisés dans le sous-ensemble conducteur. Cela ne se produira pas dans la feuille de calcul excel.
pour l'intranet de l'entreprise, je veux pouvoir chercher n'importe quoi facilement. Telles que des données relatives à un numéro de pièce, une structure de BOM, un numéro de téléphone, une adresse e-mail, une politique de l'entreprise, ou une procédure. Je veux même étendre cela pour gérer les ressources matérielles informatiques, et les logiciels installés.
j'imagine qu'une fois le réseau d'information commence pour obtenir peuplé, vous pouvez commencer à faire cool traversals tels que "je veux écrire un email à tous ceux qui travaillent sur le projet XYZ". Les gens auront été associés au projet parce qu'ils seront étiquetés comme créant et modifiant les données dans le cadre du 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 des personnes qui ont construit le projet XYZ. Les liens personnes se connecteront à leurs adresses e-mail. Si par leur participation au projet XYZ, ils seront inclus dans mon courriel. Cela contraste fortement avec le fait qu'une secrétaire essaie de tenir à jour une liste des personnes qui travaillent sur le projet. Nous produisons beaucoup de listes. Nous passons beaucoup de temps à maintenir des listes et de s'assurer qu'ils sont à jour. Et la plupart n'ajoutent aucune valeur à nos produits.
un autre cool transversal pourrait rapporter tous les ordinateurs qui ont un certain morceau de logiciel 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 d'avoir la dernière copie. Il serait également utile pour le suivi des licences.
voici un bon article qui parle des besoins que les bases de données non relationnelles remplissent: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
il fait un bon travail à signaler (en dehors du nom) que les bases de données relationnelles ne sont pas défectueux ou mal, c'est juste que les gens de nos jours commencent à traiter de plus en plus de données dans les logiciels grand public et les sites web, et que les bases de données relationnelles viennent de wont échelle pour ces besoins.
pourrait être un peu en retard, mais il y a un nombre croissant de projets utilisant Neo4j, les plus connus énumérés à Neo4j . Aussi NeoTechnology, la société derrière Neo4j, a quelques références à leurs clients page
Note: je fais partie de L'équipe Neo4j