5

Actualmente estoy cruzando la jungla de las tecnologías de escalado de SQL Server como la replicación, el envío de registros, la duplicación ... Tengo la siguientes limitaciones en mi elección:Ayuda para elegir qué solución de escalado de SQL Server 2008 seleccionar (replicación, ...)

  • que quieren la carga de sólo lectura que se extiende al otro lado del primario y el secundario (espejo, abonado) del servidor
    • carga de escritura puede ser enviada directamente al servidor principal
    • La solución debe ser casi libre de mantenimiento. Los cambios en el esquema deberían simplemente replicarse en el servidor secundario (atención: la replicación tiene algunas restricciones serias como parece)
    • Los datos escritos deben estar disponibles muy rápidamente (en menos de 1, pero mejor sería instantáneamente) en el servidor secundario
    • En caso de falla del servidor, puedo tolerar fácilmente hasta una hora de pérdida de datos. Estoy más preocupado con fácil escalabilidad

Estas son algunas opciones para lo que podía elegir: http://msdn.microsoft.com/en-us/library/bb510414.aspx. ¿Alguna experiencia que puedas compartir?

Respuesta

5

Esas son todas soluciones de alta disponibilidad, no escalables. SQL Server no tiene una solución fácil de escalar, ni ninguna otra base de datos (relacional). El uso de réplicas de esclavos maestros escala tanto como lo permite la posibilidad de escalado de escritura maestra. El uso de la duplicación master-master multiplexa las escrituras y viene con problemas de consistencia. Casi todas las implementaciones a gran escala que intentaron soluciones basadas en la replicación tuvieron que abandonarla.

Una alternativa es repensar su aplicación en términos de data-feeds independientes que se comunican por mensajería, del modo MySpace scales out.

Otra alternativa es abandonar algunas limitaciones (escribe coherencia, consistencia de lectura, capacidad de recuperación, esquemas mecanografiadas, integridad referencial) y elija un motor de nosql que puede escalar libremente una vez liberada de estas restricciones (Cassandra, HBase, MongoDB).

El escalado total es un requisito tan fundamental que debe diseñar su aplicación en torno a la solución y cumplir con todas las restricciones (severas) impuestas por la escala. Sin embargo, tenga en cuenta que todos los motores relacionales pueden ampliarse a long y que la cantidad de implementaciones en todo el mundo que requieren una escala superior a la escalabilidad de una base de datos puede contarse con los dedos.

+0

Sí, creo que su último párrafo es aplicable a nosotros porque podríamos comprar un servidor más grande. Sin embargo, estaba preocupado por el costo porque esos servidores grandes cuestan mucho dinero ... La replicación haría que la transición a un sistema más grande (actualmente 1 servidor pequeño) fuera más barato, creo, pero la molestia podría no valer la pena. Nuestro modelo de dominio es extremadamente rico y relacional. Muchas tablas y restricciones. – usr

Cuestiones relacionadas