Por qué Amazon DynamoDB no es para todos

Cómo decidir cuándo es adecuado para usted

Nota IMPORTANTE. Desde la publicación original de este artículo, AWS ha agregado varias características nuevas a DynamoDB, incluida la capacidad de adaptación , las copias de seguridad a pedido y la recuperación puntual . Si bien muchos puntos de este artículo siguen siendo válidos, algunos pueden estar desactualizados. Consulte la documentación más reciente de DynamoDB antes de tomar cualquier decisión sobre tecnología.

En 2004, el negocio de Amazon ya estaba extendiendo los límites de su infraestructura de base de datos Oracle. Con el fin de escalar el negocio en crecimiento, AWS diseñó una galardonada tienda interna de valores clave (Amazon Dynamo) para cumplir con sus requisitos de rendimiento, escalabilidad y confiabilidad.

Dynamo de Amazon
En dos semanas, presentaremos un documento sobre la tecnología Dynamo en SOSP, los prestigiosos sistemas operativos bianuales … www.allthingsdistributed.com

Amazon Dynamo ahora subyace en gran parte de Amazon.com y definió una categoría completamente nueva de bases de datos de tiendas clave-valor: "NoSQL". En 2012, AWS anunció la disponibilidad de DynamoDB como un servicio de datos NoSQL totalmente administrado para los clientes con la promesa de una escalabilidad perfecta.

¿Por qué usar DynamoDB?

Como Dynamo celebra su décimo aniversario , AWS debería considerar un servicio complementario llamado " WhynamoDB ". Cada vez que un desarrollador intenta aprovisionar una nueva tabla DynamoDB, el servicio aparece en AWS Console y simplemente pregunta: " ¿Por qué?"

La respuesta a " por qué usar DynamoDB " no es tan sencilla como la promesa de marketing de una escalabilidad perfecta.

En las últimas semanas, entrevisté a varios ingenieros y desarrolladores sobre sus experiencias con el servicio de la base de datos. Tan grande como DynamoDB es, y por muy emocionante que sean sus historias de éxito, también ha dejado muchas implementaciones fallidas a su paso.

Hay muy pocos casos de uso adecuados para DynamoDB | Hacker News
Fundamentalmente, el problema parece ser que elegir una clave de partición adecuada para el funcionamiento de DynamoDB news.ycombinator.com

Para comprender qué causa que algunas implementaciones de DynamoDB tengan éxito y otras fallen, debemos examinar la tensión esencial entre las dos grandes promesas de DynamoDB: simplicidad y escalabilidad.

DynamoDB es simple, hasta que no se escale

Realmente no puedo exagerar lo fácil que es comenzar a arrojar datos en DynamoDB. El equipo de AWS ha realizado un excelente trabajo al abstraer la complejidad: no tiene que iniciar sesión en un estudio de administración, no tiene que preocuparse por los controladores de la base de datos, no tiene que configurar un clúster.

Para comenzar con DynamoDB, simplemente gire la perilla de la capacidad de aprovisionamiento, tome su SDK favorito y comience a colgar JSON.

Con ese conjunto de características, no es de extrañar que DynamoDB sea especialmente atractivo para los desarrolladores de aplicaciones "sin servidor". Después de todo, muchas aplicaciones sin servidor comienzan como prototipos, priorizando la velocidad de entrega y la configuración mínima. ¿Por qué meterse con un almacén de datos relacional cuando ni siquiera sabes cómo será el modelo final de datos?

En este punto, necesitamos hacer una distinción clave, sin juego de palabras. DynamoDB puede ser simple para interactuar, pero una arquitectura respaldada por DynamoDB no es absolutamente fácil de diseñar.

DynamoDB es una tienda de valores clave. Funciona muy bien si está recuperando registros individuales basados ??en búsquedas de claves. Las consultas o escaneos complejos requieren una indexación cuidadosa y son complicados o directamente desaconsejables para escribir, incluso si no tiene una gran cantidad de datos, e incluso si está familiarizado con los principios de diseño de NoSQL.

Esa última parte es la que patea, por supuesto, hay una gran cantidad de desarrolladores que no saben mucho sobre NoSQL en comparación con el diseño de base de datos relacional clásico. Además, la experiencia previa en NoSQL no siempre es positiva neta. Hablé con algunos ingenieros cuyos equipos fueron quemados cuando trajeron un montón de expectativas de MongoDB, una base de datos de documentos, a su implementación de DynamoDB.

