Cuándo usar DynamoDB (y cuándo no)

DynamoDB es una base de datos fantástica para las cargas de trabajo para las que está diseñada y es frustrante. uno para el resto. La pregunta decisiva es "¿Lo sé?" mis patrones de acceso desde el principio, ¿están basados en claves?"** Hazlo bien y DynamoDB le brinda lecturas de un solo dígito en milisegundos en cualquier escala; hazlo mal y pelearás la falta de uniones y consultas ad hoc para siempre.

¿Cuándo debo usar DynamoDB?

Utilice DynamoDB cuando sus patrones de acceso sean conocidos, estén basados en claves y sean de gran volumen, y Quiere una latencia predecible de un solo dígito de milisegundos a cualquier escala sin servidores para gestionar. Evítelo para consultas ad hoc, uniones enriquecidas o análisis de conjuntos de datos completos, y cuando los datos son pequeños con query formas que siguen cambiando.

• Utilice DynamoDB cuando sus patrones de acceso sean conocidos, estén basados en claves y sean de gran volumen. y desea una latencia predecible a cualquier escala sin servidores que administrar.
• Evítelo cuando necesite consultas ad hoc, uniones enriquecidas o análisis en general conjunto de datos, o cuando los datos son pequeños y las query formas siguen cambiando.
• El oficio principal: DynamoDB le permite diseñar sus consultas desde el principio; a cambio nunca se detiene a medida que creces.
• No es una base de datos relacional con una sintaxis diferente: modelarla como tal. la fuente número uno de dolor.

Las señales que favorecen DynamoDB

DynamoDB brilla cuando la mayoría de estos se cumplen:

• Conoce sus patrones de acceso de antemano. Puede enumerar las consultas exactas de la aplicación hace ("obtener un usuario por identificación", "enumerar primero los pedidos más recientes de un usuario") y no cambian por capricho. DynamoDB se modela alrededor de esas consultas.
• El acceso se basa en claves. Los elementos se buscan mediante una clave de partición conocida, no mediante scanning. para combinaciones arbitrarias de atributos.
• La escala y la latencia predecible son importantes. DynamoDB ofrece consistente un solo dígito-milisegundo rendimiento ya sea que la mesa contenga mil elementos o mil millones.
• Quiere cero gastos operativos. Sin instancias, sin conmutación por error, sin aspiración. está completamente administrado y escala a cero bajo demanda.
• El rendimiento de escritura es alto y rápido. Registros de eventos, telemetría de IoT, sesión/carro state, leaderboards: cargas de trabajo pesadas con una clave clara.

Las señales en contra

Busque una base de datos relacional (o un motor de búsqueda/análisis) cuando:

• Sus consultas son ad hoc. Los analistas dividen los datos en columnas arbitrarias, o Los requisitos cambian semanalmente. La flexibilidad de SQL gana; DynamoDB necesitaría un nuevo índice por patrón.
• Necesita uniones y agregaciones reales en todo el conjunto de datos. Informes, inteligencia empresarial, "suma de ingresos por región por mes": eso es OLAP/relacional trabajo. (La pregunta única contra una mesa en vivo es un caso diferente: DynoTable SQL Workbench ejecuta JOIN, GROUP BY, y agregados de más de DynamoDB clilado; es la carga de trabajo permanente de BI la que pertenece a otra parte.)
• El conjunto de datos es pequeño y tiene poco tráfico. Unos pocos miles de filas en una aplicación de administración silenciosa no obtiene ningún beneficio de la escala de DynamoDB y pierde la conveniencia de SQL.
• Aún no se pueden predecir los patrones de acceso. El producto en etapa inicial aún encuentra su lugar forma? Un schema relacional que puedes re-query libremente es más indulgente hasta que el selección de patrones.

Cómo se compara DynamoDB con otras bases de datos

