Creación de particiones y escalado horizontal en Azure Cosmos DB

Azure Cosmos DB usa la creación de particiones para escalar contenedores en una base de datos para satisfacer las necesidades de rendimiento de la aplicación. Los elementos de un contenedor se dividen en distintos subconjuntos, que se llaman particiones lógicas. Las particiones lógicas se forman en función del valor de una clave de partición asociada a cada elemento de un contenedor. Todos los elementos de una partición lógica tienen el mismo valor de clave de partición.

Por ejemplo, un contenedor contiene elementos. Cada elemento tiene un valor único para la propiedad UserID. Si UserID actúa como la partición de clave para los elementos de un contenedor y hay 1000 valores UserID exclusivos, se crearán 1000 particiones lógicas del contenedor.

Cada elemento de un contenedor tiene una clave de partición que determina su partición lógica y un id. de elemento único dentro de esa partición. Al combinar la clave de partición y el id. del elemento se crea el índice del elemento, que los identifica de forma única. Elegir una clave de partición es una decisión importante que afecta al rendimiento de la aplicación.

En este artículo se explica la relación entre las particiones lógicas y físicas, se describen los procedimientos recomendados para crear particiones y se proporciona una vista detallada de cómo funciona el escalado horizontal en Azure Cosmos DB. No es necesario comprender estos detalles internos para seleccionar la clave de partición, pero en este artículo se tratan para aclarar cómo funciona Azure Cosmos DB.

Particiones lógicas

Una partición lógica es un conjunto de elementos que comparten la misma clave de partición. Por ejemplo, en un contenedor con datos sobre nutrición, todos los elementos contienen la propiedad foodGroup. Use foodGroup como clave de partición para el contenedor. Los grupos de elementos que tienen valores específicos para foodGroup, tales como Beef Products, Baked Products y Sausages and Luncheon Meats, forman distintas particiones lógicas.

Una partición lógica también define el ámbito de las transacciones de base de datos. Puede actualizar los elementos dentro de una partición lógica mediante el uso de una transacción con aislamiento de instantánea. Cuando se agregan nuevos elementos al contenedor, el sistema crea nuevas particiones lógicas de forma transparente. No tiene que preocuparse de quitar una partición lógica una vez eliminados los datos subyacentes.

No hay ningún límite en el número de particiones lógicas de un contenedor. Cada partición lógica puede almacenar un máximo de 20 GB de datos. Las claves de partición eficaces tienen una amplia gama de valores posibles. Por ejemplo, en un contenedor donde todos los elementos contienen una propiedad foodGroup, los datos de la partición lógica Beef Products podrían crecer hasta los 20 GB. Seleccionar una clave de partición con una amplia gama de valores posibles garantiza que el contenedor se puede escalar.

Use alertas de Azure Monitor para supervisar si el tamaño de una partición lógica se aproxima a 20 GB.

Particiones físicas

Un contenedor se escala mediante la distribución de datos y el rendimiento entre particiones físicas. Internamente, una o varias particiones lógicas se asignan a una sola partición física. Normalmente, los contenedores más pequeños tienen muchas particiones lógicas, pero solo requieren una sola partición física. A diferencia de las particiones lógicas, las particiones físicas son una implementación interna del sistema y Azure Cosmos DB las administra por completo.

El número de particiones físicas de un contenedor depende de estas características:

• La cantidad de rendimiento aprovisionado (cada partición física individual puede proporcionar un rendimiento de hasta 10 000 unidades de solicitud por segundo). El límite de 10 000 RU/s para las particiones físicas implica que las particiones lógicas también tienen un límite de 10 000 RU/s, ya que cada partición lógica solo se asigna a una partición física.

• El almacenamiento total de datos (cada partición física individual puede almacenar hasta 50 gigabytes de datos).

Nota:

Las particiones físicas son una implementación interna del sistema, totalmente administrada por Azure Cosmos DB. Al desarrollar las soluciones, no se centre en las particiones físicas porque no las puede controlar. En su lugar, céntrese en las claves de partición. Elegir una clave de partición que distribuya uniformemente el consumo de rendimiento entre particiones lógicas garantiza un consumo de rendimiento equilibrado entre particiones físicas.

No hay límite para el número total de particiones físicas en un contenedor. A medida que aumente el tamaño de los datos o el rendimiento aprovisionado, Azure Cosmos DB creará nuevas particiones físicas automáticamente dividiendo las particiones existentes. Las divisiones de las particiones físicas no afectan a la disponibilidad de la aplicación. Cuando una partición física se divide, todos los datos que estén en una partición lógica específica se guardarán en la misma partición física. Las divisiones de las particiones físicas simplemente crean una nueva asignación entre las particiones lógicas y las particiones físicas.

