Esta es una serie corta que quería compartir desde hace mucho tiempo sobre los conceptos básicos de "Optimización de costos" en AWS.

¡Comencemos este viaje con DocumentDB !

No dudes en 👏 si te ha gustado este post ;)

De acuerdo, para ser realmente honesto, este título es clickbait *.*

Definitivamente podría escribir algo como "cómo realicé la optimización de costos en nuestra infraestructura de AWS al respetar algunas pautas comunes proporcionadas en la documentación ", pero es mucho menos atractivo, ¿no?

Quizás algunos de ustedes ya conozcan estos trucos y buenas prácticas.

Si está buscando directamente la lista de verificación que sugiero, desplácese aquí.

Comprenda el complicado costo de E/S del servicio DocumentDB

Si observa su página de precios, está dividida por 4 dimensiones de costos, lo resumo aquí:

• El precio de la instancia : bueno, este costo es comprensible rápidamente: paga por una instancia, y el precio dependerá de sus recursos (CPU, RAM, etc.)
• Costos de almacenamiento y almacenamiento de respaldo : igual que el anterior, es bastante comprensible, y podemos rastrear y estimar fácilmente los costos de los mismos, la factura de AWS por GB almacenado. Legal.
• La parte más complicada es la E/S de la base de datos : ¡AWS facturará entre 0,20 $ y 0,30 $ (según la región de la instancia) por 1 millón de E/S!

Entonces, ¿qué hay detrás de las E/S?

AWS explica que con el servicio DocumentDB, no tiene que aprovisionar recursos de E/S por adelantado, lo cual es bastante interesante, porque no tiene limitaciones de almacenamiento y puede manejar fácilmente una selección de operaciones de E/S. Parece justo, ya que se le factura por el uso.

AWS describe en su documentación lo que cubre las operaciones de E/S, principalmente todas las operaciones como buscar, insertar, actualizar y eliminar o algunas características como flujos de cambios e índices TTL (tiempo de vida).

Bueno, todo lo que afecte el volumen de almacenamiento se te facturará.

Espera, ¿qué, 0,20 $ por millón de E/S?

¡Hagamos que AWS pierda dinero, ahora mismo!

Hay una frase en la documentación de AWS DocumentDB que llamará su atención (y billetera 💸):

Una vez, una vez que los datos se han leído del volumen de almacenamiento y continúan residiendo en la memoria, las lecturas posteriores de los mismos datos no incurren en E/S adicionales.

Esta frase es clave para entender qué hay detrás de las E/S.

¿Qué operaciones utilizan menos E/S?

Las consultas que usan un índice probablemente usarán menos E/S ya que no está escaneando todo el almacenamiento de su colección. Ciertamente consumirá E/S, pero mucho menos que escanear una colección completa.

Además, la RAM de su instancia debe cubrir el tamaño de su índice, lo que le permitirá no incurrir en operaciones de E/S adicionales.

Tenga en cuenta que debe respetar algunos principios con el uso de índices.

Lista de verificación ✅

Este es mi consejo/lista de verificación cuando desee optimizar su uso de E/S y reducir sus costos y mejorar el rendimiento.

Verá que no soy un genio, ya que solo agrego información de la página de documentación de AWS DocumentDB con algunas mejores prácticas comunes que no son estrictamente aplicables a DocumentDB.

Siempre es bueno refrescar nuestras mentes con principios.

• 🧠 Primero, recuerda esto : menos E/S = más barato = mejor rendimiento, aquí no se trata solo de costos ni de rendimiento, pero las dos cosas están vinculadas.

• ❌ Eliminar índices sin usar : no sabes lo caro que es un índice sin usar para una colección ocupada. Hice que mi empresa ahorrara 2000 $/mes así de fácil 🤌, eliminando los índices no utilizados. Y es muy fácil rastrear índices no utilizados con esta consulta:

  
  

Consulta de estadísticas de índice