"¿Debería usar DynamoDB o X?" Suele ser la misma pregunta con diferente ropa: ¿X? déjame posponer la decisión del patrón de acceso, ¿y cuánto pago por eso? DynamoDB es la opción que se niega a dejarte posponerlo. Cada comparación a continuación enciende esa comercio, no en listas de verificación de características.

Relacional: PostgreSQL, RDS y Aurora

Esta es la verdadera bifurcación y en la que la mayoría de los equipos se equivocan. Una base de datos relacional le permite escribe el query después de que tengas los datos. DynamoDB no: la mesa tiene forma de consultas antes de escribir un solo elemento.

Elija relacional cuando las query formas todavía se estén moviendo, cuando necesite uniones o agregados en todo el conjunto de datos, o cuando los datos son lo suficientemente pequeños como para que la escala no sea el problema que tienes. Elija DynamoDB cuando los patrones estén configurados y basados en claves y Quiero que cuesten lo mismo mil millones de artículos que mil.

RDS y Aurora no cambian ese cálculo: son motores relacionales administrados, por lo que heredan la flexibilidad de SQL y su modelo de escala. Lo que cambian es el funcionamiento. comparación: con Aurora Serverless, el argumento "no hay servidores para administrar" para DynamoDB se vuelve mucho más débil y la decisión recae claramente en los patrones de acceso. Escamas de aurora calcular; DynamoDB elimina el concepto.

Documento: MongoDB y DocumentDB

Ambos almacenan JSON documentos similares, por lo que parecen intercambiables con DynamoDB desde la distancia. No lo son. MongoDB indexa cualquier campo y ejecuta consultas ad hoc en él; DynamoDB da usted la clave de partición, la clave de clasificación y los índices que declaró de antemano.

Eso hace que MongoDB sea la mejor opción para evolucionar query formas, y DynamoDB la mejor opción para los conocidos en gran volumen. DocumentDB se encuentra en el lado AWS de la misma línea: habla el MongoDB API, así que trátelo como "la flexibilidad de MongoDB, el modelo operativo de AWS", y compárelo con DynamoDB exactamente en el eje de flexibilidad versus previsibilidad anterior.

Columna ancha: Cassandra

Cassandra es la pariente arquitectónica más cercana de DynamoDB: clave de partición, agrupación clave, y la misma dura verdad de que una clave de partición incorrecta es un error de diseño que no se puede indexar tu salida. Si elige entre ellos, los factores decisivos rara vez son los modelo de datos: ellos son quienes lo ejecutan y cómo usted paga. Cassandra usted opera (o compra gestionada); DynamoDB consumes. Amazon Keyspaces es el término medio administrado por Cassandra.

Debido a que los modelos están tan cerca, la guía de modelado en este sitio transfiere principalmente: diseño de tabla única razonamiento sobre claves de partición y los patrones de acceso se aplican a Cassandra casi línea por línea.

En memoria: Redis

Redis y DynamoDB resuelven diferentes problemas. Redis prioriza la memoria y está optimizado para un acceso en menos de un milisegundo. datos que puede permitirse el lujo de perder o reconstruir; DynamoDB es duradero de forma predeterminada. lo común La respuesta de producción es tanto: DynamoDB como el sistema de registro, Redis (o DAX, que es DynamoDB el propio caché de lectura) delante de las teclas de acceso rápido.

Utilice Redis únicamente cuando los datos sean genuinamente efímeros: contadores de límite de velocidad, sesiones de corta duración, leaderboards puedes volver a calcular.

Búsqueda: Elasticsearch y OpenSearch

Busque y DynamoDB también resuelven diferentes problemas, por una razón más clara que Redis: DynamoDB no tiene texto completo buscar en absoluto. Query coincidencias en igualdad de claves y un conjunto limitado de condiciones de clave de clasificación. Scan con un FilterExpression lee cada elemento y luego descartards la mayoría de ellos; es un paseo por la mesa con un filtro incorporado, no una búsqueda, y usted paga por los elementos leídos en lugar de los artículos devueltos. No hay clasificación de relevancia, ni analizadores, ni coincidencias difusas, ni facetado.

