Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas para Amazon DocumentDB

Conozca las prácticas recomendadas para trabajar con Amazon DocumentDB (con compatibilidad con MongoDB). Esta sección se actualiza continuamente a medida que se identifican nuevas prácticas recomendadas.

Directrices operativas básicas

A continuación se detallan las directrices operativas básicas que se deben seguir al trabajar con Amazon DocumentDB. El acuerdo de nivel de servicios de Amazon DocumentDB requiere que se sigan estas directrices.

Determinación del tamaño de las instancias

Uno de los aspectos más importantes a la hora de elegir un tamaño de instancia en Amazon DocumentDB es la cantidad RAM de memoria caché. Amazon DocumentDB reserva un tercio de la instancia RAM para sus propios servicios, lo que significa que solo dos tercios de la instancia RAM están disponibles para la memoria caché. Por lo tanto, una práctica recomendada de Amazon DocumentDB es elegir un tipo de instancia que sea suficiente RAM para que quepa en la memoria el conjunto de trabajo (es decir, datos e índices). Tener instancias de un tamaño adecuado ayudará a optimizar el rendimiento general y minimizar potencialmente el costo de E/S. Puede utilizar la calculadora de tamaño de Amazon DocumentDB de terceros para estimar el tamaño de la instancia para una carga de trabajo concreta.

Para determinar si el conjunto de trabajo de su aplicación cabe en la memoria, supervise el BufferCacheHitRatio uso de Amazon CloudWatch para cada instancia de un clúster que esté bajo carga.

La BufferCacheHitRatio CloudWatch métrica mide el porcentaje de datos e índices servidos desde la caché de memoria de una instancia (en comparación con el volumen de almacenamiento). En términos generales, el valor de BufferCacheHitRatio debe ser lo más alto posible, ya que la lectura de datos de la memoria del conjunto de trabajo es más rápida y rentable que la lectura del volumen de almacenamiento. Si bien es deseable mantener BufferCacheHitRatio lo más cerca posible del 100 %, el mejor valor alcanzable dependerá de los patrones de acceso y los requisitos de rendimiento de su aplicación. Para mantener el nivel más alto posibleBufferCacheHitRatio, se recomienda aprovisionar las instancias del clúster con una cantidad suficiente RAM para que quepan los índices y el conjunto de datos de trabajo en la memoria.

Si sus índices no caben en la memoria, verá un valor de BufferCacheHitRatio inferior. La lectura continua desde el disco implica costos adicionales de E/S y no es mejor que la lectura desde la memoria. Si la BufferCacheHitRatio proporción es inferior a la esperada, amplíe el tamaño de la instancia del clúster para proporcionar más datos que quepan en RAM la memoria del conjunto de trabajo. Si escalar la clase de instancia provoca un aumento drástico de BufferCacheHitRatio, entonces el conjunto de trabajo de su aplicación no cabe en la memoria. Continúe con el escalado hasta que BufferCacheHitRatio ya no aumente drásticamente después de una operación de escalado. Para obtener información acerca del monitoreo de las métricas de una instancia, consulte Métricas de Amazon DocumentDB.

Dependiendo de la carga de trabajo y los requisitos de latencia, puede ser aceptable que la aplicación tenga valores más altos de BufferCacheHitRatio durante el uso de estado constante, pero tenga una caída periódica de BufferCacheHitRatio a medida que las consultas analíticas que necesitan analizar una colección completa se ejecutan en una instancia. Estas caídas periódicas en BufferCacheHitRatio pueden manifestarse como una latencia más alta para consultas posteriores que necesitan volver a llenar los datos del conjunto de trabajo desde el volumen de almacenamiento de nuevo en la caché del búfer. Le recomendamos que pruebe las cargas de trabajo en un entorno de preproducción con una carga de trabajo de producción representativa primero, para comprender las características de rendimiento y BufferCacheHitRatio antes de implementar la carga de trabajo en producción.

BufferCacheHitRatio es una métrica específica de instancia, por lo que las distintas instancias dentro del mismo clúster pueden tener valores de BufferCacheHitRatio diferentes, dependiendo de cómo se distribuyen las lecturas entre la instancia principal y la de réplica. Si la carga de trabajo operativa no puede controlar los aumentos periódicos de latencia por volver a llenar la caché del conjunto de trabajo después de ejecutar consultas analíticas, debe intentar aislar la caché del búfer de la carga de trabajo normal de la de las consultas analíticas. Puede lograr un aislamiento completo de BufferCacheHitRatio dirigiendo las consultas operativas a la instancia principal y las consultas analíticas solo a las instancias de réplica. También puede lograr un aislamiento parcial dirigiendo consultas analíticas a una instancia de réplica específica, entendiendo que un porcentaje de consultas regulares también se ejecutarán en esa réplica y podrían verse afectadas.