La consulta generará las ops de campo que corresponden a la cantidad de veces que se alcanza su índice. Dependiendo de la carga de su aplicación, considere eliminar el índice no utilizado.

• 🧐 Active la información de rendimiento y las operaciones de generación de perfiles : si usa RDS, es posible que esté al tanto de la información de rendimiento , le brinda algunas métricas e información muy útiles sobre las consultas que están afectando su rendimiento de DocumentDB, y puede ver rápidamente las consultas que consumen I /Os operaciones (y la cantidad de ellas), por lo que es muy bueno para rastrear fácilmente un cuello de botella. Otra forma de monitorear consultas lentas o consultas collscan es activando las operaciones de generación de perfiles, como su nombre indica, está generando perfiles para usted de algunas operaciones (aquí hay un enlace para obtener más información:), puede establecer un umbral que colocará en CloudWatch un registro de un operación que está tomando más de n ms . Muy útil para rastrear el número de consultas que están realizando COLLSCAN por ejemplo. ¡Active ambas opciones ya que son muy valiosas!

  
  

• 💾 Mire siempre primero sus datos : deberá identificar el mejor campo de cardinalidad alta que desea indexar, si no está acostumbrado al concepto de cardinalidad de índice, la documentación de AWS DocumentDB está bien explicada :)

  
  

• 🫠 Evite colecciones pequeñas y complicadas : si planea tener una colección que tendrá tres campos con uno de ellos con una clave única, y si planea realizar muchas actualizaciones/inserciones, considere la modelización de su colección, porque sus operaciones de E/S se verán afectadas y, por lo tanto, su uso de E/S.

  
  

• ⏱️ Evite TTL, también conocido como índices de tiempo de salida : (la mayoría de las veces) puede manejarlo sin establecer un índice de tiempo de salida, así que verifique que el parámetro TTL no esté habilitado en la instancia o el clúster.

  
  

• 💡 ¡Explica! Una forma muy sencilla de verificar la selectividad del índice del planificador de consultas cuando está realizando una nueva consulta (o no) es realizar una operación de explicación con el parámetro executionStats . Se sorprenderá de que algunas consultas que está pensando en índice de éxito, simplemente no lleguen a ningún índice...

  
  

• ☯️ No cree un índice para un campo booleano . Simplemente no lo hagas. Recuerda la cardinalidad.

  
  

• ⚖️ Supervise el tamaño promedio de un objeto para cada colección que tenga con este comando: db.<mycollection>.stats(1024) Un tamaño promedio extremo puede crear rápidamente un bloqueo en sus consultas y aumentar las operaciones de E/S porque la RAM de tu instancia no es suficiente. Supervise de cerca los objetos y no almacene campos innecesarios. Si necesita almacenar muchos campos, considere optimizar las consultas al no seleccionar todos los campos.

  
  

• ⚠️ Tenga en cuenta que DocumentDB no es MongoDB. Es principalmente compatible con MongoDB pero no es MongoDB ya que hay algunos comportamientos específicos de mierda. Por ejemplo, si desea realizar una consulta con el operador $regex , deberá indicar su indexación, ya que es obligatorio. Los operadores de exclusión nunca usarán ningún índice, así que tenga en cuenta estos comportamientos al crear u optimizar sus índices.

  
  

• 👉Nunca insinuar . A excepción de los casos de uso muy específicos mencionados anteriormente, debe evitar el uso de la hint , tenga en cuenta que si el planificador de consultas no elige su índice, es por una buena razón. La mayoría de las veces es porque es más largo o equivalente a escanear el índice en lugar de todos los documentos de la colección.

• 
  

Espero que aprecie estos trucos que aprendí mientras trabajaba en AWS Cost Optimization para mi empresa.

¡Estén atentos para otra publicación!

No dudes en 👏 si te ha gustado este post ;)

PD: si algo parece mal o un malentendido, no dudes en enviarme un mensaje privado.

También publicado aquí