El rendimiento aprovisionado para un contenedor se divide uniformemente entre particiones físicas. Un diseño de clave de partición que no distribuye las solicitudes uniformemente podría dar lugar a demasiadas solicitudes dirigidas a un pequeño subconjunto de particiones que se vuelven "calientes". Las particiones calientes provocan un uso ineficaz del rendimiento aprovisionado, lo que puede dar lugar a una limitación de velocidad y mayores costos.

Por ejemplo, imagine un contenedor con la ruta de acceso /foodGroup especificada como clave de partición. El contenedor podría tener cualquier número de particiones físicas, pero en este ejemplo se supone que tiene tres. Una sola partición física podría contener varias claves de partición. Por ejemplo, la partición física más grande podría contener las tres particiones lógicas de mayor tamaño: Beef Products, Vegetable and Vegetable Products y Soups, Sauces, and Gravies.

Si asigna un rendimiento de 18 000 unidades de solicitud por segundo (RU/s), cada una de las tres particiones físicas usa un tercio del rendimiento aprovisionado total. Dentro de la partición física seleccionada, las claves de partición lógicas Beef Products, Vegetable and Vegetable Products y Soups, Sauces, and Gravies podrán, en conjunto, utilizar 6 000 RU/s aprovisionadas de la partición física. Como el rendimiento aprovisionado se reparte uniformemente entre las particiones físicas del contenedor, es importante elegir una clave de partición que distribuya el consumo uniformemente. Para obtener más información, consulte Elección de la clave de partición lógica correcta.

Administración de particiones lógicas

Azure Cosmos DB administra automáticamente la ubicación de las particiones lógicas en particiones físicas para satisfacer las necesidades de escalabilidad y rendimiento del contenedor. Cuando aumentan los requisitos de rendimiento y almacenamiento de una aplicación, Azure Cosmos DB mueve las particiones lógicas para distribuir la carga entre más particiones físicas. Obtenga más información sobre las particiones físicas.

Azure Cosmos DB usa particiones basadas en hash para distribuir particiones lógicas entre particiones físicas. Azure Cosmos DB aplica un algoritmo hash al valor de clave de partición de un elemento. El resultado con hash determina la partición lógica. A continuación, Azure Cosmos DB asigna el espacio de claves de los hash de claves de partición uniformemente entre las particiones físicas.

Las transacciones en procedimientos almacenados o desencadenadores solo se permiten para los elementos de una sola partición lógica.

Conjuntos de réplicas

Cada partición física consta de un conjunto de réplicas, también denominado conjunto de réplicas. Cada réplica hospeda una instancia del motor de base de datos. Los conjuntos de réplicas hacen que el almacén de datos de la partición física sea duraderos, coherente y tenga una alta disponibilidad. Cada réplica de la partición física hereda la cuota de almacenamiento de la partición. Todas las réplicas de una partición física admiten colectivamente el rendimiento asignado a esa partición física. Azure Cosmos DB administra automáticamente los conjuntos de réplicas.

Normalmente, los contenedores más pequeños requieren una sola partición física, pero todavía tienen al menos cuatro réplicas.

En esta imagen se muestra cómo las particiones lógicas se asignan a particiones físicas distribuidas globalmente. El conjunto de particiones de la imagen hace referencia a un grupo de particiones físicas que administran las mismas claves de partición lógica en varias regiones:

Elegir una clave de partición

Una clave de partición tiene dos componentes: ruta de acceso de la clave de partición y valor de la clave de partición. Por ejemplo, considere un elemento { "userId" : "Andrew", "worksFor": "Microsoft" } si elige "userId" como la clave de partición. Estos son los dos componentes de la clave de partición:

• La ruta de acceso de la clave de partición (por ejemplo: "/userId"). La ruta de acceso de la clave de partición acepta caracteres alfanuméricos y guiones bajos (_). También puede usar objetos anidados mediante la notación de ruta de acceso estándar (/).

• El valor de clave de partición (por ejemplo, "Andrew"). El valor de la clave de partición puede ser de tipo cadena o numérico.

Obtenga información sobre los límites de rendimiento, almacenamiento y longitud de clave de partición en el artículo Cuotas de servicio de Azure Cosmos DB.

La selección de la clave de partición es una decisión de diseño sencilla pero importante en Azure Cosmos DB. Una vez que seleccione la clave de partición, no podrá cambiarla en su lugar. Si necesita cambiar la clave de partición, mueva los datos a un nuevo contenedor con la clave de partición deseada. Los Trabajos de copia de contenedor ayudan en este proceso. Como alternativa, puede agregar índices secundarios globales (versión preliminar) para crear copias de los datos con diferentes claves de partición optimizadas para patrones de consulta específicos.

Para todos los contenedores, la clave de partición debe:

