Je suis en train de mettre en œuvre un portail Web SINATRA / RAILS basé sur les rails pouvant éventuellement avoir peu nombreux: de nombreuses relations entre les tables / modèles. Ceci est une équipe d'un homme et à temps partiel, mais une application du monde réel.
J'ai discuté de mon entité avec quelqu'un et j'ai été conseillé d'essayer Neo4j. En venant du monde de l'entreprise «non sexy», mon inclination est d'utiliser la DB relationnelle jusqu'à ce qu'elle arrête de mettre à l'échelle ou de devenir cauchemar à cause de la colère, etc., puis de penser à autre chose.
Cependant,
Vous recherchez des usecases où NEO4J est meilleur, surtout au protycle / phase initiale d'un projet. Je comprends si le site Web se développe, je pourrais finir de plusieurs technologies persistantes comme S3, relationnelle (PG), Mongo, etc.
En outre, il serait bon de savoir comment il joue avec des rails / écosystème rubis.
mise à jour1:
J'ai beaucoup de bonnes réponses et on dirait que la bonne chose à faire est de rester avec des postgres pour l'instant (surtout que je déploie sur Heroku)
Cependant, l'idée d'être moins schématique est tentante. Fondamentalement, je pense à une approche où vous ne définissez pas de DataModel tant que vous n'avez pas dit 100-150 utilisateurs et vous avez compris vous-même un bon schéma (cas d'utilisation des entreprises) pour votre produit, tandis que vous venez de diaboliser le concept et d'obtenir Commentaires avec des inscriptions limitées. Ensuite, on peut décider d'un schéma et commencer par relation relationnelle.
serait bien de savoir s'il existe une option de schéma / moins de persistance facile à utiliser (basée sur la facilité à utiliser / configuration pour un nouvel utilisateur) qui pourrait abandonner la mise à l'échelle, etc.
3 Réponses :
Les bases de données graphiques doivent être considérées si vous avez un modèle de données vraiment chaotique. Ils étaient nécessaires pour exprimer des relations très complexes entre les entités. Pour ce faire, ils stockent les relations au niveau des données, tandis que les RDBM utilisent une approche déclarative. Les relations de stockage ne sont logiques que si ces relations sont très différentes, sinon vous finirez simplement à dupliquer les données de plus et de plus, prenant beaucoup d'espace pour rien. Pour exiger une telle variété de relations, vous devez gérer une quantité énorme de données. C'est ici que les bases de données de graphes brillent car instantanée de tonnes de jointures, ils choisissent simplement un enregistrement et suivent ses relations. Pour soutenir ma déclaration: vous remarquerez que chaque Les cas d'utilisation sur le site Web de Neo4J traitent avec des données très complexes.
En bref, si vous ne vous sentez pas concerné par ce que j'ai dit ci-dessus, je pense que vous devriez utiliser une autre technologie. S'il s'agit uniquement de la mise à l'échelle, du schéma ou du démarrage rapide, consultez d'autres solutions NOSQL (plus spécifiquement, des bases de données orientées de la colonne ou des documents). Sinon, vous devriez rester avec PostgreSQL. Vous pouvez aussi, comme vous l'avez dit, envisagez Polyglot Persistence ,
À propos de votre mise à jour, vous pourriez envisager htstore . Je pense que cela correspond à vos besoins. C'est un module PostgreSQL qui fonctionne également sur Heroku.
Merci d'avoir suggéré HSTORE. Il semble bon et convient potentiellement aux cas de prototypage rapide et d'utilisation de la démonstration. D'autant plus qu'il est offert par Heroku !! ..so My Rails Apps peut les utiliser. Étonnamment, je ne vois pas beaucoup d'exemples de GitHub et de poteaux de blog, étant donné qu'il a l'air si simple pour le prototypage rapide. Pour le moment collera à Postgres, mais il sera basculer une fois que je me trouve plus de temps sur les conceptions de schéma
Il y a un gemme hstore active-record [mais pas de datamappper gem :(] gem 'aciverecord-postgres-hstore' GITUB.COM/GITUMIS/ACTIGECORD-POSTGRES-HSTORE
Cela ne signifie pas nécessairement qu'il existe une quantité énorme de données. Dans notre cas, nous utilisons PostgreSQL pour stocker des données utilisateur et des ensembles de données, ainsi que NeO4J pour une analyse de complexité d'une population et le stockage de vastes quantités de relations. Cela aide vraiment avec ce lac de données.
Je ne pense pas que je conviens que vous ne devez utiliser qu'une base de données graphique lorsque votre modèle de données est très complexe. Je suis sûr qu'ils pourraient également gérer un simple modèle de données / relations de données.
Si vous n'avez aucune expérience préalable avec Neo4J ou Postgres, alors probablement les deux avec beaucoup de temps pour bien apprendre.
Certaines choses à garder à l'esprit lorsque cueillette:
Il ne s'agit pas seulement de développer une technologie de base de données. Vous devriez également envisager le déploiement. Quelle est la facilité de déployer et d'échelle Postgres / Neo4j?
Considérez la communauté et les outils autour de chaque technologie. Y a-t-il une mappeuse de données pour Neo4j comme il y a pour Postgres?
considère que les modèles de données sont considérablement différents entre les deux. Si vous pouvez déjà penser de manière relative, alors je serais probablement coller avec Postgres. Si vous allez avec Neo4J, vous allez faire beaucoup d'erreurs pendant plusieurs mois avec vos modèles de données.
Au fil du temps, j'ai appris à garder cela simple quand je peux. Postgres pourrait être le choix ennuyeux par rapport à Neo4j, mais ennuyeux ne vous tient pas la nuit. =)
Aussi je ne vois jamais personne la mentionner, mais vous devriez regarder Riak ( http://basho.com/riak/ ) aussi. C'est une base de données de documents qui fournit également des relations entre les objets. Pas aussi mature qu'une base de données graphique, mais il peut connecter rapidement quelques entités rapidement.
++ pour recommander Riak - Aimer! Cependant, nous avons eu un ingénieur de Basho rond récemment pour donner une conversation technique et il a complètement rejeté des liens - ils découragent l'utilisation d'eux maintenant plutôt que de stocker simplement une (liste des) clés dans le document pour les objets enfants et ensuite avoir le Appel d'application aller les obtenir.
Ah. Bon à savoir. Oui, j'ai vu les liens dans la documentation et la pensée, "Wow! Enfin une base de données de documents avec des" relations "". Ils ont dit que, étant donné que les liens utilisaient map / réduction pour les utiliser de manière peu profonde - en d'autres termes, n'essayez pas de faire un gros graphique. Bummed ils découragent la pratique - je pensais que c'était une idée fraîche.
Le choix le plus approprié dépend de quel problème vous essayez de résoudre.
Si vous avez simplement quelques nombreuses tables, une base de données relationnelle peut aller bien. En général, il existe une meilleure aide au mapper pour des bases de données relationnelles, car elles sont beaucoup plus âgées et disposent d'une interface standardisée et d'une structure de colonne de rangée. Ils ont également été améliorés depuis longtemps, ils sont donc stables et optimisés pour ce qu'ils font.
Une base de données graphique est meilleur si par ex. Votre problème concerne davantage les connexions entre les entités, en particulier si vous avez besoin de connexions de distance plus élevées, comme "Détecter les cycles (de longueur non spécifiée)", certains "Qu'est-ce que les amis-d'un ami d'un ami". Des choses comme ça deviennent peu lourdes lorsqu'ils sont limités à SQL rejoint. Un problème de langage spécifique comme cypher dans le cas de NeO4J rend cela beaucoup plus concis. À l'inconvénient, il y a des mappeurs entre DBS graphiques et objets, mais pas pour chaque cadre et chaque langue sous le soleil.
J'ai récemment mis en place un prototype de système utilisant NeO4J et il était très utile de pouvoir parler de la structure et des connexions de nos données et de pouvoir modéliser celui-ci dans le stockage de données. En outre, l'ajout d'autres connexions entre les points de données était facile, NEO4J étant un stockage de schéma. Nous avons fini par passer à MongoDB en raison de problèmes avec la performance de l'écriture, mais je ne pense pas que nous aurions pu terminer le prototype avec cela en même temps.
D'autres datasfs de Nosql tels que le document basé sur le document, la colonne, la valeur de la clé couvrent également des usecases spécifiques. Polyglot Persistence est définitivement quelque chose à examiner, alors gardez votre choix de backend raisonnablement séparé de votre logique commerciale, afin de vous permettre de changer votre technologie plus tard si vous avez appris quelque chose de nouveau.
Tout d'abord, à mon avis, c'est la meilleure réponse. J'aimerais en savoir plus sur la raison pour laquelle vous avez changé de Neo4J à MongoDB. Et avez-vous eu des regrets plus tard en raison d'un commutateur ou êtes-vous toujours satisfait du commutateur? Merci
La mise à l'échelle et le frastien ne sont pas les principales raisons pour lesquelles je choisirais une base de données graphique. Pouvez-vous fournir plus d'informations sur votre domaine? Modélisez-vous quelque chose qui est un réseau? Aurez-vous besoin de calculer des statistiques réseau ou d'exécuter des algorithmes de graphique? La présence de plusieurs tableaux de plusieurs à plusieurs peut indiquer un réseau, comme vous pouvez considérer ces relations à être des bords. Que représentent vos bords?