ApsaraDB for MongoDB:Problemas de rendimiento por exceso de bases de datos y colecciones

Eliminar colecciones innecesarias

Identifique las colecciones en la base de datos que se pueden eliminar, como aquellas que han caducado o ya no están en uso. Utilice el comando dropCollection para quitarlas. Para obtener más información, consulte dropCollection().

Utilice los siguientes comandos para consultar la información de bases de datos y colecciones:

• Ejecute el siguiente comando para ver la cantidad de colecciones en una base de datos.

  db.getSiblingDB(<dbName>).getCollectionNames().length

• Ejecute el siguiente comando para ver información detallada sobre una base de datos, incluida la cantidad de colecciones, índices y documentos, así como el tamaño total de los datos.

  // View statistics for a specific database.
  db.getSiblingDB(<dbName>).stats()

• Ejecute el siguiente comando para ver información detallada sobre una colección específica.

  // View statistics for a specific collection.
  db.getSiblingDB(<dbName>).<collectionName>.stats()

Eliminar índices innecesarios

Reducir la cantidad de índices también disminuye el número de archivos de disco y las estructuras dhandle correspondientes mantenidas por el motor de almacenamiento WiredTiger, lo que ayuda a mitigar este problema.

Siga estos principios básicos para la optimización de índices:

• Evite índices no utilizados

  Si una consulta nunca accede a un campo específico, cualquier índice en ese campo no se utilizará. Dichos índices se consideran no utilizados y se pueden eliminar.

• Siga las reglas de prefijo de índice

  Por ejemplo, si tiene tanto los índices {a:1} como {a:1,b:1}, el primer índice es un prefijo redundante del segundo y se puede eliminar.

• Considere el orden de los campos del índice para consultas de igualdad

  Para coincidencias de igualdad, el orden de los campos en un índice compuesto no importa. Por ejemplo, para consultas en los campos a y b, los índices {a:1,b:1} y {b:1,a:1} son funcionalmente equivalentes. Puede eliminar el que se utilice con menor frecuencia.

• Utilice la regla ESR para consultas de rango

  Para crear un índice compuesto óptimo para sus consultas, organice los campos en el orden de Equality, Sort, Range. Para obtener más información, consulte The ESR (Equality, Sort, Range) Rule.

• Revise índices con bajos recuentos de aciertos

  Un índice con un bajo recuento de aciertos a menudo se superpone con un índice más eficiente. Analice todos los patrones de consulta relevantes para determinar si puede eliminarlo de forma segura.

Puede utilizar la etapa de agregación $indexStats de MongoDB para ver estadísticas de todos los índices en una colección. Asegúrese de tener los permisos necesarios antes de ejecutar el siguiente comando.

// View index statistics for a specific collection.
db.getSiblingDB(<dbName>).<collectionName>.aggregate({"$indexStats":{}})

El comando devuelve una salida similar al siguiente ejemplo.

{
   "name" : "item_1_quantity_1",
   "key" : { "item" : 1, "quantity" : 1 },
   "host" : "examplehost.local:27018",
   "accesses" : {
      "ops" : NumberLong(1),
      "since" : ISODate("2020-02-10T21:11:23.059Z")
   }
}

La siguiente tabla describe los parámetros en la información devuelta.

Si observa que un índice tiene un recuento de aciertos muy bajo, por ejemplo, si accesses.ops es 1, es probable que sea un índice redundante o no utilizado que puede considerar eliminar. Si su instancia de MongoDB es versión 4.4 o posterior, puede usar el comando hideIndex para ocultar el índice antes de eliminarlo. Esto le permite confirmar que no hay un impacto negativo en su aplicación durante un período de tiempo, reduciendo el riesgo de la eliminación del índice.

// players collection
{
  "_id": "ObjectId(123)",
  "first_name": "John",
  "last_name": "Doe",
  "coins": 11,
  "stars": 2
}

Consolidar datos de varias colecciones

Consolide los datos de varias colecciones en una sola colección para reducir el recuento total de colecciones.

Por ejemplo, una base de datos llamada temperatures almacena datos de temperatura de sensores. Un sensor opera de 10:00 AM a 10:00 PM, leyendo y almacenando datos de temperatura cada media hora. Almacena los datos de temperatura de cada día en una colección separada nombrada según la fecha.

Los siguientes fragmentos muestran datos parciales de dos colecciones, temperatures.march-09-2020 y temperatures.march-10-2020.

• Colección temperatures.march-09-2020

  {
    "_id": 1,
    "timestamp": "2020-03-09T010:00:00Z",
    "temperature": 29
  }
  {
    "_id": 2,
    "timestamp": "2020-03-09T010:30:00Z",
    "temperature": 30
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-09T022:00:00Z",
    "temperature": 26
  }

