¿Se pueden usar SQL Server y Mongo juntos?

Tenemos un gran sitio orientado a las noticias que tiene un alto tráfico web. La arquitectura es su base de datos DB - Repo Layer - Layer Services Capa - Asp.Net MVC. El problema que hemos estado viendo está relacionado con el rendimiento de lectura. Resulta que todas estas cosas de objetos de dominio DDD son geniales, en teoría, para las reglas comerciales, pero han hecho la vida más difícil cuando se trata de optimizar el rendimiento de lectura.

Como solución, estoy considerando algo completamente nuevo (para nosotros): usar noSQL. Me gustaría usar una base de datos noSQL para los datos que se presentan en nuestro sitio web. No podemos deshacernos de nuestro SQL Server (al menos no en el corto plazo), pero me parece que un paso práctico sería utilizar Mongo como una base de datos de consulta para todo el nuevo desarrollo.

Mi pregunta es si es posible usar SQL Server como su base de datos de registro y Mongo como su base de datos de consultas juntos .

Entonces, cuando uno de nuestros editores actualiza un registro, los datos se almacenarán en SQL Server. Esto es necesario porque hay demasiado código heredado que no se puede volver a escribir de la noche a la mañana.

Pero cuando un espectador en el sitio web ve un artículo o una lista de artículos, me gustaría aprovechar el rendimiento de Mongo versus SQL Server. Para mantener los datos algo actualizados, digamos 15 minutos o menos, los datos de SQL Server necesitarían actualizar Mongo. RDBMS tiene herramientas de replicación para operaciones como esta y me pregunto si existe algo para hacer lo mismo desde SQL Server a Mongo. ¿Servidor Lync, tal vez?

Te has encontrado con un problema que muchos tienen antes que tú ... una base de datos optimizada para la lectura rara vez es buena para la eficiencia de escritura y viceversa. Un enfoque que ha evolucionado a partir de este impedimento de lectura y escritura es CQRS (segmentación de responsabilidad de consulta de comando). A pesar de que Wikipedia vincula los dos, CQRS y CQS son técnicamente diferentes. CQS solo exige que un método realice un cambio (comando) o solicite información (consulta) nunca ambos.

CQRS va un paso más allá y especifica que tiene un modelo separado para consultas y comandos. Este solo paso permite cosas como separar su base de datos de lectura y escritura. Que es lo que quieres hacer.

No puedo decir que soy un experto en Mongo o que lo configuro para trabajar con SQL Server. Pero, según tengo entendido, la gente usa Mongo como una vista desnormalizada de su base de datos transaccional. La actualización de Mongo desde la base de datos transaccional podría reducirse a ejecutar un Agente SQL. O tener un servicio separado para sondear la base de datos.

Una alternativa aún mejor sería hacer que su servicio de comando active un evento cada vez que se realice una actualización. Entonces tendría un servicio que escuchó ese evento y actualizó el MongoDB con esa información. Ese es el enfoque fundamental para el abastecimiento de eventos (busque el abastecimiento de eventos en la página).

Greg Young, uno de los líderes de opinión en el mundo DDD actualmente está escribiendo un libro en la serie Fowler Signature en CQRS llamado Event-Centric (solía llamarse CQRS). Fowler ha escrito una publicación en su bliki describiendo el enfoque

Si. En mi proyecto actual, estamos obteniendo datos y almacenándolos en SQL Server, y luego generando índices de búsqueda usando Lucene / Solr y almacenando esos en MongoDB. Sin embargo, completar MongoDB se realiza con un cargador personalizado, sin replicación de SQL Server ni actualización automática.