Entonces, cuando se combinan desarrolladores inexpertos, la falta de un plan claro sobre cómo modelar un conjunto de datos en DynamoDB, y un servicio de base de datos administrado que hace que sea muy fácil ingerir muchos datos no estructurados, puede terminar con una solución que se desvanece de control, incluso a pequeña escala.

Lynn Langit , una consultora de datos en la nube con experiencia en las tres grandes nubes públicas, ha visto suficientes de estas implementaciones fallidas como para justificar cautelosamente las empresas que confían en las soluciones NoSQL como DynamoDB.

Cuando entrevisté a Lynn recientemente para la serie "Superhéroes sin Servidor", compartió una historia sobre trasladar un cliente de DynamoDB a Aurora, el servicio de base de datos relacional local de AWS, aunque la arquitectura de referencia de AWS para su proyecto utilizó DynamoDB.

"El cliente estaba teniendo todo tipo de problemas, y un día decidí cambiar a Aurora. Asombró a todo el mundo – dijeron, '¿Qué estás haciendo?' Yo dije, '¿Qué estamos haciendo? Estamos enviando un producto. ' Y lo hicimos ".

La primera ley de DynamoDB
Suponga que una implementación de DynamoDB será más difícil, no más fácil, que usar una base de datos relacional que ya conoce.

Una base de datos relacional hará casi todo lo que necesite a pequeña escala. Puede que tome un poco más de tiempo configurarlo que DynamoDB, pero las convenciones bien establecidas de una implementación de SQL pueden protegerlo de un montón de tiempo perdido en el futuro.

Esto no se debe a que DynamoDB sea una tecnología peor, sino porque es nuevo para ti, y las cosas que parecen "fáciles" y "convenientes" te morderán de verdad si no las entiendes.

DynamoDB es escalable, hasta que no es simple

Ahora explora el otro extremo del espectro: grandes tablas DynamoDB. Para este artículo, entrevisté a clientes satisfechos que obtuvieron una latencia inferior a un segundo con miles de millones de registros en sus tablas DynamoDB. DynamoDB promete un rendimiento constante a una escala esencialmente infinita, limitado solo por el tamaño físico de la nube de AWS.

Sin excepción, estos clientes están en el centro del caso de uso canónico de DynamoDB: realizan búsquedas de valores clave en registros bien distribuidos, evitan consultas complejas y, lo que es más importante, limitan las teclas rápidas.

El manejo de las teclas de acceso rápido es, sin duda, el "gotcha" más conocido de DynamoDB. El problema con las teclas rápidas está bien explicado en muchos lugares, incluida la documentación de la guía del desarrollador de DynamoDB .

Mejores prácticas para tablas – Amazon DynamoDB
Utilice estas mejores prácticas para trabajar con elementos de tablas para obtener el mejor rendimiento con costos de rendimiento reducidos mediante … docs.aws.amazon.com

Aunque DynamoDB puede escalar indefinidamente, sus datos no se almacenan en un único servidor mágico que se expande constantemente. A medida que sus datos crecen más que la capacidad de un único fragmento de DynamoDB, o "partición" (hasta 10 GB), se divide en fragmentos, con cada fragmento que vive en una partición diferente.

Si tiene una clave "activa" en su conjunto de datos, un registro particular al que está accediendo con frecuencia, debe asegurarse de que la capacidad aprovisionada en su tabla sea lo suficientemente alta como para manejar todas esas consultas.

El "error" es que solo se puede aprovisionar la capacidad de DynamoDB al nivel de toda la tabla, no por partición, y la capacidad se divide entre las particiones utilizando una fórmula bastante endeble . Como resultado, su capacidad de lectura y escritura en cualquier registro dado es mucho menor que su capacidad de aprovisionamiento general.

Entonces, si su aplicación usa demasiadas RCU en una sola clave, debe aprovisionar en exceso todas las otras particiones (costosas), generar una tonelada de errores de "Rendimiento excedido" (no es lo ideal) o descubrir cómo disminuir el acceso a esa clave.

Un punto clave aquí es que DynamoDB no es necesariamente adecuado para los conjuntos de datos que tienen una combinación de registros de frío y calor. Pero a una escala lo suficientemente grande, cada conjunto de datos tiene esa mezcla. Podrías dividir los datos en diferentes tablas, por supuesto, pero si lo haces, habrás perdido la ventaja de escalabilidad que se suponía que DynamoDB debía proporcionar en primer lugar.

Hace poco se publicó un blog sobre este tema llamado "The Million Dollar Engineering Problem" . Mostró cómo Segment redujo sustancialmente su factura de AWS mediante la fijación del sobreaprovisionamiento de DynamoDB relacionado con las teclas de acceso directo. La parte más interesante de ese artículo son los gráficos de "mapa de calor" que muestran exactamente qué particiones fueron los alborotadores.