• Colección temperatures.march-10-2020

  {
    "_id": 1,
    "timestamp": "2020-03-10T010:00:00Z",
    "temperature": 30
  }
  {
    "_id": 2,
    "timestamp": "2020-03-10T010:30:00Z",
    "temperature": 32
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-10T022:00:00Z",
    "temperature": 28
  }
  

Con el tiempo, aumenta la cantidad de colecciones en la base de datos. Dado que MongoDB no impone un límite estricto en la cantidad de colecciones y este modelo carece de una política clara de ciclo de vida de los datos, el número de colecciones y sus índices correspondientes crece indefinidamente.

Además del problema de un número de colecciones en constante crecimiento, este modelo de datos dificulta la realización de consultas que abarcan varios días. Para consultar datos a lo largo de varios días y analizar tendencias de temperatura a largo plazo, necesitaría usar consultas $lookup, las cuales tienen un rendimiento inferior al de las consultas dentro de una sola colección.

Un mejor modelo de datos consiste en almacenar todas las lecturas de temperatura en una sola colección, con los datos de cada día almacenados en un único documento. Este enfoque es un ejemplo del Patrón de Bucket. El siguiente ejemplo muestra el modelo optimizado.

// temperatures.readings
{
  "_id": ISODate("2020-03-09"),
  "readings": [
    {
      "timestamp": "2020-03-09T010:00:00Z",
      "temperature": 29
    },
    {
      "timestamp": "2020-03-09T010:30:00Z",
      "temperature": 30
    },
    ...
    {
      "timestamp": "2020-03-09T022:00:00Z",
      "temperature": 26
    }
  ]
}
{
  "_id": ISODate("2020-03-10"),
  "readings": [
    {
      "timestamp": "2020-03-10T010:00:00Z",
      "temperature": 30
    },
    {
      "timestamp": "2020-03-10T010:30:00Z",
      "temperature": 32
    },
    ...
    {
      "timestamp": "2020-03-10T022:00:00Z",
      "temperature": 28
    }
  ]
}

El modelo optimizado consume muchos menos recursos que el modelo original. Ya no necesita crear índices basados en la hora del día, y el índice predeterminado _id en la colección facilita las consultas por fecha. Esto también resuelve el problema de un número ilimitado de colecciones.

Dividir la instancia

Si no puede reducir el número total de bases de datos y colecciones dentro de una sola instancia de MongoDB, considere una división lógica de la instancia de base de datos junto con los cambios correspondientes en su aplicación.

Puede abordar esto en dos escenarios:

Migrar a un clúster fragmentado con etiquetas de fragmento

Si todas sus colecciones están en una sola base de datos y desea gestionarlas como una única instancia lógica, considere migrar sus datos a una arquitectura de clúster fragmentado y utilizar etiquetas de fragmento para su gestión. El método de gestión de etiquetas de fragmento es ligeramente más complejo y requiere pasos operativos adicionales (usando sh.addShardTag y sh.addTagRange). Sin embargo, una sola instancia de MongoDB sigue gestionando todas las colecciones, lo que requiere cambios mínimos en su aplicación. Solo necesita reemplazar la cadena de conexión por la de la nueva instancia de clúster fragmentado.

Por ejemplo, si su instancia tiene 100,000 colecciones activas, puede adquirir una nueva instancia de clúster fragmentado de 10 fragmentos. Siga el proceso a continuación para configurar la instancia y migrar datos, lo que resultará en 10,000 colecciones activas por fragmento. El procedimiento es el siguiente:

1. Adquiera una nueva instancia de clúster fragmentado. Este ejemplo utiliza una instancia de 2 fragmentos. Para obtener instrucciones sobre cómo crear un clúster fragmentado, consulte Create a sharded cluster instance.

2. Conéctese al nodo mongos de la instancia de clúster fragmentado. Para obtener más información, consulte Connect to an ApsaraDB for MongoDB sharded cluster instance by using the mongo shell.

3. Ejecute los siguientes comandos para agregar una etiqueta de fragmento a cada fragmento.

   sh.addShardTag("d-xxxxxxxxx1", "shard_tag1")
   sh.addShardTag("d-xxxxxxxxx2", "shard_tag2")

   Nota

   • Antes de ejecutar estos comandos, asegúrese de que la cuenta que está utilizando tenga los permisos necesarios.

   • DMS (Data Management) actualmente no admite el comando sh.addShardTag. Se recomienda conectarse a la instancia con mongo shell o mongosh para ejecutar estos comandos.