Los valores adecuados de BufferCacheHitRatio dependen del caso de uso y los requisitos de la aplicación. No hay un valor máximo o mínimo para esta métrica; solo usted puede decidir si la compensación de un valor de BufferCacheHitRatio temporalmente inferior es aceptable desde una perspectiva de costo y rendimiento.

Uso de índices

Creación de índices

Al importar datos en Amazon DocumentDB, debe crear los índices antes de importar grandes conjuntos de datos. Puede utilizar la herramienta de índices de Amazon DocumentDB para extraer índices de una instancia de MongoDB en ejecución o de un directorio mongodump, y crear dichos índices en un clúster de Amazon DocumentDB. Para obtener más información acerca de las migraciones, consulte Migración a Amazon DocumentDB.

Selectividad de índice

Se recomienda limitar la creación de índices a campos donde el número de valores duplicados sea inferior al 1 % del número total de documentos de la colección. Por ejemplo, si la colección cuenta con 100 000 documentos, solo cree índices en campos donde el mismo valor se produzca 1000 veces o menos.

Elegir un índice con un alto número de valores únicos (es decir, una alta cardinalidad) garantiza que las operaciones de filtro devuelvan un pequeño número de documentos, con lo que se obtiene un buen rendimiento durante los análisis de índices. Un ejemplo de un índice de alta cardinalidad es un índice único, que garantiza que los predicados de igualdad devuelvan como máximo un documento único. Entre los ejemplos de baja cardinalidad se incluyen un índice sobre un campo booleano y un índice sobre el día de la semana. Debido a su bajo rendimiento, es poco probable que el optimizador de consultas de la base de datos elija índices de cardinalidad baja. Al mismo tiempo, los índices de cardinalidad baja continúan consumiendo recursos como espacio en disco y E/S. Como regla general, debe aplicar los índices a campos donde la frecuencia del valor típica sea un 1 % del tamaño total de la colección o menos.

Además, se recomienda crear índices únicamente en campos que se utilizan comúnmente como filtro y buscar regularmente índices no utilizados. Para obtener más información, consulte ¿Cómo analizo el uso de los índices e identifico los índices no utilizados?.

Impacto de los índices en los datos de escritura

Aunque los índices pueden mejorar el rendimiento de las consultas al evitar la necesidad de examinar todos los documentos de una colección, esta mejora tiene algún inconveniente. Para cada índice de una colección, cada vez que se inserta, actualiza o elimina un documento, la base de datos debe actualizar la colección y escribir los campos en cada uno de los índices de la colección. Por ejemplo, si una colección tiene nueve índices, la base de datos debe realizar diez escrituras antes de validar la operación para el cliente. Por lo tanto, cada índice adicional genera latencia de escritura adicional, E/S y aumento del almacenamiento utilizado en general.

Las instancias del clúster deben tener el tamaño adecuado para mantener toda la memoria del conjunto de trabajo. Esto evita la necesidad de leer continuamente las páginas de índice del volumen de almacenamiento, lo que afecta negativamente al rendimiento y genera mayores costos de E/S. Para obtener más información, consulte Determinación del tamaño de las instancias.

Para obtener un mejor rendimiento, reduzca el número de índices de sus colecciones, agregando solo los índices necesarios para mejorar el rendimiento de las consultas comunes. Aunque las cargas de trabajo varían, una buena directriz es mantener el número de índices por colección en cinco o menos.

Identificación de índices que faltan

Identificar y eliminar los índices que faltan es una práctica recomendada que aconsejamos realizar de forma periódica. Para obtener más información, consulte ¿Cómo identifico los índices que faltan?.

Identificación de índices no utilizados

Identificar y eliminar índices no utilizados es una práctica recomendada que aconsejamos realizar de forma periódica. Para obtener más información, consulte ¿Cómo analizo el uso de los índices e identifico los índices no utilizados?.

Prácticas recomendadas de seguridad

Como prácticas recomendadas de seguridad, debe usar cuentas AWS Identity and Access Management (IAM) para controlar el acceso a las operaciones de Amazon DocumentDB, especialmente a API las operaciones que crean, modifican o eliminan los recursos de Amazon DocumentDB. Dichos recursos incluyen clústeres, grupos de seguridad y grupos de parámetros. Debe utilizar también IAM para controlar las acciones administrativas comunes como la restauración de las copias de seguridad de los clústeres. Al crear roles de IAM, utilice el principio de privilegios mínimos.

