Escalabilidad en Azure DocumentDB

Azure DocumentDB ofrece la capacidad de escalar clústeres tanto vertical como horizontalmente. Aunque el nivel de clúster de proceso y el disco de almacenamiento dependen funcionalmente entre sí, la escalabilidad y el costo del proceso y el almacenamiento se desacoplan.

Escalado vertical

El escalado vertical ofrece las siguientes ventajas:

• Es posible que los equipos de aplicaciones no siempre tengan una ruta de acceso clara para particionar lógicamente sus datos. Además, el particionamiento lógico se define por colección. En un conjunto de datos con varias colecciones no fragmentadas, el modelado de datos para particionar los datos puede resultar rápidamente tedioso. Simplemente escalar verticalmente el clúster puede eludir la necesidad de particionamiento lógico al tiempo que satisface las crecientes necesidades de almacenamiento y proceso de la aplicación.
• El escalado vertical no requiere reequilibrio de datos. El número de particiones físicas sigue siendo el mismo y solo aumenta la capacidad del clúster sin afectar a la aplicación.
• El escalado y la reducción son operaciones sin tiempo de inactividad y sin interrupciones en el servicio. No se necesitan cambios en la aplicación y las operaciones de estado estacionario pueden continuar sin perturbaciones.
• Los recursos informáticos también se pueden reducir durante los periodos conocidos de baja actividad. Una vez más, escalar hacia abajo evita la necesidad de redistribuir los datos entre menos particiones físicas y es una operación sin tiempo de inactividad, sin interrupciones en el servicio. No se necesita hacer ningún cambio en la aplicación después de reducir el clúster.
• Lo más importante es que el proceso y el almacenamiento se pueden escalar de forma independiente. Si se necesitan más núcleos y memoria, el tamaño del disco se puede dejar tal como está y el nivel de clúster se puede escalar verticalmente. Igualmente, si se necesitan más almacenamiento e IOPS, el nivel de clúster se puede dejar tal como está y el tamaño de almacenamiento se puede escalar verticalmente de forma independiente. Si es necesario, tanto el proceso como el almacenamiento se pueden escalar de forma independiente para optimizar los requisitos de cada componente individualmente, sin que ninguno de los requisitos de elasticidad del componente afecte al otro.

Escalado horizontal

Finalmente, la aplicación crece hasta un punto en el que el escalado verticalmente no es suficiente. Los requisitos de carga de trabajo pueden crecer más allá de la capacidad del nivel de clúster más grande y, finalmente, se necesitan más particiones. El escalado horizontal en Azure DocumentDB ofrece las siguientes ventajas:

• Los conjuntos de datos particionados lógicamente no requieren la intervención del usuario para equilibrar los datos entre las particiones físicas subyacentes. El servicio asigna automáticamente particiones lógicas a particiones físicas. Cuando se agregan o eliminan nodos, los datos se reequilibran automáticamente en la base de datos en segundo plano.
• Las solicitudes se enrutan automáticamente a la partición física pertinente que posee el intervalo hash de los datos que se consultan.
• Los clústeres distribuidos geográficamente tienen una configuración homogénea de varios nodos. Por lo tanto, las asignaciones de particiones físicas son coherentes entre las regiones principal y de réplica de un clúster.

Escalado de proceso y almacenamiento

Los recursos de proceso y memoria influyen en las operaciones de lectura en Azure DocumentDB más que las IOPS de disco.

• Las operaciones de lectura primero consultan la memoria caché en la capa de proceso y vuelven al disco cuando no se pudieron recuperar los datos de la memoria caché. En el caso de las cargas de trabajo con una mayor tasa de operaciones de lectura por segundo, el escalado vertical del nivel de clúster para obtener más recursos de CPU y memoria conduce a un mayor rendimiento.
• Además del rendimiento de lectura, las cargas de trabajo con un gran volumen de datos por operación de lectura también se benefician del escalado de los recursos de proceso del clúster. Por ejemplo, los niveles de clúster con más memoria facilitan tamaños de carga mayores por documento y un número mayor de documentos más pequeños por respuesta.

Las IOPS de disco influyen en las operaciones de escritura en Azure DocumentDB más que las capacidades de CPU y memoria de los recursos de proceso.

• Las operaciones de escritura siempre conservan los datos en el disco (además de conservar los datos en la memoria para optimizar las lecturas). Los discos más grandes con más IOPS proporcionan un mayor rendimiento de escritura, especialmente cuando se ejecuta a escala.
• El servicio admite hasta 32 TB de discos por partición, con más IOPS por partición para beneficiarse de la escritura de cargas de trabajo pesadas, especialmente cuando se ejecuta a escala.

Cargas de trabajo intensivas de almacenamiento y discos de gran tamaño

No hay requisitos mínimos de almacenamiento por nivel de clúster

Como se mencionó anteriormente, los recursos de almacenamiento y procesamiento se separan para fines de facturación y aprovisionamiento. Aunque funcionan como una unidad cohesiva, se pueden escalar de forma independiente. El nivel de clúster M30 puede tener discos aprovisionados de 32 TB. Del mismo modo, el nivel de clúster M200 puede tener discos de 32 GB aprovisionados para optimizar tanto los costos de almacenamiento como de procesamiento.

Menor TCO con discos grandes (32 TB y versiones posteriores)

Normalmente, las bases de datos NoSQL limitan el almacenamiento por partición física a 4 TB. Azure DocumentDB proporciona hasta 8 veces esa capacidad con discos de 32 TB. En el caso de las cargas de trabajo pesadas de almacenamiento, una capacidad de almacenamiento de 4 TB por partición física requiere una gran flota de recursos de proceso solo para mantener los requisitos de almacenamiento de la carga de trabajo. La capacidad de cómputo es más costosa que el almacenamiento, y el aprovisionamiento excesivo de recursos debido a las limitaciones de capacidad de un servicio puede inflar los costos rápidamente.

Consideremos una carga de trabajo intensiva de almacenamiento con 200 TB de datos.

La reducción de los requisitos de computación se reduce drásticamente con discos más grandes. Aunque es posible que sea necesario más que el número mínimo de particiones físicas para mantener los requisitos de rendimiento de la carga de trabajo, incluso duplicar o triplicar el número de particiones es más rentable que un clúster de 50 particiones con discos más pequeños.

Omitir niveles de almacenamiento con discos grandes

Una respuesta inmediata a los costos de proceso en escenarios pesados de almacenamiento consiste en "organizar" los datos. Los datos de la base de datos transaccional se limitan a los datos "activos" a los que se accede con más frecuencia, mientras que el volumen mayor de datos "fríos" se traslada a un almacén en frío. Esto provoca la complejidad operativa. El rendimiento también es impredecible y depende del nivel de datos al que se accede. Además, la disponibilidad de todo el sistema depende de la resiliencia combinada de los almacenes de datos en caliente y en frío. Con discos grandes en el servicio, no es necesario el almacenamiento en capas, ya que se minimiza el costo de las cargas de trabajo intensas de almacenamiento.

Pasos siguientes

• Aprenda a escalar el clúster de Azure DocumentDB
• Consulte los procedimientos recomendados de indexación