EventStore contre MongoDb
Je voudrais savoir quels avantages il y a à utiliser EventStore ( http://geteventstore.com ) par rapport à l'implémentation d'un événement vous-même dans un MongoDb.
La raison pour laquelle je demande, c'est que notre entreprise compte un certain nombre de personnes qui travaillent quotidiennement avec MongoDb. Cependant, ils ne fonctionnent pas avec Event Sourcing. Bien qu'ils ne soient pas complètement dans l'ignorance du sujet, ils ne sont pas non plus sur le point de commencer à le mettre en œuvre.
Je suis sur le point de démarrer un projet parfaitement adapté à l'Event Sourcing. Il y a environ 16 événements très bien définis et environ 7 projections bien définies. Je dis "à propos" parce que je sais qu'il y aura une demande pour plus de projections et d'événements une fois qu'ils verront le produit utilisé.
L'approche sera d'abord l'API, avec un REST Api que d'autres parties de notre organisation vont consommer.
Bien que j'aie beaucoup lu sur Event Sourcing comme Greg Young le définit, je n'ai jamais réellement implémenté de solution Event Sourcing.
Il s'agit d'un projet de champ vert. Aucune restriction technologique car nous allons tout exposer sous la forme d'une interface REST. Donc, si quelqu'un a une expérience de travail avec EvenStore ou Event Sourcing avec MongoDb, veuillez m'éclairer.
Également une question presque totalement non liée à la recherche d'événements: avez-vous déjà interrogé la boutique d'événements directement? Ou voudriez-vous toujours créer de nouvelles projections et rejouer l'événement pour remplir ces projections?
Avertissement Je suis Greg Young (si vous ne pouvez pas lire mon nom :))
Je vais répondre à cette question bien que je pense qu'elle sera probablement supprimée de toute façon. Cette question seule pour moi est un peu étrange, mais les réponses sont assez bizarres. Je ne prendrai pas le temps de répondre à chaque réponse individuellement, mais je mettrai plutôt tous mes commentaires dans cette réponse.
1) Il y a un commentaire que nous n'utilisons que sur une version personnalisée de mono qui est un détail mais ... Ce n'est pas le cas (et ce n'est pas le cas depuis plus d'un an). Nous attendions les correctifs critiques que nous avons faits en mono (par exemple threadpool.c pour frapper leur maître). C'est arrivé.
2) EventStore est sous licence BSD à 3 clauses. Je ne sais pas comment vous pourriez prétendre que nous ne sommes pas Open Source. Nous avons également une entreprise derrière elle et fournissons un support commercial.
3) Quelqu'un a mentionné que nous passions à la version 3 en septembre. La version 1 a été publiée il y a 2 ans. La version 2 a ajouté le clustering (évidemment quelques changements de rupture par rapport à un seul nœud). La version 3 ajoute une tonne de choses, y compris la possibilité d'avoir des consommateurs concurrents. Très peu de choses ont changé en termes de protocole client réel au cours de cette période (en particulier pour ceux qui utilisent l'API HTTP).
Ce qui me dérange vraiment dans les recommandations, cependant, c'est qu'ils ne semblent pas comprendre ce qu'ils comparent. Ce serait à peu près l'équivalent de moi disant "Lequel dois-je utiliser neo4j ou leveldb?". Vous pourriez vous construire une base de données graphique au-dessus de leveldb mais ce serait un peu de travail.
Dans ce cas, Mongo serait un moteur de stockage sur le magasin d'événements que l'OP devrait écrire lui-même. L'écriture d'un magasin d'événements de qualité de production est un exercice non trivial au-dessus d'un moteur de stockage si vous voulez avoir même les opérations les plus élémentaires.
J'ai écrit ceci en réponse à l'équivalent de la liste de diffusion de cette question :
Comment allez-vous faire ce qui suit avec Mongo?:
Écrire et lire des événements vers/depuis des flux avec commande/concurrence optimiste/etc
Ensuite:
Vos projections ne veulent pas lire les flux de la même manière qu'elles ont été écrites, les projections sont normalement intéressées par les types d'événements et veulent tous les événements de type T indépendamment du flux écrit et dans le bon ordre.
Vous souhaitez probablement également, par exemple, la possibilité de passer en direct des notifications d'événements poussés à la gestion des informations extraites (par exemple, interrogation), etc.
Il serait plus logique de comparer Kafka, datomic et Event Store.
Étant donné que les autres réponses ne parlent pas de l'outillage ou des avantages dans EventStore et se réfèrent uniquement aux avantages de MongoDB, je vais carillon. Mais notez que mon expérience est limitée.
Je vais commencer par les inconvénients ...
- Il existe de nombreux enregistrements qui peuvent conduire à décider quelle version vous allez prendre en charge activement. Alors que l'équipe a solidifié ses versions, le fait qu'elles soient arrivées à la version 3 pas même 18 mois après leur sortie devrait être un indicateur que vous devez extraire la version que vous supportez pour une autre version plus récente (qui peut également avoir un impact sur la plate-forme vous choisissez de déployer sur).
- Cela ne fonctionnera pas facilement sur toutes les plates-formes (surtout si vous essayez de passer à un environnement cloud ou à un conteneur lxc basé sur un docker). Cela est dû en partie à la communauté entourant d'autres bases de données telles que Mongo. Mais l'équipe semble avoir travaillé ses fesses sur les performances de lecture/écriture tout en maintenant la stabilité multiplateforme. Au fur et à mesure que le temps presse, j'ai découvert que vous ne voulez pas trop vous éloigner d'une implémentation de système d'exploitation nu-métal qui, de nos jours, n'est pas attrayante.
- Utilise une version spéciale de Mono. Trouver du soutien pour les anciennes versions de Mono ne sert qu'à rendre le processus plus d'un canal radiculaire.
- Pour tirer le meilleur parti des performances d'EventStore, vous devez vraiment penser à votre architecture. Les sorties EventStore vers des fichiers plats et les données d'événement peuvent croître assez rapidement. À quel taux d'échec des disques persistez-vous? Comment les choses sont-elles compressées? archivé? etc. Vous avez beaucoup de contrôle et le contrôle est orienté vers le stockage de vos données en tant qu'événements. Cependant, même si je suis sûr que Greg Young lui-même pourrait me citer à mon Grave les fonctionnalités qui optimisent et sauvegardent vos disques à long terme, je trouverai très probablement une communauté Mongo mature qui a eu de l'expérience dans des cas similaires.
Et les pros ...
- RESTful - C'est AtomPub. Votre flux n'est-il pas assez spécifique? Créez un autre et faites http obtient jusqu'à ce que votre cœur se contente. Préoccupé par le routage, effectuez un transfert HTTP. Préoccupé par la sécurité, mettez un proxy http devant. Facile!
- Vous disposez d'une belle suite d'outils et d'interface utilisateur pour tester et construire vos projections au fur et à mesure que vos événements commencent à générer de nouvelles données (par exemple, utilisez chrome pour déboguer vos projections ... ya ils sont écrits avec Java)
- Performances en lecture - Étant donné que l'application génère un fichier plat, vous pouvez obtenir une mise en cache au niveau du noyau et les exposer via http en un clin d'œil. Les index se trouvent également dans vos flux pour interroger les projections sur des ensembles de données plus volumineux (mais j'ai vraiment l'impression que les performances de l'index augmenteront avec vous au fil du temps).
Personnellement, je ne l'utiliserais pas pour une application de base/essentielle à la mission/ou croissante! Cependant, si vous avez une valise latérale pour garder votre environnement événementiel intéressant, je vous laisse faire! Personnellement, je dois m'en tenir à Mongo pour l'instant.