Confiabilidad de los contadores atómicos en DynamodB

Question

Estaba considerando usar Amazon Dynamodb en mi aplicación, y tengo una pregunta sobre su contadores atómicos fiabilidad.

Estoy construyendo una aplicación distribuida que necesita simultáneamente, y consecuentemente, incremento/disminución Un contador almacenado en el atributo de una dinamo. Me preguntaba qué tan confiable es el mostrador atómico de la dinamo en un entorno concurrente pesado, donde el nivel de concurrencia es extremadamente alto (digamos, por ejemplo, una tasa promedio de 20k golpes concurrentes, para obtener la idea, eso sería casi 52 mil millones de incrementos /disminución por mes).

El mostrador debe ser súper confiable y nunca Extraño un éxito. ¿Alguien ha probado DynamodB en entornos tan críticos?

Gracias

Answer 1

DynamoDB obtiene sus propiedades de escala dividiendo las teclas en múltiples servidores. Esto es similar a cómo otras bases de datos distribuidas como la escala Cassandra y HBase. Si bien puede aumentar el rendimiento en DynamoDB que solo mueve sus datos a múltiples servidores y ahora cada servidor puede manejar conexiones / número concurrentes totales de servidores. Echar un vistazo en sus preguntas frecuentes Para una explicación sobre cómo lograr el rendimiento máximo:

P: ¿Siempre podré alcanzar mi nivel de rendimiento aprovisionado?

Amazon DynamoDB asume un patrón de acceso relativamente aleatorio en todas las claves primarias. Debe configurar su modelo de datos para que sus solicitudes dan como resultado una distribución bastante uniforme del tráfico en las claves primarias. Si tiene un patrón de acceso altamente desigual o sesgado, es posible que no pueda lograr su nivel de rendimiento aprovisionado.

Al almacenar datos, Amazon DynamoDB divide una tabla en múltiples particiones y distribuye los datos en función del elemento de clave hash de la clave primaria. El rendimiento aprovisionado asociado con una tabla también se divide entre las particiones; El rendimiento de cada partición se gestiona de forma independiente en función de la cuota que se le asigna. No hay compartir el rendimiento aprovisionado en las particiones. En consecuencia, una tabla en Amazon DynamodB puede cumplir mejor los niveles de rendimiento aprovisionados si la carga de trabajo se extiende de manera bastante uniforme a través de los valores clave del hash. La distribución de solicitudes en valores clave hash distribuye las solicitudes entre particiones, lo que ayuda a lograr su nivel de rendimiento aprovisionado por completo.

Si tiene un patrón de carga de trabajo desigual en las claves primarias y no puede lograr su nivel de rendimiento aprovisionado, puede satisfacer sus necesidades de rendimiento aumentando su nivel de rendimiento aprovisionado aún más, lo que dará más rendimiento a cada partición. Sin embargo, se recomienda que considere modificar su patrón de solicitud o su modelo de datos para lograr un patrón de acceso relativamente aleatorio en las claves primarias.

Esto significa que tener una clave que se incrementa directamente no se escalará ya que esa clave debe vivir en un servidor. Hay otras formas de manejar este problema, por ejemplo, en la agregación de memoria con un incremento de descarga a DynamodB (aunque esto puede tener problemas de confiabilidad) o un contador de fragmentos donde los incrementos se extienden sobre múltiples claves y leída tirando de todas las teclas en los fragmentos. encimera (http://whynosql.com/scaling-distributed-counters/).

Answer 2

Además de la respuesta de GIGQ sobre la escalabilidad, los incrementos atómicos de Dynamodbs no son ideampotentes y, por lo tanto, no son confiables: si la conexión cae después de emitir un UpdateItem ADD Solicite, no tiene forma de saber si el ADD se comprometió o no, por lo que no sabe si debe volver a intentarlo o no.

Las actualizaciones condicionales de DYNAMODB solucionan esto, a costa de hacer que el sistema sea aún menos escalable, porque debe volver a intentar cada vez que se intentan dos cambios en el atributo simultáneamente, incluso en ausencia de un error.

Answer 3

Si vas a escribir una sola clave Dynamo DB, sufrirás de partición caliente tema. El problema de la partición caliente comienza alrededor de 300 tps por índice. Entonces, si tiene 5 índices en la tabla, puede ver un problema de partición caliente alrededor de 300/5 ~ 60 tps.

De lo contrario, Dynamo DB es escalable a aproximadamente 10-40k TPS, dependiendo de su caso de uso.