En SQL Server, escalar las lecturas (es decir, utilizar réplicas secundarias activas a través de Grupos de Disponibilidad AlwaysOn) es mucho más fácil que escalar las escrituras. Entonces, ¿cuáles son tus opciones cuando tienes una gran cantidad de escrituras que no se pueden manejar al escalar hacia arriba, sin importar cuán grande sea tu servidor?

Existen varias opciones que te permiten escribir en muchos servidores (en lugar de escribir en un servidor maestro) que llamaré escrituras distribuidas. Aquí tienes algunas ideas:

• Replicación transaccional de igual a igual (o replicación de varios maestros) con SQL Server.
• Fragmentación en Azure SQL Database a través de herramientas de base de datos elástica que requieren programación.
• Replicación de combinación en SQL Server.
• Crea una aplicación de mensajería y encolamiento en SQL Server Service Broker donde todas las escrituras se colocan en la cola y se envían a diferentes servidores.
• Crea una cola de mensajes utilizando un Azure Event Hub asíncrono.
• Utiliza un producto de terceros: Attunity Replicate para SQL Server, ScaleArc para SQL Server.
• En lugar de usar SQL Server, utiliza un servicio de base de datos NoSQL o de múltiples modelos como Azure Cosmos DB (no se requiere programación, piénsalo como un auto-fragmentado).

La única opción de todas las opciones anteriores que no requiere programación y puede admitir una gran cantidad de escrituras por segundo es Azure Cosmos DB. Todas las demás opciones pueden requerir una programación significativa y/o solo pueden manejar una cantidad limitada de escrituras por segundo.

Esto se debe a que Cosmos DB utiliza documentos (archivos JSON) donde toda la información necesaria está incluida en ese documento, por lo que no se necesitan uniones y los documentos se pueden distribuir en varios servidores. Esto se opone a las bases de datos relacionales que utilizan múltiples tablas que deben unirse. Si las tablas están en nodos diferentes, esto causará una gran cantidad de reorganización de datos y problemas de rendimiento.

Para entrar en más detalle sobre los beneficios de Cosmos DB sobre SQL Server para escrituras distribuidas:

• Consistencia: la replicación de igual a igual de SQL introduce problemas de consistencia de datos y resolución de conflictos.
• Disponibilidad: la fragmentación con SQL introduce problemas para mantener la disponibilidad al aumentar/disminuir el grado de escalado. Con frecuencia, se produce tiempo de inactividad debido a la necesidad de reequilibrar los datos en los fragmentos.
• SQL requiere esquemas rígidos e índices que deben definirse de antemano. Cada vez que se necesiten actualizaciones de esquema e índice, incurrirás en un alto costo operativo al ejecutar scripts de Crear índice y Alterar tablas en todos los fragmentos y réplicas de la base de datos. Además, esto introduce problemas de disponibilidad a medida que se alteran los esquemas.
• Manejo de una ingestión sostenida de escrituras pesadas: poner mecanismos de encolamiento frente a SQL solo te brinda un búfer para manejar picos de escrituras, pero al final del día, la base de datos misma debe admitir una ingestión sostenida de escrituras pesadas para consumir los eventos almacenados en el búfer. ¿Qué sucede si los eventos llegan al búfer más rápido de lo que lo vacías? Necesitarás una base de datos diseñada específicamente para la ingestión de escrituras pesadas.

Azure Cosmos DB resuelve estos problemas mediante:

• Proporcionar 5 modelos de consistencia bien definidos para ayudar a los desarrolladores a ajustar los compromisos adecuados entre consistencia y rendimiento para su escenario.
• Escalar según la demanda y admitir un modelo de datos flexible mientras se mantiene una alta disponibilidad (SLA de disponibilidad del 99.99%). La escalabilidad y la gestión de particiones son responsabilidad del servicio en nombre del usuario.
• Uso de técnicas de registro estructurado para ser una base de datos verdaderamente sin bloqueos y poder soportar una ingestión de escrituras pesadas con persistencia duradera.

Al final, eliminar la gestión de esquemas, índices y uniones es un subproducto necesario de la escalabilidad que Azure Cosmos DB proporciona.

Después de la publicación inicial de este blog, recibí la pregunta “¿Por qué no usar simplemente tablas en memoria de SQL 2016 para sistemas de escritura pesada?” y recibí una excelente respuesta de un gerente de producto de Cosmos DB:

SQL en memoria solo es viable cuando:

• La solicitud y el volumen de datos son lo suficientemente pequeños como para caber en una sola máquina. Aún tienes el problema fundamental de límites estrictos debido al modelo de escalamiento hacia arriba.
• El escenario no necesita durabilidad, confiabilidad o disponibilidad, que son requisitos para más del 99% de los escenarios críticos para el cliente.

Si los datos se mantienen solo en memoria, se produce una pérdida de datos en caso de cualquier falla intermitente que requiera reiniciar la computadora (por ejemplo, bloqueo del sistema operativo, corte de energía, el sistema operativo decide reiniciar para actualizar, etc.). Para que los datos sean duraderos, deben persistirse en disco. Para ofrecer resistencia contra fallas de disco, deberás replicar en varios discos. Para escenarios duraderos, la memoria solo actúa como un búfer para absorber los picos. Para lograr una ingestión sostenida de escrituras, deberás vaciar el búfer tan rápido como lo llenas. Ahora tienes un cuello de botella en la E/S de disco a menos que escalas hacia afuera. Por eso tienen que abordar de inmediato que esto es para “aplicaciones donde no se requiere durabilidad”; la durabilidad es un requisito para más del 99% de los escenarios de datos. La pérdida y la corrupción de datos deben tratarse como un pecado cardinal para cualquier producto de datos.

Este modelo sigue siendo un modelo de escalamiento hacia arriba, en el que existen muchos límites estrictos. ¿Qué sucede con el volumen de datos que no cabe en la memoria (que tiende a ser un tamaño muy pequeño en comparación con el almacenamiento en disco)? Debes escalar hacia afuera. ¿Qué sucede con el volumen de solicitudes para el cual el ancho de banda de memoria es insuficiente? Debes escalar hacia afuera. Por eso, los números de rendimiento en el blog son órdenes de magnitud más pequeños que lo que los clientes hacen todos los días en Cosmos DB, y se ignora silenciosamente el tamaño de almacenamiento.

La memoria es 100 veces más cara que los SSD. Lograr un alto almacenamiento en un sistema de escalamiento hacia afuera no solo proporcionará mejores características de escala y durabilidad, sino que también incurrirá en costos mucho más bajos para cualquier escenario a gran escala.

Para obtener más información, puedes consultar el artículo sobre Fragmentación de bases de datos.