MongoDB utiliza la Clave de fragmento asociada a la colección para particionar los datos en fragmentos. Un fragmento consiste en un subconjunto de datos fragmentados. Cada fragmento tiene un rango inferior inclusivo y un rango superior exclusivo según la clave de fragmento.
MongoDB divide los fragmentos cuando exceden del tamaño de fragmento configurado. Tanto las inserciones como las actualizaciones pueden desencadenar una división de fragmento.
El rango mínimo que un fragmento puede representar es un solo valor de clave de partición único. Un fragmento que solo contiene documentos con un único valor de la clave de partición no se puede dividir.
Fragmentos iniciales
Colección completada
La operación de particionado crea el(los) fragmento(s) inicial(es) para cubrir todo el rango de los valores de la clave de partición. La cantidad de fragmentos creados depende del tamaño configurado del fragmento.
Después de la creación del fragmento inicial, el balanceador migra estos fragmentos iniciales a través de los fragmentos según corresponda y también administra la distribución de los fragmentos en el futuro.
Colección vacía
Si se tienen zonas y rangos de zonas definidos para una colección vacía o inexistente.
La operación de particionado crea fragmentos vacíos para los rangos de zona definidos, así como fragmentos adicionales para cubrir todo el rango de los valores de la clave de partición y realiza una distribución inicial de fragmentos basada en los rangos de zona. Esta creación y distribución inicial de fragmentos permite configurar más rápidamente el particionado de zona.
Después de la distribución inicial, el balanceador gestiona la distribución de fragmento en adelante.
Si no tienes zonas y rangos de zonas definidos para una colección vacía o inexistente:
Para el particionado encriptado:
La operación de particionado crea fragmentos vacíos para cubrir todo el rango de los valores de la clave de partición y realiza una distribución inicial de fragmentos. Por defecto, la operación crea 2 fragmentos por partición y se migra en todo el clúster. Puedes usar
numInitialChunksOpción para especificar un número diferente de fragmentos iniciales. Esta creación y distribución inicial de fragmentos permite una configuración más rápida de la fragmentación.Después de la distribución inicial, el balanceador gestiona la distribución de fragmento en adelante.
Para el particionado clasificado por rango:
La operación de particionado crea un único fragmento vacío para cubrir todo el rango de valores de la clave de partición.
Tras la creación inicial del fragmento, el balanceador migra el fragmento inicial a través de las particiones según convenga, además de gestionar la distribución de fragmentos en adelante.
Tamaño del fragmento
El tamaño predeterminado de un fragmento en MongoDB es de 64 megabytes. Puede aumentarlo o reducirlo. Considere las implicaciones de cambiar el tamaño predeterminado de un fragmento:
Los fragmentos pequeños permiten una distribución más uniforme de los datos, a costa de migraciones más frecuentes. Esto genera un gasto en la capa de enrutamiento de consultas ().
mongosLos grandes fragmentos reducen el número de migraciones. Esto es más eficiente tanto desde la perspectiva de redes como en lo que respecta a la sobrecarga interna en la capa de enrutamiento de query. Sin embargo, estas eficiencias se logran a expensas de una potencial distribución desigual de los datos.
El tamaño del fragmento afecta el Número máximo de documentos por fragmento a migrar.
El tamaño de fragmento afecta el tamaño máximo de la colección al particionar una colección existente. Después del particionado, el tamaño del fragmento no restringe el tamaño de la colección.
Para muchas implementaciones, tiene sentido evitar migraciones frecuentes y potencialmente erróneas a costa de un conjunto de datos un poco menos uniforme.
Limitaciones
Cambiar el tamaño de fragmento afecta cuándo se produce la división de los fragmentos, pero existen algunas limitaciones en sus efectos.
La división automática solo ocurre durante inserciones o actualizaciones. Si reduces el tamaño del fragmento, puede llevar tiempo que todos los fragmentos se dividan al nuevo tamaño.
Las divisiones no se pueden "deshacer". Si aumenta el tamaño del fragmento, los fragmentos existentes deben aumentar a través de inserciones o actualizaciones hasta alcanzar el nuevo tamaño.
Divisiones de fragmentos
La división es un proceso que impide que los fragmentos crezcan demasiado. Cuando un chunk crece más allá de un tamaño de chunk especificado, o si el número de documentos en el chunk supera el Número Máximo de Documentos por Chunk para Migrar, MongoDB divide el chunk en función de los valores de la clave de partición que el chunk representa. Un fragmento puede ser dividido en varios fragmentos cuando sea necesario. Las inserciones y actualizaciones pueden desencadenar divisiones. Las divisiones son un cambio eficiente de metadatos. Para crear divisiones, MongoDB no migra ningún dato ni afecta a las particiones.
Las divisiones pueden provocar una distribución desigual de los fragmentos de una colección entre las particiones. En tales casos, el balanceador redistribuye los fragmentos entre las particiones. Consulta Clúster balanceador para obtener más detalles sobre el equilibrado de fragmentos entre particiones.
Migración de fragmentos
MongoDB migra fragmentos en un clúster para distribuir los fragmentos de una colección particionada de manera uniforme entre las particiones. Las migraciones pueden ser:
Manual. Solo se usa la migración manual en casos limitados, por ejemplo, para distribuir datos durante las inserciones masivas. Ver Migración manual de fragmentos para obtener más detalles.
Automático. El proceso del balanceador migra automáticamente fragmentos cuando hay una distribución desigual de los fragmentos de una colección particionada a través de las particiones. Consulta Umbrales de migración para más detalles.
Para obtener más información sobre el balanceador del clúster particionado, se puede consultar Balanceador de clúster particionado.
Balanceo
El balanceador es un proceso en segundo plano que gestiona la migración de fragmentos. Si la diferencia en el número de fragmentos entre el fragmento más grande y el más pequeño supera los umbrales de migración, el balanceador comienza a migrar fragmentos en todo el clúster para garantizar una distribución uniforme de los datos.
Puede administrar ciertos aspectos del balanceador. Este también respeta las zonas creadas durante la configuración de zonas en un clúster fragmentado.
Ver Balanceador del Clúster Particionado para obtener más información sobre el balanceador.
Fragmentos indivisibles/fragmento jumbo
En algunos casos, los fragmentos pueden crecer más allá del tamaño de fragmento especificado, pero no pueden sufrir una división. El escenario más común es cuando un fragmento representa un solo valor de la clave de partición. Dado que el fragmento no puede dividirse, continúa creciendo más allá del tamaño del fragmento, convirtiéndose en un fragmento jumbo. Estos fragmentos jumbo pueden convertirse en un cuello de botella de rendimiento a medida que continúan creciendo, especialmente si el valor de la clave de partición se presenta con alta frecuencia.
A partir de MongoDB 5.0, puedes refragmentar una colección al cambiar la clave de fragmentación de un documento.
MongoDB proporciona el comando refineCollectionShardKey. Refinar la clave de partición de una colección permite una distribución de datos más precisa y puede abordar situaciones en las que la insuficiente cardinalidad de la clave existente conduce a fragmentos jumbo.
Para aprender si se debe redistribuir la colección o refinar la clave de partición, se puede consultar Cambiar la clave de partición.
Para obtener más información, consulte:
moveChunk directorio
En MongoDB 2.6 y MongoDB 3.0, sharding.archiveMovedChunks está habilitado por defecto. Todas las demás versiones de MongoDB tienen esto deshabilitado por defecto. Con sharding.archiveMovedChunks habilitado, la partición de origen archiva los documentos en los fragmentos migrados en un directorio nombrado según el namespace de la colección en el directorio moveChunk en el storage.dbPath.
Si ocurre algún error durante una migración, estos archivos pueden ser útiles para recuperar los documentos afectados durante la migración.
Una vez que la migración se haya completado con éxito y no sea necesario recuperar documentos de estos archivos, puede borrar estos archivos de forma segura. O, si tienes una copia de seguridad existente de la base de datos que puedes usar para la recuperación, también puedes borrar estos archivos después de la migración.
Para determinar si se completaron todas las migraciones, ejecute sh.isBalancerRunning() mientras esté conectado a una mongos instancia.