Supposons une configuration dans laquelle une application mobile communique avec son backend via une API, et les données résultant de cette communication (par exemple, les écritures de transactions basées sur JSON, entre autres) sont écrites et lues à partir d'une instance MongoDB.
Maintenant que je voudrais effectuer des analyses lourdes sur les données stockées dans mongo, devrais-je plutôt:
enregistrer les données directement dans le SGBDR en même temps que j'écris dans Mongo (donc le service backend appelle Mongo et après une écriture réussie appelle également SGBDR)
effectuer une lecture depuis Mongo (avec quelques intervalles) et charger de nouvelles données dans le SGBDR
Je crains que ces deux solutions nécessitent également une réingénierie théorique de Mongo sans schéma pour être en accord constant avec les relations et le schéma du SGBDR. Exige-t-il vraiment plus de planification pour tout changement de structure de document dans Mongo? Je dis intuitivement oui, mais je cherche des exemples du monde réel. J'espère que mon point est assez clair.
3 Réponses :
Peut-être que le modèle CQRS sera bon pour vous. Voir: https://martinfowler.com/bliki/CQRS.html
Vous pouvez utiliser le SGBDR pour le modèle d'écriture. Mongo - pour Read Model. Après chaque opération d'écriture dans le SGBDR, vous devez mettre à jour votre ReadModel (document MongoDB) en fonction des données du modèle d'écriture.
Je pense que l'option avec le moins d'effort d'ingénierie est d'utiliser un connecteur Kafka pour MongoDB, de sorte que le connecteur lise les modifications MongoDB à partir de l'oplog en temps quasi réel et écrive l'événement dans Kafka. Ensuite, à partir de Kafka, vous pouvez écrire les données dans une base de données relationnelle en utilisant un traitement de flux.
La double écriture depuis l'interface utilisateur n'est pas une bonne option car elle peut introduire de la latence, de la complexité et une surcharge opérationnelle. Que faire si l'écriture dans un DB échoue?
Il y a quelques contraintes qui doivent être comprises avant de vous lancer dans une solution ici. Le plus important d'entre eux est la latence. Dans quelle mesure vos données peuvent-elles être obsolètes?
Vous cherchez presque certainement une sorte de solution d'écriture différée ici, en retirant les données de MongoDB et en les écrivant dans votre entrepôt de données. La question est de savoir à quelle distance de votre MongoDB votre entrepôt de données peut-il se trouver? De nombreuses solutions basées sur un modèle d'extraction-transformation-charge (ETL) fonctionnent tous les soirs, afin de minimiser l'impact sur le système en ligne. Certains peuvent faire de même toutes les heures, mais auront plus d'impact potentiel sur le système en direct.
La prise en charge transaction par transaction n'est probablement pas nécessaire pour un système d'analyse. Vous voulez vraiment éviter cela si vous le pouvez, car cela impose beaucoup plus de charge sur les deux systèmes que ce qui est généralement justifié.
Pour répondre à votre deuxième question, oui, une fois que vous commencez à dépendre d'un schéma, il doit être stable. Il ne doit pas nécessairement être synchronisé avec votre schéma cible, mais votre processus ETL devra être conscient des deux et devra être modifié à chaque fois que l'un ou l'autre changera matériellement. Être "sans schéma" ne signifie pas qu'il n'y a pas de schéma, cela signifie simplement que le schéma n'est pas appliqué par le logiciel, mais plutôt par les dépendances sur le système.
J'aime beaucoup votre réponse (car cela confirme mes premières réflexions). Pourriez-vous s'il vous plaît commenter cette solution Kafka à partir d'une autre réponse? Est-ce que «lire les modifications de MongoDB à partir de l'oplog en temps quasi réel» ajoute une charge supplémentaire à Mongo DB dans la mesure où vous le pensiez? Je comprends que la lecture du journal n'est pas la même chose que la lecture de la base de données.
D'accord, mais le journal peut également avoir des contraintes d'E / S. De plus, il y aura certainement plus de charge sur le serveur cible à mesure que les enregistrements sont rejoués. Enfin, comme vous diffusez des événements à partir de l'oplog, il est très probable que vous deviez accéder à votre banque de données en direct pour obtenir des données supplémentaires afin de les écrire correctement dans la base de données. Cela entraînera également une charge. Relationnel et NoSQL sont rarement 1-1 dans leurs dispositions de schéma (ils ne devraient pas l'être!), Il faudra donc un certain massage pour l'adapter.
On ne sait pas pourquoi vous avez absolument besoin de MongoDB en premier lieu. Pouvez-vous repenser en utilisant Elassandra (Cassandra + ES) à la place?
Pouvez-vous expliquer pourquoi devrais-je envisager un changement? Mongo a été sélectionné par les développeurs comme backend principal de l'application, je dois améliorer l'architecture pour des analyses avancées.
Considérant que NoSQL doit être hautement adapté à vos besoins et idéalement pesé par les architectes, et idéalement,: -) ... Données structurées / non structurées, écritures / lectures, latence, infra, compromis CAP, master- architecture pilotée ou peer-to-peer, verrouillage de la complexité architecturale, etc. chaque NoSQL Soln a ses propres avantages et inconvénients. S / O connaissant votre UC, il n'est pas vraiment possible de suggérer le contraire; Vous pouvez envisager d'utiliser Apache Spark + MongoDB pour l'analyse. Si vous voulez avoir des écritures élevées / des analyses fortes, vous devriez envisager d'utiliser Cassandra + Spark au lieu de Cassandra + ElasticSearch ...