Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. Es fácil entender por qué tantos equipos se han convertido en Amazon DynamoDB desde su introducción en 2012. Es fácil comenzar, especialmente si su organización ya está arraigada en el ecosistema de AWS. Es relativamente rápido y escalable, con una curva de aprendizaje baja. Pero con el paso del tiempo, surgen desventajas, especialmente a medida que la escala de las cargas de trabajo y los requisitos empresariales evolucionan. Los equipos a veces necesitan una latencia más baja, costes más bajos (especialmente a medida que escalan), o la capacidad de ejecutar sus aplicaciones en otro lugar que AWS. En esos casos, ScyllaDB, que ofrece una API compatible con DynamoDB, a menudo se selecciona como una alternativa. Exploremos los desafíos que llevaron a tres equipos a abandonar DynamoDB. Flexibilidad multi-cloud y ahorro de costes Yieldmo es una plataforma de publicidad en línea que conecta a editores y anunciantes en tiempo real utilizando un sistema basado en subastas, optimizado con ML. Su negocio depende de entregar anuncios rápidamente (dentro de 200-300 milisegundos) y de manera eficiente, lo que requiere búsquedas de bases de datos ultra rápidas y de alto rendimiento a escala. Inicialmente construyeron la plataforma en DynamoDB. Sin embargo, mientras DynamoDB había sido confiable, surgieron limitaciones significativas a medida que crecían. Como explicó Todd Coleman, cofundador técnico y arquitecto jefe, sus principales preocupaciones eran doble: la escalada de costes y las restricciones geográficas. Al explorar las alternativas de DynamoDB, esperaban encontrar una opción que mantendría la velocidad, la escalabilidad y la fiabilidad, al tiempo que reducía los costos y proporcionaba la independencia del proveedor de la nube. Yieldmo primero consideró quedarse con DynamoDB y agregar una capa de caché. Sin embargo, el caché no pudo solucionar el problema de latencia geográfica. También exploraron Aerospike, que ofreció soporte de velocidad y cross-cloud. sin embargo, la indexación en memoria de Aerospike habría requerido un clúster prohibitivamente grande y caro para manejar el gran número de objetos de datos pequeños de Yieldmo. Luego descubrieron ScyllaDB. Y la API compatible con DynamoDB (Alternator) de ScyllaDB fue un cambiador de juego. Todd explicó: “ScyllaDB soportaba las implementaciones en la nube, requería un número de servidores gestionables y ofrecía costes competitivos. Lo mejor de todo, su API era compatible con DynamoDB, lo que significa que podíamos migrar con cambios mínimos de código. El proceso de migración fue cuidadosamente planificado, aprovechando su arquitectura de cola de mensajes Kafka existente para garantizar la integridad de los datos. Realizaron dos pruebas de prueba de concepto (POC): primero con una sola tabla de 28 mil millones de objetos, y luego en todas las cinco regiones de AWS. Los resultados fueron impresionantes.Todd compartió, “Nuestros costos de base de datos se redujeron a la mitad, incluso con el precio de la capacidad reservada de DynamoDB.”Y más allá de los ahorros de costos, Yieldmo obtuvo la flexibilidad para potencialmente desplegar a través de diferentes proveedores de nube. En resumen, Todd concluyó: “Una de nuestras preocupaciones iniciales era alejarse de la fiabilidad probada de DynamoDB. Sin embargo, ScyllaDB ha sido un excelente socio. Su equipo proporciona monitoreo de nuestros clústeres, nos alerta de posibles problemas y nos aconseja cuando se necesita escalar en términos de mantenimiento continuo. La experiencia ha sido comparable a DynamoDB, pero con mayor independencia y ahorros de costes sustanciales”. Escuchando de Yieldmo Migración a GCP con mejor rendimiento y menores costes Digital Turbine, un jugador importante en la tecnología de publicidad móvil con 500 millones de dólares en ingresos anuales, se enfrentaba a desafíos crecientes con su implementación de DynamoDB. Mientras su principal motivación para la migración era la estandarización en Google Cloud Platform después de las adquisiciones, la solución existente de DynamoDB había causado preocupaciones tanto de rendimiento como de coste a escala. “Puede ser un poco caro a medida que se escala, para ser honesto”, explicó Joseph Shorter, vicepresidente de arquitectura de plataformas en Digital Turbine. “Estábamos haciendo una tonelada de lecturas – el 90% de todas las interacciones con DynamoDB eran operaciones de lectura. Con todas esas operaciones, encontramos que los éxitos de rendimiento nos obligaron a escalar más de lo que queríamos, lo que aumentó los costes”. La principal preocupación, según Shorter, era “Cómo podemos migrar sin refactorizar radicalmente nuestra plataforma, manteniendo al menos el mismo rendimiento y valor – y evitando una situación de colapso y quema? porque si fallaba, se derrumbaría toda nuestra empresa”. Después de evaluar varias opciones, Digital Turbine se trasladó a ScyllaDB y logró mejoras inmediatas.La migración tomó menos de un sprint para implementar y los resultados superaron las expectativas. “Una diferencia de costos del 20% es un gran número, no importa de qué se trate”, señaló Shorter. “Y cuando consideramos nuestros planes de escalar aún más, se vuelve aún más significativo”. Más allá de los ahorros de costes, se encontraron "apenas aprovechando los clústeres de ScyllaDB", lo que sugiere espacio para un crecimiento aún mayor sin aumentos proporcionales de costes. Seguir leyendo Turbina Digital Alta velocidad de escritura con baja latencia y menores costes El equipo de estado de usuario y personalización de uno de los servicios de streaming de medios más grandes del mundo había estado utilizando DynamoDB durante varios años. Mientras estaban rearquitectando dos casos de uso existentes, se preguntaron si era el momento de un cambio de base de datos. Pausa/Resume: Si un usuario está viendo un programa y lo pausa, puede recoger donde se ha dejado – en cualquier dispositivo, desde cualquier ubicación. Observación del estado: Usando los mismos datos, determinar si el usuario ha visto el programa. Aquí hay un diagrama de arquitectura simple: Cada 30 segundos, el cliente envía palpitaciones con la posición actualizada de la cabeza de juego del programa y luego envía esos eventos a la base de datos. El Pipeline Edge carga eventos en la misma región que el usuario, mientras que el Pipeline Authority (Auth) combina eventos para todas las cinco regiones que sirve la empresa. Finalmente, los datos deben ser recogidos y enviados de vuelta al cliente para apoyar la reproducción. Tenga en cuenta que el equipo quería preservar la separación entre las regiones Auth y Edge, por lo que no buscaban ninguna replicación específica de la base de datos entre ellas. Los dos principales requisitos técnicos para apoyar esta arquitectura fueron: Para garantizar una gran experiencia de usuario, el sistema tuvo que permanecer altamente disponible, con lecciones de baja latencia y la capacidad de escalar en función de los aumentos de tráfico. Para evitar la extensa configuración de la infraestructura o el trabajo de DBA, necesitaban una fácil integración con sus servicios de AWS. Una vez que esas cajas fueron revisadas, el equipo también esperaba reducir el coste general. “Nuestra infraestructura existente tenía datos distribuidos a través de varios clusters de DynamoDB y Elasticache, por lo que realmente queríamos algo simple que pudiera combinar estos en un sistema de coste mucho más bajo”, explicó su ingeniero de backend. En concreto, necesitaban una base de datos con: Soporte multiregión, ya que el servicio era popular en cinco regiones geográficas principales. Las actualizaciones no tenían un acuerdo de nivel de servicio estricto (SLA), pero el sistema necesitaba realizar actualizaciones condicionales basadas en los timestamps de eventos. La capacidad de manejar más de 78K de lecturas por segundo con una latencia de P99 de 10 a 20 milisegundos.El caso de uso incluía solo consultas de puntos simples; cosas como índices, particiones y patrones de consultas complicados no eran una preocupación primaria. Aproximadamente 10 TB de datos con espacio para el crecimiento. De acuerdo con su ingeniero de backend, “DynamoDB podría soportar nuestros requisitos técnicos perfectamente. pero dado nuestro tamaño de datos y alta (escribir pesado) capacidad, continuar con DynamoDB habría sido como echar dinero al fuego”. Basándose en sus requisitos para el rendimiento de escritura y el costo, decidieron explorar ScyllaDB. Para demostrar el concepto, configuraron un clúster de pruebas en la nube de ScyllaDB con seis nodos AWS i4i 4xlarge y precargaron el clúster con 3 mil millones de registros. Realizaron cargas combinadas de 170K de escritura por segundo y 78K de lectura por segundo. Estas bajas latencias, combinadas con importantes ahorros de costes (más del 50%) les convencieron a abandonar DynamoDB. Más allá de las latencias más bajas a un costo más bajo, el equipo también apreció los siguientes aspectos de ScyllaDB: El diseño centrado en el rendimiento de ScyllaDB (estando construido en el marco Seastar, utilizando C++, siendo NUMA-consciente, ofreciendo controladores no conscientes, etc.) ayuda al equipo a reducir el tiempo y los costes de mantenimiento. La estrategia de compactación incremental les ayuda a reducir significativamente la amplificación de escritura. El nivel de coherencia flexible y los factores de replicación les ayudan a soportar tuberías separadas de Auth y Edge. Por ejemplo, Auth utiliza la coherencia de quórum mientras que Edge utiliza un nivel de coherencia de "1" debido a la duplicación de datos y alta transmisión. Su ingeniero de backend concluyó: “Es difícil elegir una base de datos.Tienes que considerar no solo las características, sino también los costos. “En nuestro caso, debido a los altos requisitos de rendimiento y latencia, DynamoDB sin servidor no fue una gran opción.También, no subestimes el papel del hardware. Aprender más ¿Es su equipo el siguiente? Si el equipo está considerando , de para explorar. inscríbete para para hablar más sobre su caso de uso, los SLA, los requisitos técnicos y lo que está esperando optimizar. le informaremos si ScyllaDB es un buen ajuste y, en su caso, qué podría implicar una migración en términos de cambios en la aplicación, modelado de datos, infraestructura y así sucesivamente. Más información sobre DynamoDB ScyllaDB podría ser una opción Una consulta técnica Bonus: Aquí hay una rápida mirada a cómo ScyllaDB se compara con DynamoDB: Escrito por : de Guillermo de Silva Nogueira y Felipe Cardeneti Mendes . Escrito por Guillermo de Silva Nogueira Felipe Cardeneti Mendes
