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 de RAM de la memoria caché. Amazon DocumentDB reserva un tercio de la RAM para sus propios servicios, lo que significa que solo dos tercios de la RAM de la instancia están disponibles para la memoria caché. Es una práctica recomendada de rendimiento de Amazon DocumentDB elegir un tipo de instancia con suficiente RAM para que su conjunto de trabajo (es decir, datos e índices) quepa en la memoria. 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 la aplicación cabe en la memoria, monitorice el BufferCacheHitRatio utilizando Amazon CloudWatch para cada instancia de un clúster que está en carga.

La métrica de Cloudwatch de BufferCacheHitRatio mide el porcentaje de datos e índices servidos desde la caché de la 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 BufferCacheHitRatio más alto posible, se recomienda que las instancias del clúster cuenten con suficiente RAM para poder ajustar 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 proporción de BufferCacheHitRatio es inferior a la esperada, aumente el tamaño de la instancia del clúster para proporcionar más RAM, de forma que los datos del conjunto de trabajo quepan en la memoria. 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

Para las prácticas recomendadas de seguridad, debe usar cuentas de (IAM) de AWS Identity and Access Management para controlar el acceso a las operaciones de la API de Amazon DocumentDB, especialmente las operaciones que crean, modifican o eliminan recursos de . 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 (con compatibilidad con MongoDB) y las preguntas frecuentes sobre Amazon DocumentDB (con compatibilidad con MongoDB).

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 puede definir alarmas de Amazon CloudWatch para umbrales de métricas concretos si desea recibir alertas cuando se alcancen.

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.

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

Para definir una alarma de CloudWatch

Para configurar alarmas, consulte Uso de alarmas de Amazon CloudWatch en la Guía del usuario de CloudWatch.

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 las consultas se ajustan y el problema persiste, considere la posibilidad de actualizar su clase de instancia de Amazon DocumentDB a una con más cantidad del recurso (CPU, RAM, espacio en disco, ancho de banda de la red, capacidad de E/S) relacionado con el problema que se está experimentando.

Evaluación de la utilización de instancias de Amazon DocumentDB con métricas de CloudWatch

Puede usar las métricas de CloudWatch 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 métricas de CloudWatch pueden confirmar esta situación para que pueda planificar el escalado vertical manual a una clase de instancia más grande.

Combine los siguientes valores de métricas de CloudWatch para averiguar si se acerca al límite de clases de instancia:

Sume la métrica NetworkThroughput a StorageNetworkThroughput para determinar el rendimiento de red recibido y enviado al volumen de almacenamiento del clúster de Amazon DocumentDB por cada instancia del 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 uso de la CPU por una instancia son mutuos. Cuando aumenta el rendimiento de la red, también aumenta la utilización de la CPU. La supervisión del uso de la CPU y la red proporciona información sobre cómo y por qué se agotan 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).

TTL y cargas de trabajo de series temporales

La eliminación de documentos resultante del vencimiento del índice TTL es un proceso muy laborioso. 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 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 el que el proceso TTL elimina los documentos caducados.

Cuando el monitor de TTL elimina sus documentos, cada eliminación produce costos de E/S, lo que aumenta su factura. Si el rendimiento y las tasas de eliminación de TTL aumentan, debería esperar mayores costos en su factura debido al incremento del uso de operaciones de E/S. Sin embargo, si no crea un índice TTL para eliminar documentos, sino que los segmenta en colecciones en función del tiempo y simplemente elimina esas colecciones cuando ya no las necesita, no incurrirá en ningún costo de E/S. Esto puede resultar considerablemente más rentable que utilizar un índice TTL.

Para cargas de trabajo de series temporales, puede plantearse la creación de colecciones sucesivas en lugar de un índice TTL, ya que estas colecciones pueden ser una mejor forma de eliminar datos y pueden utilizar menos operaciones de E/S. Si tiene colecciones grandes (especialmente colecciones de más de 1 TB) o los costos de E/S de eliminación de TTL son motivo de preocupación, se recomienda dividir los documentos en colecciones en función del tiempo y eliminar las colecciones cuando los documentos ya no sean necesarios. 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. La eliminación de estas colecciones no implica costos de E/S y puede ser significativamente más rentable que usar 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

Si se realiza un alto número de operaciones de batchUpdate o batchInsert simultáneas y la cantidad de FreeableMemory (Métrica de CloudWatch) se queda a cero en la instancia principal, puede reducir la concurrencia de la carga de trabajo de inserción o actualización por lotes o, si no se puede reducir la concurrencia de la carga de trabajo, aumentar el tamaño de instancia para aumentar la cantidad de FreeableMemory.