SQL Server et Mongo peuvent-ils être utilisés ensemble?

Nous avons un grand site axé sur les nouvelles qui a un trafic Web élevé. L'architecture est votre DB souvent vue - Repo Layer - Services Layer - Asp.Net MVC. Le problème que nous avons vu concerne les performances de lecture. Il s'avère que toutes ces choses d'objets de domaine DDD sont idéales, en théorie, pour les règles métier, mais ont rendu la vie plus difficile lorsqu'il s'agit d'optimiser les performances de lecture.

Comme solution, j'envisage quelque chose de complètement nouveau (pour nous): utiliser noSQL. J'aimerais utiliser une base de données noSQL pour les données présentées sur notre site Web. Nous ne pouvons pas nous débarrasser de notre SQL Server (du moins pas de sitôt), mais il me semble qu'une étape pratique serait d'utiliser Mongo comme base de données de requêtes pour tout nouveau développement.

Ma question est de savoir s'il est possible d'utiliser SQL Server comme base de données d'enregistrement et Mongo comme base de données de requête ensemble ?

Ainsi, lorsque l'un de nos éditeurs met à jour un enregistrement, les données sont stockées dans SQL Server. Cela est nécessaire, car il y a trop de code hérité qui ne peut pas être réécrit du jour au lendemain.

Mais lorsqu'un internaute sur le site Web consulte un article ou une liste d'articles, j'aimerais profiter des performances de Mongo par rapport à SQL Server. Afin de garder les données quelque peu à jour, disons 15 minutes ou moins, les données SQL Server devraient actualiser Mongo. RDBMS a des outils de réplication pour des opérations comme celle-ci et je me demande s'il existe quelque chose pour faire la même chose de SQL Server à Mongo. Serveur Lync, peut-être?

Vous avez rencontré un problème que beaucoup ont devant vous ... une base de données optimisée pour la lecture est rarement bonne pour l'efficacité d'écriture et vice versa. Une approche qui a évolué à partir de cet obstacle en lecture-écriture est CQRS (Command Query Responsibility Segregation). Malgré Wikipédia reliant les deux CQRS et CQS sont techniquement différents. CQS exige simplement qu'une méthode effectue une modification (commande) ou demande des informations (requête) jamais les deux.

CQRS va plus loin et spécifie que vous disposez d'un modèle distinct pour les requêtes et les commandes. Cette étape unique permet de séparer votre base de données de lecture et d'écriture. C'est ce que tu veux faire.

Je ne peux pas dire que je suis un expert de Mongo ou que je l'ai configuré pour fonctionner avec SQL Server. Mais d'après ma compréhension, les gens utilisent Mongo comme une vue dénormalisée de leur base de données transactionnelle. La mise à jour de Mongo à partir de la base de données transactionnelle peut se résumer à l'exécution d'un agent SQL. Ou avoir un service distinct pour interroger la base de données.

Une alternative encore meilleure serait que votre service de commandement déclenche un événement chaque fois qu'une mise à jour est effectuée. Vous auriez alors un service qui aurait écouté cet événement et mis à jour le MongoDB avec ces informations. C'est l'approche fondamentale du Event Sourcing (recherchez Event Sourcing sur la page).

Greg Young, l'un des leaders d'opinion dans le monde DDD, écrit actuellement un livre de la série Fowler Signature sur CQRS intitulé Event-Centric (il s'appelait auparavant CQRS). Fowler a écrit un post sur son bliki décrivant l'approche

Oui. Sur mon projet actuel, nous obtenons des données et les stockons dans SQL Server, puis nous créons des indices de recherche à l'aide de Lucene / Solr et les stockons dans MongoDB. Le remplissage de MongoDB se fait avec un chargeur personnalisé, cependant - pas de réplication SQL Server ni d'actualisation automatique.