Optimización de costos

Las siguientes prácticas recomendadas pueden ayudarlo a administrar y minimizar sus costos cuando utilice Amazon DocumentDB. Para obtener información sobre precios, consulte los precios de Amazon DocumentDB (compatible con MongoDB) y Amazon DocumentDB (compatible con MongoDB). FAQs

Uso de métricas para identificar los problemas de rendimiento

Para identificar los problemas de rendimiento causados por la falta de recursos y otros cuellos de botella frecuentes, puede monitorizar las métricas disponibles para su clúster de base de datos de Amazon DocumentDB.

Visualización de métricas de rendimiento

Monitorice las métricas de desempeño con frecuencia para ver los valores medios, máximos y mínimos de diversos intervalos de tiempo. Esto lo ayuda a identificar cuándo se degrada el rendimiento. También puedes configurar CloudWatch las alarmas de Amazon para determinados umbrales de métricas, de forma que recibas una alerta si se alcanzan.

Para solucionar los problemas de rendimiento, es importante conocer el desempeño de referencia del sistema. Después de configurar un nuevo clúster y ponerlo en marcha con una carga de trabajo típica, capture los valores promedio, máximo y mínimo de todas las métricas de rendimiento en diferentes intervalos (por ejemplo, 1 hora, 24 horas, 1 semana, 2 semanas). Esto permite hacerse una idea de lo que es normal. Ayuda a obtener comparaciones para las horas con picos y valles de funcionamiento. Puede usar esta información para saber cuándo cae el desempeño por debajo de los niveles estándar.

Para ver las métricas de rendimiento, utilice la AWS Management Console tecla o. AWS CLI Para obtener más información, consulte Visualización CloudWatch de datos.

Configurar una CloudWatch alarma

Para configurar una CloudWatch alarma, consulta Uso de Amazon CloudWatch Alarms en la Guía del CloudWatch usuario de Amazon.

Evaluación de las métricas de rendimiento

Una instancia tiene varias categorías diferentes de métricas. La forma de determinar los valores aceptables depende de la métrica.

En general, los valores aceptables para las métricas de desempeño dependen del aspecto de la referencia y de lo que hace la aplicación. Investigue las variaciones coherentes o de las tendencias con respecto a la referencia.

A continuación, se ofrecen algunas recomendaciones y sugerencias sobre tipos concretos de métricas:

Si sus consultas están ajustadas y el problema persiste, considere la posibilidad de actualizar su clase de instancia de Amazon DocumentDB a una con más recursos (CPU,, espacio en discoRAM, ancho de banda de red, capacidad de E/S) relacionados con el problema que está experimentando.

Evaluación del uso de instancias de Amazon DocumentDB con métricas CloudWatch

Puede usar CloudWatch las métricas para observar el rendimiento de su instancia y descubrir si su clase de instancia proporciona recursos suficientes para sus aplicaciones. Para obtener información sobre los límites de la clase de instancia, vaya a Límites de instancias y busque las especificaciones de la clase de instancia para encontrar el rendimiento de la red.

Si el uso de la instancia está cerca del límite de las clases de instancia, es posible que el rendimiento comience a disminuir. Las CloudWatch métricas pueden confirmar esta situación, por lo que puedes planificar la ampliación manual a una clase de instancias más grande.

Combina los siguientes valores de CloudWatch métricas para saber si te estás acercando al límite de clases de instancias:

Añada el NetworkThroughputal StorageNetworkThroughputpara encontrar el rendimiento de red recibido y enviado al volumen de almacenamiento del clúster de Amazon DocumentDB por cada instancia de su clúster de Amazon DocumentDB. El límite de clases de instancia para su instancia debe ser mayor que la suma de estas dos métricas combinadas.

Puede utilizar las siguientes métricas para revisar detalles adicionales del tráfico de red de las aplicaciones cliente al enviar y recibir:

Sume todas estas métricas para evaluar cómo está el uso de la red con respecto al límite de las clases de instancias. El límite de las clases de instancias debe ser mayor que la suma de estas métricas combinadas.

Los límites de la red y el CPU uso por parte de una instancia son mutuos. Cuando el rendimiento de la red aumenta, la CPU utilización también aumenta. La supervisión CPU y el uso de la red proporcionan información sobre cómo y por qué se están agotando los recursos.

Para ayudar a minimizar el uso de la red, puede considerar lo siguiente:

