Sharding

Cantidad de particiones

A continuación se muestra un ejemplo usando la base de datos mytable, la colección mycoll y el name del campo como clave de shard.

1. Inicie sesión en una instancia de clúster fragmentada con Mongo Shell.
2. Habilite el sharding para las bases de datos que pertenecen a la instancia del clúster.
   • Método 1

     sh.enableSharding("<database>") 

     Ejemplo:

     sh.enableSharding("mytable")

   • Método 2

     use admin 
     db.runCommand({enablesharding:"<database>"})

3. Shard una colección.
   • Método 1

     sh.shardCollection("<database>.<collection>",{"<keyname>":<value> })

     Ejemplo:

     sh.shardCollection("mytable.mycoll",{"name":"hashed"})

   • Método 2

     use admin
     db.runCommand({shardcollection:"<database>.<collection>",key:{"keyname":<value> }})

   Tabla 1 Descripción del parámetro

   Parámetro	Descripción
   <database>	Nombre de la base de datos
   <collection>	Nombre de colección
   <keyname>	Clave de shard Las instancias de clúster se fragmentan según el valor de este parámetro. Seleccione una clave de shard adecuada para la colección en función de sus requisitos de servicio. Para más detalles, consulte Selección de una clave de fragmento.
   <value>	El orden basado en el rango de la clave de shard. 1: Índices ascendentes -1: Índices descendentes hashed: indica que se utiliza el sharding de hash. El sharding de hash proporciona una distribución de datos más uniforme en todo el clúster sharded. Para obtener más información, consulte sh.shardCollection ().

4. Compruebe el estado de almacenamiento de datos de la base de datos en cada shard.

   sh.status()

   Ejemplo:

   

Selección de una clave de fragmento

• Antecedentes

  Cada clúster sharded contiene colecciones como su unidad básica. Los datos de la colección son particionados por la clave de shard. La clave de shard es un campo de la colección. Distribuye los datos de manera uniforme entre shards. Si no selecciona una clave de shard adecuada, el rendimiento del clúster puede deteriorarse y el proceso de ejecución de la sentencia de shard puede estar bloqueado.

  Una vez que se determina la clave de shard, no se puede cambiar. Si ninguna clave de fragmento es adecuada para el sharding, debe usar una política de sharding y migrar datos a una nueva colección para el sharding.

• Características de las claves de shard apropiadas
  • Todas las inserciones, actualizaciones y eliminaciones se distribuyen uniformemente a todos los shards de un clúster.
  • La distribución de claves es suficiente.
  • Raras consultas de scatter-gather.

  Si la clave de shard seleccionada no tiene todas las características anteriores, la escalabilidad de lectura y escritura del clúster se ve afectada. Por ejemplo, si la carga de trabajo de la operación find () se distribuye de manera desigual en los shards, se generarán shards calientes. Del mismo modo, si su carga de escritura (insertos, actualizaciones y eliminaciones) no se distribuye uniformemente en tus shards, entonces podrías terminar con un shard caliente. Por lo tanto, debe ajustar las claves de shard en función de los requisitos de servicio, como el estado de lectura/escritura, los datos consultados con frecuencia y los datos escritos.

  Después de fragmentar los datos existentes, si filtro archivado de la solicitud de actualización no contiene claves de shard y upsert:true o multi:false, la solicitud de actualización reportará un error y devolverá el mensaje "Un upsert en una colección de shard debe contener la clave de shard y tener la simple intercalación".

