Buscando asesoramiento sobre cómo integrar datos de más de 100 bases de datos de clientes en una base de datos de informes centralizada


10

Soy un desarrollador de SQL (no DBA o arquitecto) para una pequeña empresa SaaS (~ 50 empleados). Tengo la tarea de descubrir cómo:

  1. Descargar informes operativos de nuestras más de 100 bases de datos OLTP
  2. Permitir que esos informes se ejecuten contra datos de múltiples bases de datos de clientes
  3. Posicionar a nuestra empresa para proporcionar más soluciones basadas en análisis en el futuro

He leído varios artículos sobre diversas tecnologías, como la replicación transaccional (específicamente el modelo de abonado centralizado), el agente de servicios SQL, el envío de registros, el seguimiento de cambios (CT) y la captura de datos modificados (CDC, según tengo entendido). esto es solo para empresas), y no estoy seguro de qué camino es mejor seguir.

Espero que algunos de ustedes con experiencia en integración puedan haber encontrado una configuración similar a la nuestra y poder señalarme un camino exitoso o dirigirme a algunos recursos que serían útiles.

Debido a limitaciones de costos, nuestra solución debe funcionar dentro de SQL Server Standard Edition. Además, la solución debe ser razonable para apoyar / mantener dentro de nuestra pequeña organización.

Configuracion basica:

Actualmente tenemos más de 100 bases de datos de clientes individuales, la mayoría implementadas en servidores SQL en nuestro centro de datos, pero algunas implementadas en servidores de clientes dentro de su centro de datos en las que podemos acceder de forma remota. Estas son todas las bases de datos de SQL Server 2008 R2, pero estamos planeando actualizar a SQL 2016 pronto.

Utilizamos proyectos de bases de datos y dacpacs para garantizar que el esquema sea el mismo en todas las bases de datos de clientes que se integrarían. Sin embargo, dado que no obligamos a todos los clientes a actualizar a nuevas versiones al mismo tiempo, es posible que existan algunas diferencias de esquema entre las actualizaciones. La solución debe ser lo suficientemente flexible como para no romperse si el cliente A está en la versión de software 1.0 y el cliente B está en la versión 1.1.

Los informes operativos se ejecutan actualmente directamente desde la base de datos OLTP de cada cliente. Nos preocupa el impacto que esto tendrá en el rendimiento de la aplicación si no la descargamos.

Requisitos de alto nivel:

Nuestros clientes son departamentos de procesamiento estéril (SPD) de hospitales que desean informes actualizados sobre lo que han procesado hasta ahora, dónde está el inventario, etc. Dado que uno de los principales propósitos de este esfuerzo es respaldar mejor los informes operativos, nos gustaría que los datos estén lo más cerca posible del tiempo real para continuar satisfaciendo las necesidades de los clientes.

Actualmente tenemos algunos SPD en bases de datos separadas que en realidad son parte del mismo sistema hospitalario. Estos clientes desean la capacidad de informar contra todos los SPD en su sistema.

Hablando estratégicamente, nos gustaría la capacidad de agregar fácilmente datos a todos nuestros clientes para respaldar nuestras iniciativas de análisis interno. Nuestra expectativa es que podríamos usar los datos operativos recopilados como fuente para los almacenes / almacenes de datos.

Pensamientos hasta ahora:

Parece que la replicación transaccional proporcionaría la solución más "en tiempo real". Encontré que esta respuesta fue especialmente útil, pero me preocupa que con el potencial de diferencias de esquema no funcione para nosotros: la replicación de SQL Server Many-to-One

El envío de registros no suena ideal dado que el registro no se puede restaurar mientras las consultas están activas. Debo expulsar a todos para que se pueda restaurar el registro o los datos se volverán obsoletos. No tengo claro si este método podría usarse para centralizar datos de múltiples bases de datos, ya que cada registro enviado solo sería para la base de datos individual de la que proviene.

Con el servicio de SQL Service Broker, la latencia puede ser impredecible si una cola no puede mantenerse al día con la cantidad de mensajes a procesar.

CT solo identifica una versión para cada fila de la tabla. La latencia dependerá de la rapidez con que podamos procesar algo como un paquete SSIS en cada base de datos para recuperar los datos e insertarlos en un repositorio central.

¿Necesitamos considerar replicar cada base de datos individualmente y luego tal vez usar algún tipo de técnica de virtualización de datos para combinar datos de las diversas fuentes replicadas?

Cualquier consejo o dirección que esté dispuesto a proporcionar sería muy apreciado.


1
Debido a su requisito (casi) en tiempo real, solo miraría el procesamiento basado en eventos con algunas implementaciones de la cola de mensajes (para garantías de entrega). Espero que esto ayude
Grimaldi

1
Tiraría HTAP a la mezcla. en.m.wikipedia.org/wiki/Hybrid_Transactional/… BIML y SSIS para poblar la tienda común.
Michael Green

@Grimaldi, ¿recomendaría usar el corredor de servicios SQL para implementar el procesamiento basado en eventos / colas de mensajes o alguna otra tecnología de mensajería?
bperry

Gracias por la sugerencia, @MichaelGreen. Básicamente, parece que HTAP nos permitiría usar nuestras bases de datos existentes para OLTP y OLAP al agregar índices de almacén de columnas no agrupados (NCCI) a nuestras tablas. Las consultas de informes utilizan el NCCI para que no interfieran con las operaciones transaccionales. SQL 2016 incluye soporte HTAP en Standard Edition (SE), pero parece que la memoria caché del almacén de columnas está limitada a 32 GB en toda la instancia de SQL. Esto podría ser un problema para nosotros ya que tenemos docenas de bases de datos en la misma instancia. microsoft.com/en-us/sql-server/sql-server-2016-editions
bperry

