Hace poco trabajé en un proyecto para escalar automáticamente el rendimiento aprovisionado para DynamoDB de Amazon. Si no lo ha usado antes, no se preocupe, la idea básica es la siguiente:
– La métrica principal de DynamoDB es el rendimiento, que se mide en kilobytes por segundo.
– El servicio se factura en función del rendimiento que usted proporciona, no de su uso real.
– El servicio tiene una restricción interesante: no puede reducir su rendimiento aprovisionado más de 4 veces por día (medianoche a medianoche).
– Si supera su rendimiento aprovisionado, la API de DynamoDB le arroja un error de límite de velocidad durante un tiempo.
Con base en los hechos anteriores, escribí un sistema para rastrear el uso y escalar nuestro rendimiento automáticamente a fin de reducir los costos con un impacto mínimo en el servicio (por lo tanto, una limitación de velocidad mínima).
- ¿Alguna vez ha enviado un artículo científico sobre un algoritmo que funciona tan bien como los métodos más modernos pero realmente no sabe por qué? ¿Puedes decir 'tal vez' al explicar tu método?
- ¿Qué algoritmo se usa para detectar "No más interruptores posibles, barajar" en la saga Candy Crush?
- ¿Qué técnica general siguen los autores al escribir libros técnicos en LaTeX?
- ¿Cuál es la diferencia entre un problema formal y solo un problema?
- Lo que algunos deben saber son punteros para la optimización del código fundamental en Java
Una de las cosas que este sistema necesitaba hacer era rastrear el uso a lo largo del tiempo. Desafortunadamente, la API de Amazon que le brinda estos datos es un poco extraña de consultar y no siempre le brinda todos los datos que solicitó. Esa es la naturaleza de los grandes sistemas distribuidos. Por lo tanto, debe reconstruir lentamente la “realidad” y tomar decisiones solo cuando tenga suficientes datos.
Necesitaba una estructura de datos que me diera las siguientes cosas:
– Almacenamiento de clave / valor.
– Inserciones rápidas.
– Búsquedas rápidas de teclas.
– Recorrido rápido en orden clave.
El proceso también es de larga ejecución, por lo que era necesaria una estructura de datos que no se degradara con el tiempo (los árboles binarios están fuera).
Terminé usando un árbol rojo-negro. Esta joya de Ruby, para ser precisos: skade / rbtree
Los árboles rojo-negros se equilibran a sí mismos y brindan todas las cualidades que deseaba anteriormente. La implementación terminó siendo lo suficientemente rápida como para rastrear más de 20 tablas de manera confiable en un solo proceso, con casi toda la sobrecarga siendo llamadas a la API de DynamoDB.
Si está interesado en el código, puede encontrarlo aquí: invisiblehand / dynamo-autoscale. Las clases table_tracker.rb y rule.rb son las que aprovechan el uso de árboles rojo-negros.