• Ser una propiedad con un valor invariable. Si una propiedad es la clave de partición, no se puede actualizar su valor.

• Solo contienen valores String, o convierten números en una String si pueden superar los límites de números de precisión doble según el Institute of Electrical and Electronics Engineers (IEEE) 754 binary64. La especificación JSON explica por qué usar números fuera de este límite es un procedimiento incorrecto debido a problemas de interoperabilidad. Estos problemas son especialmente relevantes para la columna de clave de partición porque es inmutable y requiere la migración de datos para cambiar más adelante.

• Tener una cardinalidad alta. En otras palabras, la propiedad debe tener una amplia gama de valores posibles.

• Distribuir el consumo de unidades de solicitud (RU) y el almacenamiento de datos uniformemente en todas las particiones lógicas. Esto garantiza una distribución uniforme del consumo de RU y el almacenamiento en las particiones físicas.

• Tener valores que, por lo general, no superan los 2048 bytes (o 101 bytes si no están habilitadas las claves de partición grandes). Para más información, consulte Claves de partición de gran tamaño.

Si necesita transacciones ACID de varios elementos en Azure Cosmos DB, deberá usar procedimientos almacenados o desencadenadores. Todos los procedimientos almacenados y desencadenadores basados en JavaScript están limitados a una única partición lógica.

Nota:

Si solo tiene una partición física, es posible que el valor de la clave de partición no sea relevante porque todas las consultas tienen como destino la misma partición física.

Tipos de claves de partición

Estrategia de creación de particiones	Cuándo se deben usar	Ventajas	Desventajas
Clave de partición normal (por ejemplo, CustomerId, OrderId)	Use cuando la clave de partición tenga una cardinalidad alta y se alinee con los patrones de consulta (por ejemplo, el filtrado por CustomerId). Adecuado para cargas de trabajo en las que las consultas tienen como destino principalmente los datos de un solo cliente (por ejemplo, recuperar todos los pedidos de un cliente).	Fácil de administrar. Consultas eficaces cuando el patrón de acceso coincide con la clave de partición (por ejemplo, consultando todos los pedidos por CustomerId). Impide las consultas entre particiones si los patrones de acceso son coherentes.	Riesgo de particiones calientes si algunos valores (por ejemplo, algunos clientes de tráfico elevado) generan más datos que otros. Puede alcanzar el límite de 20 GB por partición lógica si el volumen de datos de una clave específica crece rápidamente.
Clave de partición sintética (por ejemplo, CustomerId + OrderDate)	Use cuando ningún campo único tenga una cardinalidad alta y coincida con los patrones de consulta. Adecuado para cargas de trabajo con muchas operaciones de escritura en las que los datos deben distribuirse uniformemente entre particiones físicas (por ejemplo, muchos pedidos realizados en la misma fecha).	Ayuda a distribuir datos uniformemente entre particiones, lo que reduce las particiones calientes (por ejemplo, la distribución de pedidos por CustomerId y OrderDate). Distribuye las escrituras entre varias particiones y mejora el rendimiento.	Las consultas que solo filtran por un campo (por ejemplo, solo CustomerId) podrían dar lugar a consultas entre particiones. Las consultas entre particiones pueden provocar un mayor consumo de RU (cargo adicional de 2 a 3 RU/s por cada partición física que exista) y una latencia agregada.
Clave de partición jerárquica (HPK) (por ejemplo, CustomerId/OrderId, StoreId/ProductId)	Use cuando necesite particiones de varios niveles para admitir conjuntos de datos a gran escala. Ideal cuando las consultas filtran en los niveles primero y segundo de la jerarquía.	Ayuda a evitar el límite de 20 GB mediante la creación de varios niveles de creación de particiones. Consulta eficaz en ambos niveles jerárquicos (por ejemplo, filtrar primero por CustomerID y, a continuación, por OrderID). Minimiza las consultas entre particiones para las consultas que tienen como destino el nivel superior (por ejemplo, recuperar todos los datos de un CustomerID específico).	Requiere una planeación cuidadosa para asegurarse de que la clave de primer nivel tiene una cardinalidad alta y se incluye en la mayoría de las consultas. Más complejo de administrar que una clave de partición normal. Si las consultas no se alinean con la jerarquía (por ejemplo, el filtrado solo por OrderID cuando CustomerID es el primer nivel), el rendimiento de las consultas podría verse afectado.
Índice secundario global (GSI): versión preliminar ( por ejemplo, el origen usa CustomerId, GSI usa OrderId)	Use cuando no encuentre una sola clave de partición que funcione para todos los patrones de consulta. Ideal para cargas de trabajo que necesitan consultar varias propiedades independientes de forma eficaz y tener un gran número de particiones físicas.	Elimina las consultas entre particiones al usar la clave de partición GSI. Permite varios patrones de consulta en los mismos datos con sincronización automática desde el contenedor de origen. Aislamiento del rendimiento entre cargas de trabajo.	Cada GSI tiene costos adicionales de almacenamiento y RU. Los datos del GSI son coherentes con el contenedor de origen.