Entonces la pregunta nunca es "DynamoDB o un motor de búsqueda". ¿Esta carga de trabajo necesita búsqueda y, de ser así, ¿qué alimenta el índice?" La forma estándar es tanto: DynamoDB como el sistema de registro, un grupo de búsqueda sologsi lo define y DynamoDB Streams lleva cada cambio al índice. Eso compra una búsqueda real y le cuesta un segundo sistema para ejecutar y un índice que es eventualmente consistente con la tabla.

OpenSearch y Elasticsearch toman la misma decisión. OpenSearch es la bifurcación de AWS Elasticsearch, dividido en 7.10 en 2021 por el cambio de licencia de Elastic, y los dos se han desviado aparte desde entonces. Nada de esa deriva toca esta pregunta: "¿debería la búsqueda vivir fuera de DynamoDB", se comportan de manera idéntica. Elija entre ellos en materia de licencias, alojamiento y cuál servicio administrado que desea operar, no en nada que ver con DynamoDB.

Utilice un motor de búsqueda como tienda principal solo cuando la búsqueda realmente sea el producto. log Analytics, un catálogo cuyo principal patrón de acceso es el texto libre. Incluso entonces, la mayoría de los equipos mantienen un almacén duradero detrás de él, debido a que un índice de búsqueda es una vista derivada que necesita para poder reconstruir.

El eje de costes, que oculta la comparación de modelos.

Todas las comparaciones anteriores se refieren a modelos de datos, pero la sorpresa en la factura suele ser estructural: los motores relacionales facturan por la capacidad que usted aprovisiona, DynamoDB factura por operaciones que realiza. Eso hace que DynamoDB sea barato para cargas de trabajo puntiagudas e inactivas y caro para un scanning sostenido: la misma carga de trabajo puede ganar en un motor y perder mucho por el otro sin cambio de código entre ellos.

El multiplicador que la gente pasa por alto son los índices. En un motor relacional, un índice adicional cuesta almacenamiento y algunos escriben latencia; el DynamoDB cada índice secundario es una escritura adicional completa del atributos proyectados. Trabajamos la aritmética en tres volúmenes escritos en la guía de índices — uno GSI duplica la factura de escritura, dos el triple eso. Modele su mezcla real de lectura/escritura en el calculadora de precios antes de comprometerse con cualquiera de las partes.

Contando el costo antes de comprometerse

DynamoDB el precio sigue las lecturas, escrituras y el almacenamiento, no las horas de instancia, por lo que es Es barato para cargas de trabajo exigentes y sin servidor y puede resultar costoso para scans pesados y sostenidos. Modele su mezcla real de lectura/escritura con el DynamoDB calculadora de precios antes de comprometerse; una carga de trabajo que técnicamente parece adecuada también debería tener en cuenta el costo.

Una vez que hayas decidido que encaja

El trabajo pasa al modelaje. DynamoDB rewards diseñando la tabla alrededor de sus consultas — consulte cómo modelar datos en DynamoDB y diseño de mesa única — y explícitamente cuando no alcanzar la mesa única.

Escollos + próximos pasos

• No modele DynamoDB como una base de datos relacional: tablas normalizadas en las que se une El tiempo de lectura es el antipatrón que castiga con más dureza.
• No lo elijas para análisis: combínalo con una tienda de análisis (o exporta a una) para informar en lugar de scanfinar.
• ¿No estás seguro de los patrones de acceso? Espera. Adoptar DynamoDB antes de conocer tu consultas es elegir la base de datos que exige que usted las conozca.
• Relacionado: query vs scan muestra qué es el "acceso basado en claves" realmente te compra.

¿Quieres explorar una mesa de DynamoDB antes de apostar tu aplicación en ella? Descarga DynoTable y conéctate a tus datos directamente: es SQL Workbench ejecuta los JOINs ad-hoc y los agregados DynamoDB por sí solo no lo hará.