4. Preconfigure las reglas de distribución de rangos basadas en etiquetas para todas las colecciones fragmentadas.

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.addTagRange("<dbName>.test", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag1")
   sh.addTagRange("<dbName>.test1", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag2")

   Este ejemplo utiliza _id como clave de fragmentación. Elija una clave de fragmentación que se adapte a su carga de trabajo y asegúrese de que todas las operaciones de consulta incluyan el campo de clave de fragmentación. La clave de fragmentación debe ser coherente con el campo utilizado en el siguiente paso. También debe utilizar los límites [MinKey,MaxKey] para garantizar que todos los datos de una sola colección residan en un único fragmento.

5. Ejecute la operación shardCollection para todas las colecciones que se van a migrar.

   sh.shardCollection("<dbName>.test", {"_id":1})
   sh.shardCollection("<dbName>.test1", {"_id":1})

6. Ejecute el comando sh.status() para confirmar que las reglas están vigentes.

   zhongli.test
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag1  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
   zhongli.test1
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag2  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrate data from a replica set instance to a sharded cluster instance.

   Nota

   Dado que ya ha prefragmentado las colecciones en la instancia de destino, toda la información de bases de datos y colecciones ya existe. Por lo tanto, debe establecer el Processing Mode of Conflicting Tables en Ignore Errors and Proceed en su tarea de DTS.

8. Después de verificar la consistencia de los datos, cambie sus aplicaciones para acceder a la nueva instancia de clúster fragmentado.

Migrar a un clúster fragmentado con zonas

Este método es similar al uso de etiquetas de fragmento, pero utiliza la función Zones de MongoDB en su lugar. Requiere pasos operativos adicionales, específicamente sh.addShardToZone() y sh.updateZoneKeyRange().

El procedimiento es el siguiente:

1. Adquiera una nueva instancia de clúster fragmentado. Este ejemplo utiliza una instancia de 2 fragmentos. Para obtener instrucciones sobre cómo crear un clúster fragmentado, consulte Create a sharded cluster instance.

2. Conéctese al nodo mongos de la instancia de clúster fragmentado. Para obtener más información, consulte Connect to an ApsaraDB for MongoDB sharded cluster instance by using the mongo shell.

3. Ejecute los siguientes comandos para asignar cada fragmento a una zona.

   sh.addShardToZone("d-xxxxxxxxx1", "ZoneA")
   sh.addShardToZone("d-xxxxxxxxx2", "ZoneB")

   Nota

   • Antes de ejecutar estos comandos, asegúrese de que la cuenta que está utilizando tenga los permisos necesarios.

   • DMS actualmente no admite el comando sh.addShardToZone. Se recomienda conectarse a la instancia con mongo shell o mongosh para ejecutar estos comandos.

4. Preconfigure las reglas de distribución de rangos basadas en zonas para todas las colecciones.

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.updateZoneKeyRange("<dbName>.test", { "_id": MinKey }, { "_id": MaxKey }, "ZoneA")
   sh.updateZoneKeyRange("<dbName>.test1", { "_id": MinKey }, { "_id": MaxKey }, "ZoneB")

   Este ejemplo utiliza _id como clave de fragmentación. Elija una clave de fragmentación que se adapte a su carga de trabajo y asegúrese de que todas las operaciones de consulta incluyan el campo de clave de fragmentación. La clave de fragmentación debe ser coherente con el campo utilizado en el siguiente paso. También debe utilizar los límites [MinKey,MaxKey] para garantizar que todos los datos de una sola colección residan en un único fragmento.

5. Ejecute la operación shardCollection para todas las colecciones que se van a migrar.

   sh.shardCollection("<dbName>.test", { "_id": 1 })
   sh.shardCollection("<dbName>.test1", { "_id": 1 })

6. Ejecute el comando sh.status() para ver la distribución de fragmentación y confirmar que la configuración de zona está vigente. La salida de ejemplo es la siguiente:

   {  "_id" : "shardDistributionDB",  "primary" : "d-xxx24",  "partitioned" : false,  "version" : {  "uuid" : UUID("1dc635xxx"),  "lastMod" : 1 } }
           shardDistributionDB.test
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2ze9797089ef3704      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx04 Timestamp(1, 0)
                    tag: ZoneA  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
           shardDistributionDB.test1
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2zed2e752c35af24      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx24 Timestamp(1, 0)
                    tag: ZoneB  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrate data from a replica set instance to a sharded cluster instance.

   Nota

   Dado que ya ha prefragmentado las colecciones en la instancia de destino, toda la información de bases de datos y colecciones ya existe. Por lo tanto, debe establecer el Processing Mode of Conflicting Tables en Ignore Errors and Proceed en su tarea de DTS.

8. Después de verificar la consistencia de los datos, cambie sus aplicaciones para acceder a la nueva instancia de clúster fragmentado.