Ajuste de consultas

Una de las formas más eficaces de mejorar el rendimiento de clúster es ajustar las consultas más utilizadas y que más recursos consumen para que ejecutarlas resulte más económico.

Puede utilizar el generador de perfiles (consulte Creación de perfiles de operaciones en Amazon DocumentDB) para registrar el tiempo de ejecución y los detalles de las operaciones realizadas en el clúster. El generador de perfiles es útil para monitorizar las operaciones más lentas del clúster para ayudarle a mejorar el rendimiento de las consultas individuales y el rendimiento general del clúster.

También puede utilizar el comando explain para descubrir cómo analizar un plan de consulta para una determinada consulta. Utilice esta información para modificar una consulta o una colección subyacente con el fin de mejorar el rendimiento de las consultas (por ejemplo, cómo añadir un índice).

TTLy cargas de trabajo de series temporales

La eliminación de documentos como resultado de la caducidad del TTL índice es el mejor proceso. No se garantiza la eliminación de documentos dentro de un periodo específico. Factores como el tamaño de la instancia, la utilización de los recursos de la instancia, el tamaño del documento, el rendimiento general, el número de índices y si los índices y el conjunto de trabajo caben en la memoria pueden afectar al momento en que el proceso elimina los documentos caducados. TTL

Cuando el TTL monitor elimina los documentos, cada eliminación implica costes de E/S, lo que aumenta la factura. Si las tasas de rendimiento y TTL eliminación aumentan, cabe esperar una factura más alta debido al aumento del uso de E/S. Sin embargo, si no crea un TTL índice para eliminar documentos, sino que los segmenta en colecciones en función del tiempo y simplemente elimina esas recopilaciones cuando ya no las necesita, no incurrirá en ningún coste de E/S. Esto puede resultar considerablemente más rentable que utilizar un TTL índice.

Para las cargas de trabajo de series temporales, puede considerar la posibilidad de crear recopilaciones continuas en lugar de un TTL índice, ya que las recopilaciones sucesivas pueden ser una forma mejor de eliminar datos y requerir menos E/S. Si tiene colecciones de gran tamaño (especialmente aquellas de más de 1 TB) o si le preocupan los costes de E/S de TTL eliminación, le recomendamos que divida los documentos en colecciones en función del tiempo y elimine las recopilaciones cuando los documentos ya no los necesite. Puede crear una colección por día o una por semana, dependiendo de su tasa de incorporación de datos. Aunque los requisitos varían en función de su aplicación, una buena regla general es tener colecciones más pequeñas en lugar de unas pocas colecciones grandes. Eliminar estas recopilaciones no implica costes de E/S y puede ser más rápido y rentable que utilizar un índice. TTL

Migraciones

Como práctica recomendada, recomendamos que al migrar datos a Amazon DocumentDB, primero cree los índices en Amazon DocumentDB antes de migrar los datos. Crear los índices en primer lugar puede reducir el tiempo general y aumentar la velocidad de la migración. Para hacer esto, puede usar la Herramienta de índice de Amazon DocumentDB. Para obtener más información sobre las migraciones, consulte la Guía de migración de Amazon DocumentDB.

También le recomendamos que antes de migrar la base de datos de producción, se recomienda probar completamente la aplicación en Amazon DocumentDB, teniendo en cuenta la funcionalidad, el rendimiento, las operaciones y el costo.

Uso de grupos de parámetros de clúster

Es recomendable que pruebe los cambios de los grupos de parámetros de clúster en un clúster de prueba antes de aplicarlos en los clústeres de producción. Para obtener información acerca del procedimiento para realizar la copia de seguridad del clúster, consulte Copia de seguridad y restauración en Amazon DocumentDB.

Consultas de canalización de agregación

Si crea una consulta de canalización de agregación con varias etapas y evalúa un solo subconjunto de los datos de la consulta, utilice la etapa $match como primera etapa o al principio de la canalización. Usar primero $match reducirá el número de documentos que las etapas posteriores tendrán que procesar dentro de la consulta de canalización de agregación, mejorando así el rendimiento de su consulta.

batchInsert y batchUpdate

Al realizar una alta tasa de batchUpdate operaciones simultáneas batchInsert o simultáneas y la cantidad FreeableMemory (CloudWatch métrica) se reduce a cero en la instancia principal, puede reducir la simultaneidad de la carga de trabajo de inserción o actualización por lotes o, si no se puede reducir la simultaneidad de la carga de trabajo, aumentar el tamaño de la instancia para aumentar la cantidad de. FreeableMemory