Elegir una clave de partición

Completado

Recuerde que los datos de los documentos JSON se almacenan en bases de datos de Azure Cosmos DB dentro de contenedores que, a su vez, se distribuyen entre particiones físicas y donde los datos se enrutan a la partición física adecuada en función del valor de una clave de partición.

Diagram that illustrates the physical partitions in Azure Cosmos DB.

La clave de partición es una propiedad de documento necesaria que garantiza que los documentos con el mismo valor de clave de partición se enruten a y almacenen en una partición física específica. Una partición física admite una cantidad máxima fija de almacenamiento y rendimiento (RU/s). Azure Cosmos DB distribuye automáticamente las particiones lógicas entre las particiones físicas disponibles usando de nuevo el valor de clave de partición para hacerlo de forma predecible.

En esta unidad, aprenderá más sobre las particiones lógicas y cómo evitar las particiones frecuentes. Esta información nos ayudará a elegir la clave de partición adecuada para los datos del cliente en nuestro escenario.

En Azure Cosmos DB, se puede aumentar el almacenamiento y el rendimiento agregando más particiones físicas para acceder a los datos y almacenarlos. El tamaño de almacenamiento máximo de una partición física es de 50 GB y el rendimiento máximo es de 10 000 RU/s.

Particiones lógicas en Azure Cosmos DB

La clave de partición garantiza que se considere que los documentos con el mismo valor de clave de partición pertenecen a la misma partición lógica, se enruten a una partición física específica y se almacenen en ella. El concepto de partición lógica permite agrupar documentos con el mismo valor de clave de partición. Se pueden almacenar varias particiones lógicas dentro de una sola partición física y el contenedor puede tener un número ilimitado de particiones lógicas. Las particiones lógicas individuales se mueven a nuevas particiones físicas como una unidad a medida que crece el contenedor. Mover particiones lógicas como una unidad garantiza que todos los documentos que se encuentran en ella residan en la misma partición física. El tamaño máximo de una partición lógica es de 20 GB. El uso de una clave de partición con alta cardinalidad permite evitar este límite de 20 GB al distribuir sus datos en una mayor cantidad de particiones lógicas.

Diagram that shows the relationship between the physical and logical partitions.

Una clave de partición proporciona una manera de enrutar los datos de una partición lógica. Es una propiedad que existe en todos los documentos del contenedor que enruta los datos. Un contenedor es otra abstracción y es para todos los datos almacenados con la misma clave de partición. La clave de partición se define al crear un contenedor.

En el ejemplo siguiente, el contenedor tiene una clave de partición de /username.

Diagram that shows an example where the partition key is username.

Evitar particiones frecuentes

Al modelar datos para Azure Cosmos DB, es fundamental que la clave de partición que elija dé como resultado una distribución uniforme de los datos y de las solicitudes entre las particiones físicas del contenedor. Esto es especialmente cierto cuando los contenedores aumentan de tamaño y tienen un número creciente de particiones físicas.

Si no se prueba el diseño de una base de datos bajo carga durante el desarrollo, es posible que no se ponga de manifiesto una elección deficiente de la clave de partición hasta que la aplicación esté en producción y se hayan escrito datos significativos.

Cuando los datos no están correctamente particionados, se pueden producir particiones frecuentes. Las particiones de acceso frecuente impiden el escalado de la carga de trabajo de la aplicación y pueden producirse tanto en el almacenamiento como en el rendimiento.

Particiones frecuentes de almacenamiento

Una partición frecuente en el almacenamiento se produce cuando tiene una clave de partición que da como resultado patrones de almacenamiento muy asimétricos. Por ejemplo, considere una aplicación multiinquilino que usa TenantId, ya que es la clave de partición con seis inquilinos: del A al F. Los inquilinos B, C, E y F son muy pequeños, mientras que el inquilino D tiene un poco más de datos. Sin embargo, el inquilino C es masivo y alcanza rápidamente el límite de 20 GB para su partición. En este escenario, necesitamos seleccionar una clave de partición diferente que reparta el almacenamiento entre más particiones lógicas.

Diagram that shows a storage distribution skew.

Particiones frecuentes del rendimiento

El rendimiento puede sufrir particiones frecuentes cuando la mayoría de las solicitudes, o todas ellas, van a la misma partición lógica.