Claves de partición para contenedores con lecturas frecuentes

Para la mayoría de los contenedores, estos criterios son todos los que debe tener en cuenta al elegir una clave de partición. No obstante, en el caso de los contenedores con lecturas frecuentes, es posible que quiera elegir una clave de partición que aparece con frecuencia como filtro en las consultas. La inclusión de la clave de partición en el predicado de filtro permite enrutar las consultas de forma eficaz solo a las particiones físicas pertinentes.

Esta propiedad es una buena opción de clave de partición si la mayoría de las solicitudes de la carga de trabajo son consultas y la mayoría de las consultas usan un filtro de igualdad en la misma propiedad. Por ejemplo, si ejecuta frecuentemente una consulta que filtra por UserID, al seleccionar UserID como clave de partición se reduciría el número de consultas entre particiones.

Si el contenedor es pequeño, es probable que no tenga suficientes particiones físicas para preocuparse por el rendimiento de las consultas entre particiones. La mayoría de los contenedores pequeños en Azure Cosmos DB requieren solo una o dos particiones físicas.

Si el contenedor puede aumentar a unas cuantas particiones físicas, debe asegurarse de elegir una clave de partición que minimice las consultas entre particiones. El contenedor necesita más de algunas particiones físicas si se cumple alguno de los siguientes escenarios:

• El contenedor tiene más de 30 000 unidades de solicitud aprovisionadas

• El contenedor almacena más de 100 GB de datos.

Índices secundarios globales para consultas entre particiones

Si la aplicación necesita consultar datos con varias propiedades diferentes de forma eficaz, los índices secundarios globales (versión preliminar) proporcionan una alternativa al uso de una estrategia de clave de partición para el conjunto de datos. Los índices secundarios globales son contenedores adicionales con diferentes claves de partición, sincronizadas automáticamente con datos del contenedor de origen.

Considere los índices secundarios globales cuando:

• Tiene varios patrones de consulta que no se pueden satisfacer mediante una estrategia de clave de partición única.
• Cambiar la clave de partición existente sería perjudicial
• Debes aislar las cargas analíticas o de búsqueda de las operaciones transaccionales.

Los índices secundarios globales ayudan a evitar consultas entre particiones almacenando los mismos datos con claves de partición diferentes optimizadas para patrones de consulta específicos. Este enfoque puede reducir significativamente el consumo de RU y mejorar el rendimiento de las consultas en escenarios en los que la optimización de claves de partición solo no es suficiente.

Uso del identificador de elemento como clave de partición

Nota:

Esta sección se aplica principalmente a la API para NoSQL. Otras API, como la API de Gremlin, no admiten el identificador único como clave de partición.

Si el contenedor tiene una propiedad con una amplia gama de valores posibles, es probable que sea una excelente opción de clave de partición. Un ejemplo de esta propiedad es el Id. de elemento. En el caso de contenedores pequeños de lectura o escritura frecuente de cualquier tamaño, el Id. de elemento (/id) es naturalmente una excelente opción de clave de partición.

El Id. del elemento de propiedad del sistema está presente en todos los elementos del contenedor. Es posible que tenga otras propiedades que representen un identificador lógico para el elemento. En muchos casos, estos identificadores únicos también son excelentes opciones de clave de partición por las mismas razones que el Id. de elemento.

El id. de elemento es una excelente opción de clave de partición por los siguientes motivos:

• Hay una amplia gama de valores posibles (un id. de elemento único por elemento).
• Dado que cada elemento tiene un id. único, este id. de elemento realiza un trabajo excelente para equilibrar de manera uniforme el consumo de RU y el almacenamiento de datos.
• Puede realizar lecturas puntuales de forma eficiente, ya que siempre conocerá la clave de partición de un elemento si conoce su identificador.

Tenga en cuenta las siguientes advertencias al seleccionar el Id. de elemento como clave de partición:

• Si el Id. de elemento es la clave de partición, se convierte en un identificador único para todo el contenedor. No se pueden crear elementos con identificadores duplicados.
• Si tiene un contenedor con lecturas frecuentes que tiene muchas particiones físicas, las consultas serán más eficaces si disponen de un filtro de igualdad con el identificador del elemento.
• Los procedimientos almacenados o desencadenadores no pueden tener como destino varias particiones lógicas.

Contenido relacionado

• Rendimiento aprovisionado en Azure Cosmos DB
• Distribución global en Azure Cosmos DB
• Entrenamiento: modelar y particionar los datos en Azure Cosmos DB