¿Cómo configurar una nueva base de datos de SQL Server para permitir una posible replicación en el futuro?

Question

Estoy construyendo un sistema que tiene el potencial de requerir soporte para más de 500 usuarios simultáneos, cada uno realizando docenas de consultas (selecciona, inserta Y actualizaciones) cada minuto. En base a estos requisitos y tablas con muchos millones de filas, sospecho que será necesario utilizar la replicación de la base de datos en el futuro para reducir parte de la carga de consultas.

Al no haber utilizado la replicación en el pasado, me pregunto si hay algo que deba tener en cuenta en el diseño del esquema.

Por ejemplo, una vez me dijeron que es necesario usar GUID para claves principales para habilitar la replicación. ¿Es esto cierto?
¿Qué consideraciones especiales o mejores prácticas para el diseño de bases de datos existen para una base de datos que se replicará?

Debido a limitaciones de tiempo en el proyecto, no quiero perder tiempo implementando la replicación cuando no sea necesaria. (Tengo suficientes problemas definitivos para superar en este momento sin preocuparme por tener que resolver los posibles). Sin embargo, no quiero tener que hacer cambios de esquema potencialmente evitables cuando/si se requiere replicación en el futuro.

Cualquier otro consejo sobre este tema, incluidos buenos lugares para aprender sobre la implementación de la replicación, también sería apreciado.

Answer 1

Mientras que cada fila debe tener una columna rowguid, usted es no requiere usar un GUID de su clave primaria. En realidad, ni siquiera está obligado a tener una clave principal (aunque será apedreado hasta la muerte por no poder crear uno). Incluso si define su clave principal como un guid, al no convertirla en la columna rowguid, los Servicios de replicación crearán una columna adicional para usted. Definitivamente puede hacer esto, y no es una mala idea, pero de ninguna manera es necesario ni particularmente ventajoso.

Éstos son algunos consejos:

1. mesa de guardar (o, más bien, fila) el tamaño pequeño; a menos que use la replicación a nivel de columna, estará descargando/cargando todo el contenido de una fila, incluso si solo cambia una columna. Además, las tablas más pequeñas hacen que la resolución de conflictos sea más fácil y menos frecuente.
2. No utilice claves primarias secuenciales o deterministas impulsadas por algoritmos. Esto incluye las columnas de identidad. Sí, Replication Services manejará las columnas de identidad y asignará las asignaciones de claves por sí mismo, pero es un dolor de cabeza que no desea tratar con. Esto solo es un gran argumento para usar un Guid para tu clave principal.
3. No permita que sus aplicaciones realicen actualizaciones innecesarias. Obviamente, esta es una mala idea para empezar, pero este problema se empeora exponencialmente en los escenarios de replicación, tanto desde el uso del ancho de banda como desde la perspectiva de resolución de conflictos.

Answer 2

Es posible que desee utilizar GUID para claves principales: en un sistema replicado, las filas deben ser únicas en toda su topología, y GUID PK es una forma de lograr esto.

He aquí una breve article about use of GUIDs in SQL Server

Answer 3

Diría que su verdadera pregunta no es cómo manejar la replicación, sino cómo manejar la escala, o al menos ampliar para la consulta.Y aunque hay varias respuestas a este acertijo, una respuesta se destacará: no usando la replicación.

El problema con la replicación, especialmente con la duplicación de mezcla, es que las escrituras se multiplican en la replicación. Supongamos que tiene un sistema que maneja una carga de 100 consultas (90 lecturas y 10 escrituras) por segundo. Desea escalar y elige la replicación. Ahora tiene 2 sistemas, cada uno maneja 50 consultas, 45 lecturas y 5 escribe cada. Ahora esas escrituras deben ser replicadas para que la cantidad real de escrituras no sea 5 + 5, sino 5 + 5 (escrituras originales) y luego otras 5 + 5 (la réplica escribe), por lo que tiene 90 lecturas y 20 escrituras. Por lo tanto, aunque se redujo la carga en cada sistema, la proporción de escrituras y lecturas ha aumentado. Esto no solo cambia los patrones de IO, sino que lo más importante es que cambia el patrón de concurencia de la carga. Agregue un tercer sistema y tendrá 90 lecturas y 30 escrituras, y así sucesivamente. Pronto tendrá más escrituras que lecturas y la latencia de actualización de la replicación combinada con los problemas de concurencia y los conflictos de fusión harán descarrilar su proyecto. La esencia de esto es que el 'pronto' es mucho más rápido de lo que esperabas. Es lo suficientemente pronto como para justificar la ampliación de escala, ya que estás hablando de una escala de 6-8 iguales en el mejor de todos modos, y de 6 a 8 veces el aumento de capacidad con la ampliación será más rápido, mucho más simple y posible, incluso más barato Empezar con.

Y tenga en cuenta que todos estos son solo puramente teoréticos números. En la práctica, lo que sucede es que la infraestructura de replicación no es gratuita, sino que agrega su propia carga al sistema. Las escrituras deben rastrearse, los cambios deben leerse, debe existir un distribuidor para almacenar los cambios hasta que se distribuyan a los suscriptores, luego deben escribirse los cambios y mediar en posibles conflictos. Es por eso que he visto muy pocas implementaciones que podrían tener éxito con una estrategia de escalado basada en la replicación.

Una alternativa es escalar solo las lecturas y aquí la réplica funciona como, usualmente usando replicación transaccional, pero también lo hace el envío de registro o el reflejo con una instantánea de base de datos.

La alternativa real es la partición (es decir, fragmentación). Las solicitudes se enrutan en la aplicación a la partición adecuada y aterrizan en el servidor que contiene los datos apropiados. Los cambios en una parte que deben reflejarse en otra partición se envían a través de medios asincrónicos (generalmente basados ​​en mensajes). Los datos solo se pueden unir dentro de una partición. Para una discusión más detallada de lo que estoy hablando, lea how MySpace does it. Huelga decir que tal estrategia tiene un gran impacto en el diseño de la aplicación y no puede ser simplemente pegada después de v1.