Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure DocumentDB admite particionamiento para distribuir horizontalmente datos y tráfico. Los documentos de una colección se dividen en fragmentos denominados particiones lógicas.
El particionamiento se define individualmente para cada colección mediante una clave de partición designada de la estructura de documentos de la colección. A continuación, los datos se agrupan en fragmentos con cada fragmento correspondiente a una partición lógica. Los documentos para cada valor único de la propiedad de clave de partición residen en la misma partición lógica.
Para cada documento insertado en una colección particionada, al valor de la propiedad de clave de partición se le aplica un hash para calcular la partición lógica designada. La responsabilidad de colocar la partición lógica y distribuir todas las particiones lógicas dentro del clúster se abstrae del usuario y se administra completamente por el servicio.
Particiones lógicas
Todos los documentos que contienen el mismo valor para la clave de partición pertenecen a la misma partición lógica.
Por ejemplo, consideremos una colección denominada Employees con la estructura de documentos siguiente.
En esta tabla se muestra una asignación de valores de clave de partición a particiones lógicas.
| Id. de documento | Valor de clave de partición | Fragmento lógico |
|---|---|---|
| "12345" | "Steve Smith" | Partición 1 |
| "23456" | "Jane Doe" | Partición 2 |
| "34567" | "Steve Smith" | Partición 1 |
| "45678" | "Michael Smith" | Partición 3 |
| "56789" | "Jane Doe" | Partición 2 |
No hay límites para el número de particiones lógicas de una colección. Una colección puede tener tantas particiones lógicas como documentos con un valor único para la propiedad de clave de partición de cada documento.
Tampoco hay límites para el tamaño de una sola partición lógica.
Además, el servicio no limita las transacciones al ámbito de una partición lógica. Azure DocumentDB admite transacciones de lectura y escritura que son aplicables en varias particiones lógicas y en varias particiones físicas del clúster.
Particiones físicas
Las particiones físicas son las máquinas y discos subyacentes responsables de conservar los datos y cumplir las transacciones de base de datos. A diferencia de las particiones lógicas, el servicio administra las particiones físicas en segundo plano.
El número de particiones físicas se define cuando se crea un clúster y se puede aumentar si el tamaño de la base de datos crece con el tiempo. Los clústeres de particiones únicas tienen una partición física (nodo) que es completamente responsable de las transacciones de almacenamiento y base de datos del clúster. Los clústeres de varias particiones distribuyen los datos y el volumen de transacciones entre las particiones físicas del clúster.
Asignación de fragmentos lógicos a fragmentos físicos
Cuando se agregan nuevas particiones lógicas, el clúster actualiza sin problemas la asignación de particiones lógicas a físicas. Del mismo modo, la asignación del espacio de direcciones a cada partición física se cambia a medida que se agregan nuevas particiones físicas al clúster después de lo cual las particiones lógicas se vuelven a equilibrar en el clúster.
El intervalo hash usado para asignar particiones lógicas y físicas se distribuye uniformemente entre las particiones físicas del clúster. Cada partición física posee un cubo de tamaño uniforme del intervalo hash. Para cada documento escrito, al valor de la propiedad de clave de partición se le aplica un hash y el valor hash determina la asignación del documento a la partición física subyacente. Internamente, varios fragmentos lógicos se asignan a un solo fragmento físico. Además, las particiones lógicas nunca se dividen entre particiones físicas y todos los documentos de una partición lógica solo se asignan a una partición física.
Basándose en el ejemplo anterior mediante un clúster con dos particiones físicas, en esta tabla se muestra una asignación de ejemplo de documentos a particiones físicas.
| Id. de documento | Valor de clave de partición | Fragmento lógico | Partición física |
|---|---|---|---|
| "12345" | "Steve Smith" | Partición 1 | Partición física 1 |
| "23456" | "Jane Doe" | Partición 2 | Partición física 2 |
| "34567" | "Steve Smith" | Partición 1 | Partición física 1 |
| "45678" | "Michael Smith" | Partición 3 | Partición física 1 |
| "56789" | "Jane Doe" | Partición 2 | Partición física 2 |
Capacidad de particiones físicas
El nivel de clúster que se selecciona cuando se aprovisiona el clúster determina la capacidad de CPU y memoria de una partición física. Del mismo modo, la SKU de almacenamiento determina la capacidad de almacenamiento e IOPS de una partición física. Los niveles de clúster más grandes proporcionan más potencia de proceso y memoria mayor, mientras que los discos de almacenamiento más grandes proporcionan más almacenamiento e IOPS. Las cargas de trabajo de lectura intensiva se benefician de un nivel de clúster más grande, mientras que las cargas de trabajo de escritura intensiva se benefician de una SKU de almacenamiento mayor. El nivel de clúster se puede escalar y reducir verticalmente después de crear el clúster en función de las necesidades cambiantes de la aplicación.
En un clúster de varias particiones, la capacidad de cada partición física es la misma. El escalado vertical del nivel de clúster o la SKU de almacenamiento no cambia la ubicación de las particiones lógicas en las particiones físicas. Después de una operación de escalamiento, el número de particiones físicas sigue siendo el mismo, lo que evita la necesidad de reequilibrar los datos del clúster.
La capacidad de proceso, memoria, almacenamiento e IOPS de la partición física determinan los recursos disponibles para las particiones lógicas. Las claves de partición que no tienen una distribución uniforme de volúmenes de almacenamiento y solicitud pueden provocar un consumo desigual de almacenamiento y rendimiento dentro del clúster. Las particiones de acceso frecuente pueden hacer que las particiones físicas se utilicen de forma desigual, lo que conduce a un rendimiento y rendimiento impredecibles. Por lo tanto, los clústeres particionados requieren una planeación cuidadosa por adelantado para garantizar que el rendimiento sigue siendo coherente a medida que los requisitos de la aplicación cambian con el tiempo.
Conjuntos de réplicas
Cada fragmento físico consta de un conjunto de réplicas, conocido también como un grupo de réplicas. Cada réplica hospeda una instancia del motor de base de datos. Un conjunto de réplicas hace que el almacén de datos dentro de la partición física sea duradero, de alta disponibilidad y coherente. Cada réplica que compone la partición física hereda el almacenamiento y la capacidad de proceso de la partición física. Azure DocumentDB administra automáticamente los conjuntos de réplicas.
Procedimientos recomendados para particionar datos
El particionamiento en Azure DocumentDB no es necesario a menos que el almacenamiento y los volúmenes de transacciones de la colección puedan superar la capacidad de una sola partición física. Por ejemplo, el servicio proporciona 32 TB de discos por partición. Si una colección requiere más de 32 TB, debe particionarse.
No es necesario particionar todas las colecciones de un clúster con varias particiones físicas. Las colecciones particionadas y sin particiones pueden coexistir en el mismo clúster. El servicio distribuye de forma óptima las colecciones dentro del clúster para utilizar uniformemente los recursos de proceso y almacenamiento del clúster de la manera más uniforme posible.
Para las aplicaciones de lectura intensiva, la clave de partición debe seleccionarse en función de los patrones de consulta más frecuentes. El filtro de consulta más usado para una colección debe elegirse como clave de partición para optimizar el porcentaje más alto de transacciones de base de datos mediante la localización de la búsqueda en una sola partición física.
Para escribir aplicaciones pesadas que favorecen el rendimiento de escritura en las lecturas, se debe elegir una clave de partición para distribuir uniformemente los datos entre las particiones físicas. Las claves de partición con la cardinalidad más alta ofrecen la mejor oportunidad para distribuir de la forma más uniforme posible.
Para obtener un rendimiento óptimo, el tamaño de almacenamiento de una partición lógica debe ser inferior a 4 TB.
Para obtener un rendimiento óptimo, las particiones lógicas deben distribuirse uniformemente en el almacenamiento y solicitar volumen en las particiones físicas del clúster.
Cómo particionar una colección
Considere el siguiente documento dentro de la base de datos "cosmicworks" y la colección "employee"
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
En el ejemplo siguiente se particiona la colección employee dentro de la base de datos cosmicworks en la propiedad firstName.
use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})
La colección también se puede particionar mediante un comando admin:
use cosmicworks;
db.adminCommand({
"shardCollection": "cosmicworks.employee",
"key": {"firstName": "hashed"}
})
Aunque no es ideal cambiar la clave de partición después de que la colección haya crecido significativamente en el volumen de almacenamiento, el comando reshardCollection se puede usar para modificar la clave de partición.
use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})
La colección también se puede volver a particionar mediante un comando admin:
use cosmicworks;
db.adminCommand({
"reshardCollection": "cosmicworks.employee",
"key": {"lastName": "hashed"}
})
Como procedimiento recomendado, se debe crear un índice en la propiedad de clave de partición.
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
blocking: true
})