Desde su concepción en 2010, como base de datos concebida para la nube, hemos diseñado Azure Cosmos DB con mucho cuidado para explotar las tres propiedades fundamentales de la nube:
- Distribución global en virtud de una replicación multimaestro transparente.
- Escalabilidad elástica de rendimiento y almacenamiento en todo el mundo en virtud de particiones horizontales.
- Multiempresa pormenorizada en virtud de una pila del sistema regida en gran medida por recursos desde el motor de base de datos al protocolo de replicación.
Cosmos DB crea estas tres propiedades de forma novedosa para ofrecer una escalabilidad elástica tanto de escrituras como de lecturas en todo el mundo con una latencia en milisegundos de un solo dígito garantizada en el percentil 99 y una alta disponibilidad del 99,999 %. El servicio replica sus datos de forma transparente y proporciona una sola imagen del sistema de su base de datos de Cosmos distribuida globalmente con una opción de cinco modelos de coherencia bien definidos (especificados con precisión mediante TLA+), mientras sus usuarios escriben y leen en réplicas locales en cualquier lugar del mundo. Desde su lanzamiento el año pasado, el crecimiento del servicio ha validado nuestras opciones de diseño y las contrapartidas de ingeniería únicas que hemos creado.
Escrituras globalmente escalables y endiabladamente rápidas
Como uno de los servicios fundamentales de Azure, Cosmos DB se ejecuta en todas las regiones de Azure de forma predeterminada. En el momento de escribir, Cosmos DB funciona en más de 50 regiones geográficas; decenas de miles de clientes han configurado sus bases de datos de Cosmos para que se repliquen globalmente en cualquier lugar en un número de regiones que abarca entre dos y más de 50.
Mientras nuestros clientes han usado sus bases de datos de Cosmos para abarcar varias regiones, hasta ahora, podrían designar solo una de las regiones para las escrituras (y lecturas) con el resto de las regiones para las lecturas. Tras probar el servicio ejecutando cargas de trabajo internas de Microsoft durante algunos años, hoy nos complace anunciar que podrá configurar sus bases de datos de Cosmos para que tengan varias regiones de escritura (lo que también se conoce como configuración "multimaestro"). Esta funcionalidad, a su vez, le ofrecerá las siguientes ventajas:
- Disponibilidad de escritura y lectura del 99,999 % en todo el mundo: ahora, además de una disponibilidad de lectura del 99,999 %, Cosmos ofrece una disponibilidad de escritura del 99,999 % que cuenta con el respaldo de Acuerdos de Nivel de Servicio financieros.
- Escalabilidad de escritura y lectura elástica: además de las lecturas, ahora puede escalar las escrituras con total flexibilidad en todo el mundo. Se garantiza que el rendimiento que configura su aplicación en un contenedor de Cosmos DB (o una base de datos) se ofrecerá en todas las regiones, contando con el respaldo de Acuerdos de Nivel de Servicio financieros.
- Latencias de escritura y lectura en milisegundos de un solo dígito en el percentil 99 en todo el mundo: ahora, además de las latencias de lectura en milisegundos de un solo dígito garantizadas, Cosmos DB ofrece una latencia de escritura inferior a 10 ms en el percentil 99, en cualquier parte del mundo y contando con el respaldo de Acuerdos de Nivel de Servicio financieros.
- Varios modelos de coherencia bien definidos: el protocolo de replicación de Cosmos DB se ha diseñado para ofrecer cinco modelos de coherencia bien definidos, prácticos e intuitivos a fin de compilar aplicaciones distribuidas globalmente correctas con facilidad. También hemos creado las especificaciones de TLA+ de alto nivel para los modelos de coherencia disponibles.
- Escalabilidad de punto de conexión ilimitada: el protocolo de replicación de Cosmos DB se ha diseñado para escalarse en centenas de centros de datos y miles de millones de dispositivos perimetrales, de manera uniforme. La arquitectura trata una región de Azure o un dispositivo perimetral como iguales: ambos pueden hospedar réplicas de Cosmos DB y participar como auténticos homólogos en el protocolo de replicación multimaestro.
- MongoDB, Cassandra, SQL, Gremlin y tablas multimaestro: como base de datos de varios modelos y varias API, Cosmos DB ofrece soporte técnico compatible de protocolo de transferencia nativo para las API de SQL (Cosmos DB), Cassandra (CQL), MongoDB, Table Storage y Gremlin. Con Cosmos DB, puede tener un servicio de base de datos sin servidor, rentable, seguro, totalmente administrado y compatible para sus aplicaciones MongoDB y Cassandra, que de nuevo cuentan con el respaldo de Acuerdos de Nivel de Servicio completos y líderes del sector. Ahora, las funcionalidades indicadas anteriormente están disponibles para todos los apoyos de Cosmos DB de las API, incluidos Cassandra, MongoDB, Gremlin, Table Storage y SQL. Por ejemplo, ahora puede tener una base de datos de gráfico accesible de Apache Gremlin o MongoDB multimaestro distribuida globalmente, con tecnología de Cosmos DB.
Décadas de investigación + ingeniería rigurosa = Cosmos DB
El año pasado, en el lanzamiento de Cosmos DB, escribimos información técnica de Cosmos DB acompañada de una entrevista en vídeo con el ganador del premio Turing, el Dr. Leslie Lamport, en la que se describen los fundamentos técnicos de Cosmos DB. Siguiendo con esta tradición, esta es la nueva entrevista en vídeo de Leslie en la que se describe la evolución de la arquitectura de Cosmos DB, la aplicación de TLA+ en el diseño de su protocolo de replicación novedoso y cómo Cosmos DB ha unido décadas de investigación de sistemas distribuidos que abarca desde Paxos a protocolos epidémicos con su ingeniería de primer orden para permitirle compilar auténticas aplicaciones de escalado de Cosmos.
Esta entrada de blog profundiza un poco más en la arquitectura de distribución global de Cosmos DB, incluida la nueva funcionalidad de habilitación de varias regiones de escritura para su base de datos de Cosmos. En las siguientes secciones, hablamos sobre el modelo del sistema para la distribución global de Cosmos DB con su diseño basado en la antientropía para escalar escrituras en todo el mundo.
Modelo del sistema para la distribución global
El servicio de Cosmos DB es un servicio fundamental de Azure, de modo que se implementa en todas las regiones de Azure del mundo, incluidas las nubes públicas, soberanas, DoD y gubernamentales. En un centro de datos, implementamos y administramos el servicio de Cosmos DB en "timbres" masivos de máquinas, cada una de ellas con almacenamiento local dedicado. En un centro de datos, Cosmos DB se implementa en muchos clústeres, cada uno de los cuales ejecuta de forma potencial varias generaciones de hardware. Las máquinas de un clúster suelen repartirse entre una cantidad de dominios de error comprendida entre 10 y 20.
Figura 1: topología del sistema
La distribución global en Cosmos DB es inmediata: en cualquier momento y con solo hacer clic en un botón unas pocas veces (o mediante programación con una sola llamada API), los clientes pueden agregar (o quitar) las regiones geográficas que se van a asociar a su base de datos de Cosmos. Una base de datos de Cosmos, a su vez, consta de un conjunto de contenedores de Cosmos. En Cosmos DB, los contenedores sirven de unidades lógicas de distribución y escalabilidad. Las colecciones, tablas y gráficos que crea se representan (de forma interna) como contenedores de Cosmos. Los contenedores son totalmente independientes del esquema y proporcionan un ámbito para una consulta. Todos los datos de un contenedor de Cosmos se indexan tras la ingesta de datos. Esto permite a los usuarios consultar los datos sin tener que hacer frente al esquema o a complicaciones relativas a la administración de índices, especialmente en una configuración distribuida globalmente.
Como se observa en la Figura 2, los datos de un contenedor se distribuyen a lo largo de dos dimensiones:
- En una región especificada, los datos de un contenedor se distribuyen mediante un valor partition-key proporcionado y administrado de forma transparente por las particiones de recursos subyacentes (distribución local).
- Cada partición de recursos también se replica en regiones geográficas (distribución global).
Cuando una aplicación que usa Cosmos DB con total flexibilidad escala el rendimiento (o consume más almacenamiento) en un contenedor de Cosmos, Cosmos DB realiza operaciones de administración de particiones (p. ej., dividir, clonar, eliminar, etc.) de manera transparente en todas las regiones. Independientemente de la escala, la distribución o los errores, Cosmos DB continúa proporcionando una sola imagen de sistema de los datos incluidos en los contenedores, que se distribuyen globalmente en el número de regiones que sea.
Figura 2: distribución de particiones de recursos en dos dimensiones, que abarcan varias regiones de todo el mundo.
Físicamente, una partición de recursos se implementa por medio de un grupo de réplicas, llamado replica-set. Cada máquina hospeda cientos de réplicas que corresponden a diversas particiones de recursos incluidas en un conjunto fijo de procesos (ver Figura 1). Las réplicas que corresponden a las particiones de recursos se colocan y su carga se equilibra de forma dinámica en las máquinas de un clúster y los centros de datos de una región.
Una réplica pertenece únicamente a un inquilino de Cosmos DB. Cada réplica hospeda una instancia del motor de base de datos, que administra los recursos, así como los índices asociados. El motor de base de datos de Cosmos DB funciona en un tipo system1 basado en la secuencia de registro de átomos (ARS). El motor es completamente independiente del concepto de un esquema y difumina el límite entre la estructura y los valores de instancia de los registros. Cosmos DB logra la independencia total del esquema indexando todo automáticamente tras la ingesta de datos de forma eficaz, lo que permite a los usuarios consultar sus datos distribuidos globalmente sin tener que hacer frente al esquema o a la administración de índices. El motor de base de datos de Cosmos DB, a su vez, consta de componentes como la implementación de varios primitivos de coordinación, tiempos de ejecución del idioma, el procesador de consultas, el almacenamiento y los subsistemas de indexación responsables del almacenamiento transaccional y la indexación de datos, respectivamente. Para proporcionar durabilidad y alta disponibilidad, el motor de base de datos continúa con sus datos e índice en SSD y los replica entre las instancias de motor de base de datos de los conjuntos de réplicas, respectivamente. Los inquilinos más grandes corresponden a una mayor escala de rendimiento y almacenamiento, y tienen réplicas más grandes o una mayor cantidad de las mismas, o bien ambas cosas (y viceversa). Todos los componentes del sistema son completamente asincrónicos: no se bloquea ningún subproceso y el trabajo que realiza cada uno es de corta duración, sin incurrir en ningún cambio de subproceso innecesario. La limitación de frecuencia y la contrapresión se asocian en toda la pila desde el control de admisión a todas las rutas de acceso de E/S. Nuestro motor de base de datos se ha diseñado para explotar la simultaneidad pormenorizada y ofrecer un alto rendimiento mientras funciona en frugales cantidades de recursos del sistema.
La distribución global de Cosmos DB se basa en dos abstracciones clave: conjuntos de réplicas y conjuntos de particiones. Un conjunto de réplicas es un bloque Lego modular para la coordinación, mientras que un conjunto de particiones es una superposición dinámica de una o varias particiones de recursos distribuidas geográficamente. Para entender el funcionamiento de la distribución global, necesitamos comprender estas dos abstracciones clave.
Conjuntos de réplicas: bloques Lego de coordinación
Una partición de recursos se materializa como un grupo de réplicas autoadministradas cuya carga se equilibra de forma dinámica que se reparten entre varios dominios de error, llamados conjunto de réplicas. Este conjunto implementa de forma colectiva el protocolo de máquina de estado replicado para que los datos de la partición de recursos tengan una alta disponibilidad y sean duraderos y fuertemente coherentes. La pertenencia a conjuntos de réplicas N es dinámica: sigue fluctuando entre NMin y NMax en función de los errores, las operaciones administrativas y el tiempo de regeneración o recuperación de las réplicas con errores. Basándose en los cambios de pertenencia, el protocolo de replicación también vuelve a configurar el tamaño de los cuórums de lectura y escritura. Para distribuir de forma uniforme el rendimiento que se asigna a una partición de recursos especificada, empleamos dos ideas: primero, el costo de procesamiento de las solicitudes de escritura en el líder es mayor que el de aplicación de las actualizaciones en el seguidor. Correspondientemente, al líder se le presupuestan más recursos del sistema que a los seguidores. En segundo lugar, en la medida de lo posible, el cuórum de lectura para un nivel de coherencia especificado se compone exclusivamente de las réplicas de los seguidores. Evitamos ponernos en contacto con el líder para el servicio de lecturas a menos que sea absolutamente necesario. Empleamos un número de ideas de la investigación de la relación de carga y capacidad en los sistemas basados en el cuórum para los cinco modelos de coherencia que admite Cosmos DB.
Conjuntos de particiones: superposiciones dinámicas distribuidas geográficamente
Un grupo de particiones de recursos, uno de cada uno de los configurados con las regiones de base de datos de Cosmos, se compone para administrar el mismo conjunto de claves replicadas en todas las regiones configuradas. Este primitivo de mayor coordinación se llama conjunto de particiones: una superposición dinámica distribuida geográficamente de particiones de recursos que administran un conjunto especificado de claves. Mientras que una partición de recursos especificada (es decir, un conjunto de réplicas) está limitada en un clúster, un conjunto de particiones puede abarcar clústeres, centros de datos y regiones geográficas (Figura 2 y Figura 3).
Figura 3: el conjunto de particiones es una superposición dinámica de particiones de recursos
Puede ver un conjunto de particiones como un "superconjunto de réplicas" geográficamente dispersas, que consta de varios conjuntos de réplicas que poseen el mismo conjunto de claves. Similar a un conjunto de réplicas, la pertenencia de un conjunto de particiones también es dinámica: fluctúa basándose en operaciones de administración de particiones de recursos implícitas para agregar o quitar nuevas particiones a o de un conjunto de particiones especificado (p. ej., al escalar horizontalmente el rendimiento en un contenedor, agregue o quite una región a o de su base de datos de Cosmos, al producirse errores, etc.). En virtud de haber hecho que cada una de las particiones (de un conjunto de particiones) administre la pertenencia a conjuntos de particiones en su propio conjunto de réplicas, la pertenencia está completamente descentralizada y tiene una alta disponibilidad. Durante la reconfiguración de un conjunto de particiones, se establece también la topología de la superposición entre las particiones de recursos. La topología se selecciona de forma dinámica en función del nivel de coherencia, la distancia geográfica y el ancho de banda de red disponible entre las particiones de recursos de origen y las de destino.
El servicio le permite configurar sus bases de datos de Cosmos con una sola región de escritura o varias de ellas y, según la opción, los conjuntos de particiones están configurados para aceptar las escrituras exactamente en una o en todas las regiones. El sistema emplea un protocolo de consensos anidado de dos niveles: un nivel funciona en las réplicas de un conjunto de réplicas de una partición de recursos que acepta las escrituras, mientras que el otro funciona en el nivel de un conjunto de particiones para ofrecer garantías de ordenación completas para todas las escrituras confirmadas en el conjunto de particiones. Este consenso anidado multicapa es fundamental para la implementación de nuestros rigurosos Acuerdos de Nivel de Servicio para la alta disponibilidad, así como la implementación de los modelos de coherencia, que ofrece Cosmos DB a sus clientes.
Antientropía con resolución flexible de conflictos
Nuestro diseño para la propagación de actualizaciones, la resolución de conflictos y el seguimiento de causalidades está inspirado en el anterior trabajo sobre algoritmos epidémicos y el sistema Bayou. Mientras que los kernels de las ideas han sobrevivido y proporcionan un cómodo marco de referencia para comunicar el diseño del sistema de Cosmos DB, también han experimentado una transformación significativa al aplicarlos al sistema de Cosmos DB. Esto era necesario, ya que los sistemas anteriores no estaban diseñados ni con la gobernanza de recursos ni con la escala en la que Cosmos DB necesita funcionar ni tampoco para proporcionar las funcionalidades (p. ej., coherencia de obsolescencia limitada) y los Acuerdos de Nivel de Servicio rigurosos y completos que Cosmos DB ofrece a sus clientes.
Recuerde que un conjunto de particiones se distribuye entre varias regiones y sigue el protocolo de replicación (multimaestro) de Cosmos DB para replicar los datos entre las particiones de recursos que componen un conjunto de particiones especificado. Cada partición de recursos (de un conjunto de particiones) acepta las escrituras y suele ofrecer lecturas a los clientes que son locales de esa región. Las escrituras aceptadas por una partición de recursos de una región se confirman de forma duradera y tienen una alta disponibilidad en la partición de recursos antes de confirmarse al cliente. Estas son escrituras provisionales y se propagan a otras particiones de recursos en el conjunto de particiones mediante un canal de antientropía. Los clientes pueden solicitar escrituras provisionales o confirmadas pasando un encabezado de la solicitud. La propagación de antientropía (incluida la frecuencia de propagación) es dinámica, según la topología del conjunto de particiones, la proximidad regional de las particiones de recursos y el nivel de coherencia configurado. En un conjunto de particiones, Cosmos DB sigue un esquema de confirmación principal con una partición de árbitro seleccionada dinámicamente. La selección de árbitro es una parte integral de la reconfiguración del conjunto de particiones basado en la topología de la superposición. Se garantiza que las escrituras confirmadas (incluidas las actualizaciones de varias filas o por lotes) están totalmente ordenadas.
Empleamos relojes vectoriales codificados (que contienen relojes lógicos y de id. de región que corresponden a cada nivel de consenso en el conjunto de réplicas y el conjunto de particiones, respectivamente) para que el seguimiento de causalidades y los vectores de versión detecten y resuelvan conflictos relativos a las actualizaciones. La topología y el algoritmo de selección de homólogos se han diseñado para garantizar un almacenamiento fijo y mínimo y una sobrecarga de red mínima de los vectores de versión. El algoritmo garantiza la propiedad de convergencia estricta.
En las bases de datos de Cosmos configuradas con varias regiones de escritura, el sistema ofrece un número de directivas de resolución de conflictos automáticas flexibles para que los desarrolladores elijan entre ellas, incluidas:
- Últimos casos de escritura correcta (LWW) que, de forma predeterminada, usa una propiedad de marca de tiempo definida por el sistema (que se basa en el protocolo de reloj de sincronización de hora). Cosmos DB también le permite especificar cualquier otra propiedad numérica personalizada que se vaya a usar para la resolución de conflictos.
- Directiva de resolución de conflictos personalizada (expresada a través de procedimientos de combinación) que se ha diseñado para la reconciliación de conflictos de semántica definida por la aplicación. Estos procedimientos almacenados se invocan tras la detección de los conflictos de escritura-escritura bajo los auspicios de una transacción de base de datos en el servidor. El sistema garantiza exactamente una vez la ejecución de un procedimiento de combinación como parte del protocolo de confirmación. Hay varios ejemplos disponibles con los que puede jugar.
- Tipos CRDT (datos replicados libres de conflictos) de forma nativa dentro del sistema de tipo básico (ARS) de nuestro motor de base de datos. Esto, a su vez, permite la resolución automática de conflictos, transaccional y directamente dentro del motor de base de datos como parte del protocolo de confirmación.
Cinco modelos de coherencia definidos con precisión
Independientemente de si configura su base de datos de Cosmos con una o con varias regiones de escritura, puede usar cinco modelos de coherencia bien definidos que ofrece el servicio. Con la recién agregada compatibilidad para permitir varias regiones de escritura, a continuación se indican algunos aspectos notables de los niveles de coherencia:
Como antes, la coherencia de obsolescencia limitada garantiza que todas las lecturas van a estar dentro de prefijos k o segundos t desde la última escritura en cualquiera de las regiones. Además, se garantiza que las lecturas con coherencia de obsolescencia limitada son monotónicas y con garantías de prefijo coherente. El protocolo de antientropía funciona con limitación de frecuencia y garantiza que los prefijos no se acumulen y que la resistencia en los escritos no tenga que aplicarse. Como antes, la coherencia de sesión garantiza las garantías de lectura monotónica, escritura monotónica, RYOW, escritura tras lectura y prefijo coherente en todo el mundo. En las bases de datos configuradas con coherencia máxima, el sistema vuelve a cambiar a una sola región de escritura designando a un líder en cada uno de los conjuntos de particiones.
La semántica de los cinco modelos de coherencia se describe aquí, y lo hace de forma matemática mediante especificaciones de TLA+ de alto nivel.
Conclusión
Igual que una base de datos distribuida globalmente, Cosmos DB replica sus datos de forma transparente en cualquier número de regiones de Azure. Con su arquitectura de replicación novedosa, completamente descentralizada y multimaestro, puede escalar de forma elástica tanto las escrituras como las lecturas en todas las regiones asociadas a su base de datos de Cosmos. La capacidad de escalar de forma elástica las escrituras globalmente escribiendo a las réplicas locales de su base de datos de Cosmos en cualquier parte del mundo ha estado en marcha durante los últimos años. Nos emociona que esta característica se encuentre ahora disponible de forma general para todo el mundo.
Confirmaciones
Azure Cosmos DB se inició como "Proyecto Florence" a finales de 2010 antes de expandirse y despertar a su forma actual. Damos las gracias a todos los equipos de Microsoft que han consolidado Azure Cosmos DB, por su amplio uso del servicio con los años. Nos apoyamos en los hombros de los grandes: hay muchas tecnologías de componentes en las que se basa Azure Cosmos DB, incluidas Compute, redes y Service Fabric. Les damos las gracias por su apoyo constante. Gracias al Dr. Leslie Lamport por inspirarnos e influir en nuestro enfoque de diseño de sistemas distribuidos. Estamos muy agradecidos a nuestros clientes que han confiado en Cosmos DB para crear sus aplicaciones críticas, que han puesto a prueba los límites del servicio y que siempre exigen lo mejor. Por último, pero no menos importante, damos las gracias a todos los increíbles Cosmonautas por sus profundos compromiso y atención.
- Gramáticas como JSON, BSON y CQL son un estricto subconjunto del sistema de tipo ARS.