• Criterios de juicio
  Puede utilizar las dimensiones proporcionadas en Tabla 2 para determinar si las claves de shard seleccionadas cumplen con los requisitos de servicio:

  Tabla 2 Claves de shard razonables

  Criterios de identificación	Descripción
  Cardinalidad	La cardinalidad se refiere a la capacidad de dividir trozos. Por ejemplo, si necesita registrar la información del estudiante de una escuela y usar la edad como clave de shard, los datos de los estudiantes de la misma edad se almacenarán en un solo segmento de datos, lo que puede afectar el rendimiento y la capacidad de administración de sus clústeres. Una clave de shard mucho mejor sería el número de estudiante porque es único. Si el número de estudiante se utiliza como una clave de shard, la cardinalidad relativamente grande puede garantizar la distribución uniforme de los datos.
  Escribir la distribución	Si se realizan un gran número de operaciones de escritura en el mismo período de tiempo, desea que la carga de escritura se distribuya uniformemente sobre los shards del clúster. Si la política de distribución de datos es sharding por intervalo, una clave de shard monótonamente creciente garantizará que todas las inserciones vayan a un solo shard.
  Leer la distribución	De manera similar, si se realizan un gran número de operaciones de lectura en el mismo período, desea que su carga de lectura se distribuya uniformemente sobre los shards en un clúster para utilizar plenamente el rendimiento informático de cada shard.
  Lectura dirigida	El router de consulta mongos puede realizar una consulta dirigida (consulta de solo un shard) o una consulta de dispersión/recopilación (consulta todos los shards). La única manera de que los mongos puedan apuntar a un solo shard es tener la clave de shard presente en la consulta. Por lo tanto, debe elegir una clave de shard que estará disponible para su uso en las consultas comunes mientras se ejecuta la aplicación. Si elige una clave de shard sintética y su aplicación no puede usarla durante consultas típicas, todas sus consultas se convertirán en scatter/gather, limitando así su capacidad de escalar la carga de lectura.

Elección de una política de distribución

Un clúster con fragmentos puede almacenar los datos de una colección en varios shards. Puede distribuir datos basados en las claves de shard de los documentos de la colección.

Hay dos políticas de distribución de datos: sharding por rango y sharding por hash. Para más detalles, consulte 3.

A continuación se describen las ventajas y desventajas de los dos métodos.

• Sharding por rango

  El sharding basado en rango implica dividir los datos en intervalos contiguos determinados por los valores de clave del shard. Si asume que una clave de shard es una línea estirada desde el infinito positivo y el infinito negativo, cada valor de la clave de shard es la marca en la línea. También puede asumir segmentos pequeños y separados de una línea y que cada fragmento contiene datos de una clave de shard dentro de un rango determinado.

  Figura 1 Distribución de datos
  

  Como se muestra en la figura anterior, el campo x indica la clave de shard de sharding por rango. El rango de valores es [minKey,maxKey] y el valor es un entero. El rango de valores se puede dividir en múltiples fragmentos, y cada fragmento (normalmente 64 MB) contiene un pequeño segmento de datos. Por ejemplo, el fragmento 1 contiene todos los documentos en el rango [minKey, -75] y todos los datos de cada fragmento se almacenan en el mismo fragmento. Eso significa que cada shard contiene múltiples chunks. Además, los datos de cada shard se almacenan en el servidor de configuración y se distribuyen uniformemente por mongos en función de la carga de trabajo de cada shard.

  El sharding por rango puede cumplir fácilmente los requisitos de consulta en un cierto rango. Por ejemplo, si necesita consultar documentos cuya clave de shard está en el rango [-60,20], mongos solo necesita reenviar la solicitud al chunk 2.

  Sin embargo, si las claves de shard están en orden ascendente o descendente, es probable que los documentos recién insertados se distribuyan en el mismo chunk, lo que afecta a la expansión de la capacidad de escritura. Por ejemplo, si se usa _id como clave de fragmento, los bits altos de _id generados automáticamente en el clúster son ascendentes.

• Sharding por hash

  El sharding por hash calcula el valor hash (entero de 64 bits) de un solo campo como valor de índice; este valor se utiliza como clave de shard para particionar datos en el clúster compartido. El sharding hashed proporciona una distribución de datos más uniforme en el clúster hashed, ya que es posible que los documentos con claves de shard similares no se almacenen en el mismo chunk.

  Figura 2 Distribución de datos
  

  El sharding hashed distribuye aleatoriamente documentos a cada chunk, lo que amplía completamente la capacidad de escritura y compensa la deficiencia del rango de shanrding. Sin embargo, las consultas en un cierto rango deben distribuirse a todos los shards de backend para obtener documentos que cumplan las condiciones, lo que resulta en una baja eficiencia de la consulta.