Es importante comprender los patrones de acceso de la aplicación para asegurarse de que las solicitudes se reparten lo más uniformemente posible entre los valores de la clave de partición. Cuando el rendimiento se aprovisiona para un contenedor en Azure Cosmos DB, se asigna uniformemente entre todas las particiones físicas de un contenedor.

Por ejemplo, si tiene un contenedor con 30 000 RU/s, esta carga de trabajo se repartiría entre las tres particiones físicas de los mismos seis inquilinos mencionados anteriormente. Por lo tanto, cada partición física obtiene 10 000 RU/s. Si el inquilino D consume todas sus 10 000 RU/s, se limitará la velocidad, ya que no podrá consumir el rendimiento asignado a las otras particiones. Esto da como resultado un rendimiento deficiente para los inquilinos C y D, y deja la capacidad de proceso sin usar en las otras particiones físicas y los inquilinos restantes. En última instancia, esta clave de partición da como resultado un diseño de base de datos donde la carga de trabajo de la aplicación no se puede escalar.

Diagram that shows a throughput hot partition.

Cuando los datos y las solicitudes se reparten uniformemente, la base de datos puede crecer de la manera que mejor aproveche el almacenamiento y el rendimiento en su totalidad. El resultado será el mejor rendimiento posible y la máxima eficacia. En resumen, el diseño de la base de datos se escalará.

Diagram that shows the data and requests spread evenly across partitions.

Consideración de las lecturas frente a las escrituras

Al elegir una clave de partición, también debe tener en cuenta si los datos experimentan numerosas operaciones de lectura y escritura. Las solicitudes con numerosas operaciones de escritura se deben distribuir con una clave de partición que tenga una cardinalidad alta.

Para cargas de trabajo con mucha actividad de lectura, debe asegurarse de que una o un número limitado de particiones físicas procesen las consultas mediante la inclusión de una cláusula WHERE con un filtro de igualdad en la clave de partición o un operador IN en un subconjunto de valores de clave de partición en las consultas.

En escenarios en los que la carga de trabajo de la aplicación está sometida a numerosas operaciones de lectura y escritura, existe una solución. La examinaremos en el módulo siguiente.

En la ilustración siguiente se muestra un contenedor con particiones por nombre de usuario. Esta consulta solo encontrará una sola partición lógica, por lo que su rendimiento siempre será bueno.

Diagram that shows a partition query for username.

Una consulta que filtrase por una propiedad diferente, como favoriteColor, se "diseminaría" por todas las particiones del contenedor. Esto también se conoce como consulta entre particiones. Esta consulta funcionará según lo esperado cuando el contenedor sea pequeño y solo ocupe una partición. Sin embargo, a medida que el contenedor crezca y haya un número creciente de particiones físicas, esta consulta será más lenta y más costosa porque tendrá que comprobar cada partición para obtener los resultados tanto si los contenedores de particiones físicas están relacionados con la consulta como si no lo están.

Diagram that shows a cross-partition query for favorite color.

Elección de la clave de partición para los clientes

Ahora que sabemos cómo funcionas las particiones en Azure Cosmos DB, podemos tomar una decisión respecto a una clave de partición para nuestros datos de cliente. Como se ha mencionado anteriormente, se realizan tres operaciones sobre los clientes: crear un cliente, actualizar un cliente y recuperar un cliente. En este caso, recuperaremos el cliente por su identificador. Dado que esa operación será a la que más se llame, tiene sentido convertir el identificador del cliente en la clave de partición del contenedor.

Diagram that shows the customer partition key as ID.

Aquí, puede preocuparle que al convertir el identificador en la clave de partición tengamos tantas particiones lógicas como clientes haya, y que cada partición lógica contenga solo un documento. Millones de clientes supondrían entonces millones de particiones lógicas.

Pero esto está perfectamente bien. Las particiones lógicas son un concepto virtual y no hay ningún límite en cuanto al número de particiones lógicas que pueda tener. Azure Cosmos DB colocará varias particiones lógicas en la misma partición física. A medida que las particiones lógicas aumenten de tamaño o de número, Cosmos DB las moverá a particiones físicas nuevas cuando sea necesario.