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 réplica 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 Ejemplos y bases de datos de ejemplo.
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 réplica para obtener escalabilidad normalmente tienen los siguientes requisitos que una solución de réplica 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 réplica de un gran número de transacciones.
- El procesamiento de réplica 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 réplica que se debe utilizar en este escenario
SQL Server utiliza una metáfora del sector editorial para describir los componentes del sistema de réplica. 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 réplica.
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 réplica para distintos requisitos de aplicación: réplica de instantáneas, réplica transaccional y réplica de mezcla. La mejor implementación para este escenario es la réplica transaccional, que se adapta perfectamente para controlar los requisitos indicados en la sección anterior. Para obtener más información sobre la réplica transaccional, vea Información general de la réplica transaccional y Cómo funciona la réplica transaccional.
Por diseño, la réplica transaccional satisface los requisitos principales 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 réplica 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:
- Configurar la distribución
- Publicar datos y objetos de base de datos
- Suscribirse a publicaciones
- Inicializar una suscripción
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:
- Supervisar la réplica
- Estrategias para hacer copias de seguridad y restaurar la réplica de instantáneas o transaccional
- Solucionar problemas de réplica
- Quitar la réplica
Vea también
Otros recursos
Replicar datos en un entorno de servidor a servidor