ApsaraDB for MongoDB:Introducción a los clústeres fragmentados de MongoDB

¿Cuándo usar un clúster fragmentado?

¿Cómo determinar el número de shards y mongos?

Selección de la clave de fragmentación

• Estrategias de fragmentación compatibles con los clústeres fragmentados de MongoDB

  • La fragmentación por rangos admite consultas de rango basadas en la clave de fragmentación.

  • La fragmentación por hash distribuye las escrituras uniformemente entre los shards.

  • La fragmentación consciente de etiquetas permite personalizar las reglas de distribución de chunks.

    Nota

    • Funcionamiento

      1. Utilice sh.addShardTag() para asignar la Etiqueta A a un shard.

      2. Utilice sh.addTagRange() para asignar la Etiqueta A a un rango de chunks de una colección. MongoDB garantiza entonces que el rango de chunks con la Etiqueta A, o un superconjunto de ese rango, se distribuya en el shard con la Etiqueta A.

    • Escenarios

      • Puede configurar etiquetas de centro de datos en shards desplegados en diferentes centros de datos. Esto distribuye los datos de distintos rangos de chunks a los centros de datos especificados.

      • Puede configurar etiquetas de nivel de servicio en shards con diferentes capacidades de servicio. Esto distribuye más chunks a los shards con mayores capacidades.

    • Notas

      ApsaraDB for MongoDB no puede distribuir chunks directamente a los nodos shard etiquetados con las etiquetas especificadas. Los chunks se distribuyen gradualmente a medida que las operaciones de inserción y actualización desencadenan frecuentemente la división y migración de chunks. Asegúrese de que el balanceador esté habilitado durante el proceso de distribución. Después de agregar etiquetas a los rangos de chunks, es posible que los datos escritos no se distribuyan al nodo shard que tiene las mismas etiquetas que los rangos de chunks.

• Problemas que la fragmentación por rangos y por hash no pueden resolver

  • El rango de valores de la clave de fragmentación es demasiado pequeño. Por ejemplo, si utiliza un centro de datos como clave de fragmentación, la fragmentación no es efectiva porque generalmente hay pocos centros de datos.

  • Un valor específico de la clave de fragmentación está presente en demasiados documentos. Esto puede provocar un único chunk de gran tamaño, conocido como jumbo chunk, que afecta la migración de chunks y el balanceo de carga.

  • Las consultas y actualizaciones basadas en un campo que no es clave de fragmentación se convierten en consultas scatter-gather, las cuales son ineficientes.

• Características de una buena clave de fragmentación

  • Cardinalidad suficiente

  • Escrituras distribuidas uniformemente

  • Evitar consultas scatter-gather (lecturas dirigidas).

Ejemplo:

Una aplicación de IoT utiliza una instancia de clúster fragmentado para almacenar los registros de millones de dispositivos. Cada dispositivo envía registros a la instancia de clúster fragmentado una vez cada 10 segundos. Los registros contienen información como identificadores de dispositivo y marcas de tiempo. Se consultan frecuentemente los registros generados por un dispositivo específico durante un rango de tiempo determinado.

Solicitud de consulta: Consulta los registros de un dispositivo específico dentro de un rango de tiempo especificado.

• (Recomendado) Método 1: Utilizar una clave de fragmentación compuesta por ID de dispositivo y marca de tiempo con fragmentación por rangos.

  • Las escrituras se distribuyen uniformemente entre varios shards.

  • Los datos del mismo ID de dispositivo se distribuyen además en múltiples chunks según la marca de tiempo.

  • Las consultas por rango de tiempo según el ID de dispositivo pueden completarse directamente mediante el índice compuesto (deviceId, timestamp).

• Método 2: Utilizar la marca de tiempo como clave de fragmentación con fragmentación por rangos.

  • Las nuevas escrituras tienen marcas de tiempo consecutivas y se envían todas al mismo shard, lo que provoca una distribución desigual de escrituras.

  • Las consultas por ID de dispositivo se dispersan a todos los shards, lo cual es ineficiente.

• Método 3: Utilizar la marca de tiempo como clave de fragmentación con fragmentación por hash.

  • Las escrituras se distribuyen uniformemente entre varios shards.

  • Las consultas por ID de dispositivo se dispersan a todos los shards, lo cual es ineficiente.

• Método 4: Utilizar el ID de dispositivo como clave de fragmentación con fragmentación por hash.

  Nota

  Si el ID de dispositivo no tiene un patrón evidente, puede utilizar fragmentación por rangos.

  • Las escrituras se distribuyen uniformemente entre varios shards.

  • Los datos del mismo ID de dispositivo no pueden subdividirse más y solo pueden distribuirse en un único chunk. Esto causa jumbo chunks. Las consultas por ID de dispositivo se envían a un solo shard. Una vez que la solicitud se enruta a ese shard, una consulta de rango basada en la marca de tiempo requiere un escaneo completo de la tabla y una ordenación.

Jumbo chunk y tamaño por chunk

El tamaño predeterminado por chunk en una instancia de clúster fragmentado es de 64 MB. Si el tamaño de un chunk supera los 64 MB y el chunk no se puede dividir, se etiqueta como jumbo chunk. Por ejemplo, si todos los documentos tienen el mismo valor de clave de fragmentación, estos documentos se almacenan en el mismo chunk, el cual no se puede dividir. El balanceador no puede migrar jumbo chunks, lo que puede causar un desequilibrio de carga. Se recomienda evitar la formación de jumbo chunks.

Acerca del balanceo de carga

El balanceo automático de carga en una instancia de clúster fragmentado se implementa mediante un hilo en segundo plano que se ejecuta en los nodos mongos de la instancia. Solo se puede ejecutar una tarea de migración por cada colección en un momento dado. El balanceo de carga se activa según el número de chunks por colección en cada nodo shard. Si la diferencia entre el número de chunks de una colección en un nodo shard y el número total de chunks de la colección alcanza el umbral especificado, ApsaraDB for MongoDB comienza a migrar los chunks de la colección desde el nodo shard hacia otros nodos shard. Debe especificar un umbral basado en el número total de chunks.

use config
                db.settings.update(
                { _id: "balancer" },
                { $set: { activeWindow : { start : "02:00", stop : "06:00" } } },
                { upsert: true }
                )
            

sh.stopBalancer()            

Configuración de archivado en el comando moveChunk

Si una instancia de clúster fragmentado ejecuta MongoDB 3.0 o anterior, el uso del espacio en disco en el catálogo de datos puede seguir aumentando incluso después de detener las escrituras de datos.

Este problema es causado por el elemento de configuración sharding.archiveMovedChunks, cuyo valor predeterminado es true en MongoDB 3.0 y versiones anteriores. Esta configuración significa que, durante una operación moveChunk, el shard de origen archiva los datos del chunk migrado con fines de recuperación. Como resultado, cuando se migra un chunk, el espacio en disco del nodo de origen no se libera, mientras que el nodo de destino utiliza nuevo espacio en disco.