Uno de los grandes desafíos para los administradores de SQL Server siempre ha sido escalar las bases de datos para adaptarse a cargas de trabajo de procesamiento de datos más pesadas. Para complicar las cosas, Microsoft ofrece muchas opciones diferentes de escalabilidad de SQL Server, pero no todas son apropiadas para cada situación.
En primer lugar, está la cuestión básica de si se debe ampliar o ampliar una arquitectura de SQL Server. El primero implica mover una base de datos a un servidor más grande con más procesadores, memoria y almacenamiento de datos; este último extiende las aplicaciones de SQL Server a varios servidores, lo que distribuye las cargas de trabajo de procesamiento de datos y ofrece posibles ventajas de disponibilidad y redundancia de datos.
En este caso, nos centraremos en las diversas formas de escalar SQL Server. Antes de decidir qué método de escalabilidad utilizar, los administradores de bases de datos deben considerar factores como la frecuencia de las actualizaciones de datos, si los datos se pueden dividir entre diferentes bases de datos y su capacidad para modificar las aplicaciones que se ejecutan en SQL Server. Con las respuestas en la mano, pueden crear un plan de escalamiento horizontal que satisfaga sus necesidades específicas.
Para ayudar a encontrar estas respuestas, aquí hay detalles básicos sobre algunos de los enfoques de escalamiento horizontal de SQL Server de uso común, condensados de la información técnica publicada por Microsoft.
Bases de datos compartidas escalables. Una base de datos no tiene que estar ubicada físicamente en un servidor de base de datos. En su lugar, colocándolo en una red de área de almacenamiento (SAN), se puede acceder a los datos simultáneamente mediante varias instancias de SQL Server que se ejecutan en diferentes servidores. En esencia, cada instancia conectada a la SAN funciona desde la misma copia de la base de datos.
Este método de escalabilidad se puede utilizar normalmente sin modificaciones en las aplicaciones de SQL Server. Sin embargo, una gran desventaja es que solo es adecuado para cargas de trabajo con datos estáticos. Las bases de datos compartidas escalables funcionan muy bien en aplicaciones de lectura intensiva que implican consultas complejas, por ejemplo, un almacén de datos.
Sin embargo, las bases de datos compartidas escalables no son adecuadas para aplicaciones con una combinación de operaciones de lectura / escritura. Se coloca un candado en una base de datos de SQL Server al escribir datos en ella. Si los datos deben escribirse en una base de datos compartida, todas las instancias de SQL Server menos una se separarán momentáneamente de ella hasta que se complete la operación de escritura. Como resultado, las operaciones de escritura afectan negativamente al rendimiento de la base de datos de una manera muy significativa.
Vistas divididas distribuidas. A diferencia de las bases de datos compartidas escalables, esta técnica para escalar las cargas de trabajo de SQL Server funciona bien para los datos que se actualizan con frecuencia, lo que la convierte en una buena opción para las aplicaciones de procesamiento de transacciones en línea (OLTP). La posible desventaja es que los datos deben poder particionarse. También es probable que las aplicaciones de la base de datos necesiten modificaciones para sincronizar las operaciones de procesamiento en todas las particiones.
El concepto detrás del enfoque de vistas particionadas distribuidas es simple: los datos en una base de datos grande se dividen en varias bases de datos distribuidas más pequeñas. Por ejemplo, una base de datos que contiene facturas puede dividirse por año. Las facturas de 2016 podrían colocarse en una base de datos, mientras que las facturas de 2017 irían a otra. Las actualizaciones y consultas se pueden ejecutar en la base de datos que contiene los datos relevantes.
Enrutamiento dependiente de datos. Se trata esencialmente de una variación de las vistas particionadas distribuidas diseñadas para aplicaciones OLTP de gran volumen. Una base de datos se divide de manera similar en una serie de bases de datos más pequeñas. La diferencia radica en cómo se gestiona el proceso de enrutamiento de consultas a la base de datos correcta. Con vistas particionadas distribuidas, SQL Server mismo es consciente de la estructura de partición de datos y determina dónde acceder a los datos solicitados. En el caso del enrutamiento dependiente de datos, las aplicaciones de SQL Server o los servicios de middleware determinan dónde residen los datos necesarios.
Servidores enlazados. SQL Server puede acceder a bases de datos remotas como si fueran locales. Por eso, es posible configurar el software para tratar una colección de bases de datos escaladas como si fueran una única base de datos grande. Los servidores vinculados ofrecen una alternativa viable cuando las aplicaciones de SQL Server existentes no se pueden cambiar fácilmente para admitir otro enfoque de escalamiento horizontal.
Sin embargo, debido a que SQL Server se conecta a una serie de bases de datos independientes, no puede tener un acoplamiento formal entre ellas. Además de algunas limitaciones dentro de SQL Server, como la falta de integridad referencial entre tablas locales y remotas, existe una sobrecarga de procesamiento significativa involucrada en el acceso a bases de datos remotas. Las arquitecturas de SQL Server que involucran servidores vinculados deben diseñarse de tal manera que se minimice la necesidad de acceder a datos remotos, especialmente a través de uniones entre tablas locales y remotas.
Replicación de igual a igual. Un mecanismo más para escalar las aplicaciones de SQL Server es la replicación de datos entre diferentes servidores. La replicación de igual a igual es esencialmente lo opuesto al método de bases de datos compartidas escalables. En lugar de que varios servidores de bases de datos compartan una única copia de una base de datos, cada uno de los servidores contiene su propia copia. Cuando se produce una operación de escritura, el cambio se replica en todas las copias.
La replicación de igual a igual puede manejar una cantidad moderada de escrituras de base de datos, pero es más adecuada para datos que son relativamente estáticos. Debido a la latencia involucrada en el proceso de replicación, tampoco es una buena opción para usar con datos que son extremadamente urgentes. Sin embargo, es una buena opción de escalabilidad de propósito general para bases de datos que procesan más lecturas que escrituras.