1
Sí, almacén de columnas pero también en memoria, si las especificaciones de su servidor le permiten ir allí. Escuché a Sunil Agarwal hablar sobre esto recientemente. La regla general de MS fue aproximadamente un 3% de degradación de OLTP en beneficio de los informes de latencia cero. Lamentablemente no hay almuerzos gratis; puede crear nuevas instancias para contener la base de datos de informes o puede crear una nueva instancia para obtener suficiente margen para admitir HTAP. No estoy abogando por este patrón. Puede que no funcione para ti. Solo quería hacerte saber que existía.
Michael Green

Respuestas:


1

¿Necesitamos considerar replicar cada base de datos individualmente y luego tal vez usar algún tipo de técnica de virtualización de datos para combinar datos de las diversas fuentes replicadas?

Si. Puede alojar múltiples bases de datos de suscriptores en una sola instancia y luego consultarlas con vistas o cargarlas en una base de datos consolidada.


¿Hay una manera más elegante de configurar esas vistas además de algo como ... SELECCIONAR Campo1, Campo2, Campo3 DESDE [Base de datos1]. [Esquema]. [Nombre de tabla] UNIR TODOS SELECCIONAR Campo1, Campo2, Campo3 DESDE [Base de datos2]. [Esquema ]. [TableName]
bperry

1

De acuerdo con la descripción anterior, el siguiente enlace lo ayudará a usted y a mí también a trabajar en el mismo escenario. Editor múltiple con suscriptor único.

  1. Agregue una columna más como server_id con un valor predeterminado como 1,2,3 y así sucesivamente y conviértala en clave primaria compuesta.

  2. Al crear las publicaciones y agregar artículos, la propiedad del artículo Acción si el nombre está en uso debe establecerse en Eliminar datos. Si el artículo tiene un filtro de fila, elimine solo los datos que coincidan con el filtro. Esto se puede configurar utilizando el cuadro de diálogo Propiedades del artículo del Asistente de nueva publicación o utilizando los procedimientos almacenados de replicación sp_addarticle y especificando un valor de eliminación para el argumento @pre_creation_cmd. De esta forma, cuando el suscriptor central se inicializa o reinicializa a partir de múltiples instantáneas de publicación, los datos de la instantánea aplicados previamente se conservarán ya que solo se eliminarán los datos que coincidan con la cláusula de filtro.

ingrese la descripción de la imagen aquí

http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/


Gracias por el artículo. Utilizando el modelo de suscriptor central, ¿ha resuelto cómo manejará las actualizaciones del esquema de sus editores (por ejemplo, con actualizaciones de versión)? ¿Forzará que todas las bases de datos del editor se actualicen simultáneamente? En mi entorno, no siempre tenemos esta opción y esa fue mi principal duda al buscar un modelo de replicación de suscriptor central. Si hay una forma de sortear esta barrera, ¡me encantaría saberlo!
bperry

No estoy usando 'Actualizar editor'. Dividí la base de datos en dos partes, como (dos tipos de replicación), algunas de la tabla en el editor detallado (Editor para suscriptor centralizado) y algunas son editor principal (suscriptor centralizado para todo editor) ... .Mi suscriptor centralizado también forma parte del grupo de disponibilidad AlwaysOn, por lo que mi réplica secundaria funciona como servidor de informes.
Gulrez Khan

Déjame asegurarme de que entiendo tu solución. Digamos que el publicador A está en la versión 1 y el publicador B está en la versión 2. 1) Ha desactivado la replicación de los cambios de esquema en ambos publicadores (usando replicate_ddl = 0 en la configuración). 2) La versión 2 incluye una nueva columna, por lo que debería agregarla manualmente en el suscriptor central. 3) En Publisher B (actualizado), debería agregar manualmente la nueva columna a la replicación (usando sp_articlecolumn). No se realizan cambios en el editor A. ¿Permitiría esto que ambos editores continúen replicando en el suscriptor central sin interrumpir la replicación?
bperry



1

Una arquitectura posible:

Considere los informes como una solución basada en el almacén de datos.

Normalmente, un almacén de datos es una base de datos con un esquema que representa el subconjunto requerido de los sistemas de origen. AdventureWorks y AdventureworksDW demuestran ese modelado.

A continuación, el ETL: Mover datos de las fuentes al almacén de datos.

Una posible implementación aquí es usar el seguimiento de cambios.

En primer lugar, se pueden implementar vistas que son específicas de la versión en lo que consumen, pero en términos de lo que devuelven, son uniformes. por ejemplo, si Person.Gender existe en la versión 2 pero no en la versión 1, la vista de persona para la versión uno puede devolver, por ejemplo, nulo para la versión 1.

Para el consumidor del almacén, que solo lee las vistas, los datos tienen la misma forma (con una integridad variable).

El seguimiento de cambios proporciona una forma (relativamente) ligera de determinar qué datos deben cambiarse en cada actualización.

La implementación de lo anterior se basa en herramientas manuales, por lo que deberá confiar en la codificación SQL y probar escenarios de rendimiento para ver qué tan rápido se ejecutan los incrementos. En muchos casos, pueden ser inferiores a 1 segundo, pero algunas tablas de transacciones altas pueden generar una gran carga en los cambios de procesamiento. (El seguimiento de cambios es "relativamente" ligero ... solo las pruebas lo demuestran).

Lo bueno aquí es que tiene un alto grado de control sobre cómo se manifiestan las diferencias de esquema, y ​​con el seguimiento de cambios, no hay posibilidad de problemas de integridad cuando se implementa correctamente, ya que el seguimiento se realiza a nivel del motor.

Si esto es definitivamente adecuado para usted, sería difícil de decir.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.