Mejorar la escalabilidad
Las aplicaciones de nivel medio con frecuencia utilizan una sola base de datos para almacenar datos, lo que puede provocar limitaciones de escala cuando aumenta la carga respecto a la base de datos. Cuando las aplicaciones realizan más lecturas que escrituras, como en un catálogo basado en Web, es posible distribuir la parte de lectura de la carga de trabajo almacenando en caché los datos de sólo lectura en varias bases de datos y conectando los clientes de forma equilibrada entre las bases de datos para distribuir la carga.
En el siguiente diagrama se ilustra una configuración en la que la aplicación y los servidores Web utilizan datos de tres servidores con almacenamiento en caché.
.gif "Usar replicación para ajustar actividad de lectura")
Si la aplicación también requiere disponibilidad mejorada y/o que las lecturas y actualizaciones de un determinado usuario pasen a un servidor de aplicación específico y, a continuación, a un servidor de almacenamiento en caché específico, vea el ejemplo de Mejorar la disponibilidad y la escalabilidad.
Ejemplo de Adventure Works Cycles
Adventure Works Cycles es una compañía ficticia que se utiliza para mostrar situaciones y conceptos de bases de datos. Para obtener más información, vea Bases de datos de ejemplo AdventureWorks.
Adventure Works Cycles ha actualizado recientemente el sitio Web para incluir las nuevas características siguientes:
Pedidos de productos en línea para clientes
Comprobación del estado de los pedidos en línea
Mejores capacidades de búsqueda de documentación de productos
La posibilidad de realizar pedidos de productos en línea desde el sitio Web ha aumentado enormemente la actividad del único equipo de la compañía dedicado a Microsoft SQL Server. Los administradores de Adventure Works han decidido utilizar este equipo como origen para los datos replicados. Toda la actividad de lectura se ha distribuido a tres equipos adicionales que ejecutan SQL Server, con datos almacenados en caché del equipo de origen. Los equipos con almacenamiento en caché controlan toda la actividad de lectura, incluido el examen y la búsqueda en el catálogo de productos, y la comprobación del estado de los pedidos. Toda la actividad de escritura se dirige a la base de datos de origen.
Requisitos comunes para este escenario
Las aplicaciones que utilizan la replicación para obtener escalabilidad normalmente tienen los siguientes requisitos que una solución de replicación adecuada debe resolver:
El sistema debe mantener la coherencia transaccional.
El sistema debe tener latencia baja: las actualizaciones en el origen deben llegar a la caché rápidamente.
El sistema debe tener un rendimiento alto: debe controlar la replicación de un gran número de transacciones.
El procesamiento de replicación debe producir una sobrecarga mínima en el origen.
Los datos requeridos en la caché deben ser un subconjunto de los datos disponibles en el origen.
Tipo de replicación que se debe utilizar en este escenario
SQL Server utiliza una metáfora del sector editorial para describir los componentes del sistema de replicación. Los componentes incluyen el publicador, los suscriptores, las publicaciones y artículos, y las suscripciones. Para obtener más información sobre los componentes del sistema, vea Información general del modelo de publicación de replicación.
En el diagrama anterior, el origen es el publicador. Algunos o todos los datos del origen se incluyen en la publicación, donde cada tabla de datos es un artículo (los artículos también pueden ser otros objetos de base de datos, por ejemplo procedimientos almacenados). Cada caché es un suscriptor de la publicación y recibe el esquema y los datos como una suscripción.
SQL Server ofrece diferentes tipos de replicación para distintos requisitos de aplicación: replicación de instantáneas, replicación transaccional y replicación de mezcla. La mejor implementación para este escenario es la replicación transaccional, que se adapta perfectamente para controlar los requisitos indicados en la sección anterior. Para obtener más información sobre la replicación transaccional, vea Información general de la replicación transaccional y Cómo funciona la replicación transaccional.
Por diseño, la replicación transaccional satisface los requisitos de entidad de seguridad de este escenario:
Coherencia transaccional
Latencia baja
Rendimiento alto
Sobrecarga mínima
La opción principal que hay que tener en cuenta en este escenario es el filtro. La replicación transaccional permite filtrar columnas y filas, por lo que las tablas en los suscriptores sólo contienen los datos requeridos por la aplicación. Para obtener más información, vea Filtrar datos publicados.
Pasos para implementar este escenario
Para implementar este escenario, primero debe crear una publicación y suscripciones y, a continuación, inicializar cada suscripción. Para obtener más información sobre cada paso, haga clic en los siguientes vínculos:
Cuando la suscripción se haya inicializado y los datos fluyan entre el publicador y los suscriptores, es posible que necesite consultar los siguientes temas para obtener información sobre tareas habituales de administración y supervisión: