Que pensez-vous de Raven DB ?

Question

Que pensez-vous de Raven DB ?

1. Comment puis-je utiliser Raven DB pour le stockage de données dans un environnement d'hébergement web partagé, puisque Raven DB est interagi par HTTP ?
2. Y a-t-il des domaines dans lesquels Raven DB est particulièrement bien ou moins bien adapté ?
3. Comment se classe-t-il parmi les alternatives, du point de vue d'un développeur .NET ?

Answer 1

Le contexte typique que je vois pour la base de données Raven est un site web ou une application web unique avec des pages principalement CRUD, éventuellement avec beaucoup de champs de nature dynamique/optionnelle, et un besoin particulier d'extensibilité.

Je ne la vois pas bien adaptée aux logiciels qui ont besoin de fonctions avancées de rapport ou d'analyse de données, ni comme base de données centrale sur laquelle reposent deux ou plusieurs applications très hétérogènes.

Le stockage de données dans un environnement d'hébergement Web semble convenir parfaitement à Raven. En fait, les trois principaux fournisseurs de services en nuage (Amazon, Google et Microsoft) proposent tous à leurs clients une sorte de stockage de données non relationnel. Raven est livré avec une interface d'administration basée sur un navigateur, ce qui rend sa gestion à distance d'autant plus pratique.

Ce que je trouve bien dans Raven DB :

• Il rend votre couche ORM inutile puisqu'il n'y a plus de décalage d'impédance entre les objets et le stockage de données relationnelles (le plus grand avantage pour moi).
• Les données sont accessibles sous une forme RESTful et lisible par l'homme.
• Beaucoup plus facilement extensible qu'un rdbms.
• API .NET avec interrogation Linq.
• S'intègre bien à l'architecture de style "Domain Driven Design". Les documents de Raven DB sont fondamentalement des agrégats et les recommandations pour modéliser vos documents sont les mêmes que celles pour constituer des agrégats DDD.

Ce qui l'est moins :

• Si vous voulez tirer pleinement parti des performances de Raven, votre stockage de données aura probablement tendance à imiter beaucoup vos interfaces graphiques.
• L'ignorance de la persistance souffre un peu de ce que j'ai vu jusqu'à présent. L'utilisation de Raven semble avoir un impact considérable sur la façon dont vous concevez vos objets. Par exemple, il semble qu'une entité qui fait référence à un objet dans un autre agrégat (un autre document, en termes de Raven) ne peut pas contenir une référence directe à cet objet comme vous le feriez normalement dans un modèle d'objet, mais doit stocker son ID à la place. Si vous voulez conserver l'entité telle quelle, cet ID doit suivre le format de la clé du document Raven, ce qui, à mon avis, rend plus difficile la recherche de l'objet original qu'il représente.

Des doutes qui devront être levés :

• Performance. Ayende a publié quelques mesures de performance prometteuses, mais je suppose qu'elles doivent être généralisées et répétées sur des projets à plus grande échelle. Je suis particulièrement impatient de voir comment le système de concurrence optimiste de Raven se comporte dans un contexte de transactions intensives.
• Adoption. À mon avis, les bases de données NoSQL ne survivront pas sans un écosystème solide autour d'elles, tant en termes de communauté de soutien que d'outils disponibles.

Answer 2

Je dirais que le plus gros inconvénient est le octroi de licences et le fait que vous ne pouvez utiliser que C# pour cela.

Je suis un grand fan de C#, mais lorsque vous créez des applications pour le web, les choses changent très vite. On ne sait jamais ce que l'on va coder dans les 5 prochaines années.

Le site octroi de licences est vraiment le tueur ici. Il n'est gratuit que si vous l'utilisez avec un projet open source. Si vous l'utilisez pour un produit, vous devez le payer... c'est une déception.

En comparaison MongoDB est totalement open source et a beaucoup beaucoup de conducteurs comme 3 pilotes C#, Ruby, C, Haskel, Php, etc. De plus, il fonctionne sous Windows, Mac et Linux. C'est aussi une base de données bien testée. De grands magasins l'utilisent comme Amazon, Facebook, FourSquare, New York Times, etc.

Answer 3

Je ne peux pas le recommander assez. Nous l'utilisons pour Sonatribe. Nous utilisons les bundles de réplication et de versioning ainsi que le bundle de sécurité. C'est absolument génial et nous bénéficions d'un support de première classe de la part des gars de Raven Tools.

Answer 4

Une fonctionnalité très agréable, pour moi, est de l'utiliser comme un magasin de données facile pour une application client autonome. Vous pouvez sauvegarder vos données dans un fichier xml, un fichier ou quelque chose comme SQLite (éventuellement avec NHibernate), mais rien ne se compare à la facilité d'utilisation de RavenDb.

Si vous construisez bien vos classes, avec des agrégats et une approche orientée domaine, vous pouvez simplement passer vos objets, et RavenDb fait le reste. Pas besoin de fichiers de mappage, d'attributs de sérialisation, ou d'autres trucs compliqués. Et pas besoin de compromettre votre modèle (ce qui est nécessaire pour NHibernate par exemple).

Le fait qu'il soit préférable d'utiliser une approche axée sur le domaine avec des agrégats est une bonne chose, et non une mauvaise.

Answer 5

En ce qui concerne ma première préoccupation ci-dessus, à savoir les environnements d'hébergement partagé, il semble que le serveur puisse être intégré à l'application. Je n'ai pas encore trouvé comment l'exécuter dans un environnement qui n'est pas de confiance totale.