Un mapa de calor provisto por AWS de las particiones totales, junto con la presión clave en cada

Ahora, si lees la letra pequeña, esos gráficos geniales provienen de las herramientas internas de AWS, no de ningún control que Segment haya podido hacer por sí mismo. En otras palabras, alguien de Segment tuvo que hablar por teléfono con el equipo de DynamoDB para poder observar sus problemas en la base de datos.

Incluso en ese punto, su estrategia para bloquear las claves ofensivas era una cuestión de envolver las llamadas de DynamoDB en un try / catch – y ejecutar una lógica de rastreo personalizada si una clave en particular tropezaba con una excepción de rendimiento.

En efecto, Segment tuvo que luchar contra el problema de las teclas de acceso directo con una venda en los ojos, y aquí es donde volvemos a la tensión entre la simplicidad y la escala.

DynamoDB está diseñado como una caja negra con muy pocos controles accesibles para el usuario. Este enfoque lo hace fácil de usar cuando recién está comenzando. Pero a escala de producción, cuando los casos extremos determinan tu vida, a veces necesitas más información sobre por qué tus datos se están portando mal.

Necesitas un poco de complejidad compasiva.

La segunda ley de DynamoDB
A escala masiva, la usabilidad de DynamoDB está limitada por su propia simplicidad.

Esto no es un problema con la arquitectura de Dynamo. Es un problema con lo que AWS ha elegido exponer a través del servicio de DynamoDB .

En este punto, ni siquiera hemos tocado el tema de las copias de seguridad y las restauraciones, algo que DynamoDB no admite de forma nativa y que se torna tremendamente complicado a escala. La imposibilidad de hacer una copia de seguridad de 100TB de datos de DynamoDB fue aparentemente una gran razón por la cual Timehop ??recientemente se retiró del servicio por completo .

Si no es DynamoDB, ¿entonces qué?

Entonces, si DynamoDB es solo una de las muchas opciones plausibles a pequeña escala y tiene una viabilidad limitada como servicio a gran escala, ¿para qué sirve?

Si le preguntas a AWS, casi cualquier cosa. Después de todo, Werner Vogels dice que el diseño original de Dynamo podría manejar aproximadamente el 90% de las cargas de trabajo de Amazon.com.

Con la excepción de ciertos casos especiales como analíticas de BI o transacciones financieras, es cierto que puede rediseñar casi cualquier aplicación para sacar las relaciones comerciales de la base de datos, almacenar el estado en una tabla K / V y usar una arquitectura basada en eventos para el contenido de tu corazón

Pero como solía decir mi profesor de informática, también es cierto que "solo porque puedes, no significa que debas".

Si no comprende por completo por qué está utilizando DynamoDB desde el principio, es probable que termine como Ravelin haciendo girar sus ruedas a través de varias reescrituras de código hasta que finalmente aterrice en una solución que más o menos funciona, pero todavía odia. .

Probablemente no deberías usar DynamoDB
Los lectores ávidos de Ravelin syslog recordarán una historia del año pasado sobre nuestro uso de DynamoDB. Delineó algunos … syslog.ravelin.com

La tercera ley de DynamoDB
El valor del negocio supera el idealismo arquitectónico todo el tiempo.

Esta es la razón por la que Lynn Langit ha abandonado más o menos a NoSQL como una solución para las pequeñas y medianas empresas. Es por eso que Timehop ??se mudó de DynamoDB a Aurora, y por qué otra empresa conocida que entrevisté se mudó a "un clúster de ElasticSearch gigante".

También es la razón por la cual DynamoDB tiene montones de estudios de casos de clientes satisfechos en marcas famosas. No porque una de estas tecnologías sea uniformemente mejor que otra, sino porque los ingenieros de cada empresa, con sus casos de uso específico y niveles de experiencia, pudieron entregar valor comercial de la manera más rápida y efectiva con diferentes soluciones.

Presentamos Amazon WhynamoDB

En algún momento, Amazon puede anunciar el lanzamiento del servicio WhynamoDB que pregunta "por qué está aprovisionando una tabla DynamoDB". En preparación para el lanzamiento, he creado este práctico árbol de decisiones que lo guiará a través del servicio WhynamoDB .

¿Cuál es su experiencia y pensamientos sobre DynamoDB? ¡Me interesaría escuchar tus pensamientos en los comentarios a continuación!

Si disfrutaste este artículo, asegúrate de ver mis series de comics FaaS y Furious . Puedes seguir en Twitter donde estoy @ forrestbrazeal .