Datos distribuidos en Data WareHouse

Datos distribuidos
 
La distribución de los Datos a través de varios servidores es toda una teoría de la que nosotros solo vamos a mencionar sus más relevantes rasgos, haciendo énfasis en la replicación de SQL Server. Para comenzar debemos decir que existen dos técnicas fundamentales apara usar datos distribuidos.

1. Transacciones Distribuidas
2. Replicación

La primera necesita que todos los servidores involucrados estén funcionando correctamente y en red (online). Este tipo de transacciones mantiene actualizadas todas las bases de datos involucradas en todo momento. Todos los servidores tienen que estar sincronizados y si falla un solo elemento de la transacción falla completa. Teniendo que revertir el proceso en todos los servidores con su correspondiente consumo de procesamiento. La segunda por su parte puede mantener un margen de tiempo que permite a los servidores no tener que estar sincronizados en todo momento. Así como podemos ver el uso de una u otra técnica está dado principalmente por dos factores: Latencia entre servidores y Autonomía de cada servidor. Este último tiene que ver por ejemplo: Si el Data Mart ubicado en Ciego es actualizado a partir de la información recolectada del sistema de inventario de todos los centros comerciales de esta provincia. Entonces este Servidor posee una autonomía. Estos datos no tienen por qué ser replicados al servidor de la Provincia Santiago de Cuba o Matanzas. En este caso esa información solo sería necesaria en El servidor central de la Empresa donde se encuentra el Data Warehouse central. Así mismo estos pueden ser replicados en el horario nocturno evitando que los enlaces de comunicación WAN se congestionen por el día que hay un mayor tráfico de correo, Messenger, sistemas contables y otros. Es decir en nuestro ejemplo la replicación sería la vía más óptima de implementación para poder mantener los datos distribuidos con autonomía a través de todas las sucursales del país.

Estas dos técnicas de trabajo poseen una serie de variantes para su implementación que mostramos en forma de gráfico:

Figura 5: Formas de implementación de datos distribuidos (Microsoft Training, 2000)

 
 Alta Latencia (Hight Latency)
                                                         Merge Replication
                                               SnapShot Replication
                                           SnapShot Replication with immediate or queued updating
                                     Transactional Replication
                              Transactional Replication with immediate or queued updating
                          Distributed Transactions

                                                       
                                                           Alta Autonomía (Hight Autonomy)
       
SQL Server 2000 tiene tres formas básicas para implementar la distribución de datos:

1. Snapshot Replication
2. Transactional Replication
3. Merge Replication

SanapShot Replication: Replica todos los datos en la publicación hacia el o los subscriptores. En el tiempo especificado en el Agente. Este tipo de método es muy usado en ambientes con una gran autonomía y donde se necesitan los datos publicados con una latencia no muy baja.
Transactional Replication: En este tipo de replicación solo se replican los cambios incrementales. Este tipo de replicación es usada en ambientes donde la latencia de actualización debe ser baja, puede ser muy útil además en ambientes conectados por enlaces de poco ancho de banda pues el tamaño de los datos replicados es muy bajo. El agente que permite realizar este trabajo tiene además la opción de replicar los datos inmediatamente.
Merge Replication: En este tipo de replicación se analizan los artículos publicados y se crea uno solo con la información resultante de la comparación de estos en cada servidor. Al final cada servidor se actualiza con el artículo resultante. En este tipo de replicación pueden ocurrir colisiones si se usan las mismas bases de datos con un nivel de autonomía alto. Estas colisiones pueden ser resultas programando reglas en la publicación. 

SQL Server usa una filosofía llamada Publicador-Distribuidor-Subscriptor. Análogamente a la vida real el Publicador crea una a varias publicaciones, que no son más que objetos de una base datos como: Tablas, Vistas, Procedimientos almacenados; o Porciones de estos como una proyección de una tabla determinada o una selección de una o varias tablas relacionadas y a partir de esa publicación es que un subscriptor puede suscribirse para recibir las actualizaciones de esta publicación que le llega a través del distribuidor. Tenga en cuenta que el distribuidor puede estar en el propio servidor que publica o puede estar en otro diferente para eliminar carga al publicador y buscar un balance en el procesamiento. Atendiendo a esta filosofía existen tres tipos básicos de implementación física de los servidores:

1. Publicador Central y Muchos Suscriptores
2. Muchos Publicadores y un solo suscriptor
3. Muchos Publicadores y muchos suscriptores

En nuestro caso particular necesitaríamos publicadores en todas las sucursales del país y un subscriptor central en la Habana, con una replicación transaccional (Tansactional Replication) que se ejecutara en el horario de la noche. Es importante destacar que bases de datos de otros sistemas como Lotus Notes. Implementan este sistema de bases de datos distribuidas con replicación con muy buena calidad, prestaciones y poco uso de ancho de banda en los enlaces WAN lo que las hace muy competitivas en el mundo empresarial.