Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

220
Views
¿DynamoDB es adecuado para aplicaciones de transacciones altas?

Estoy escribiendo una aplicación de agregación de probabilidades de carreras de caballos que obtendrá datos del sitio web de casas de apuestas de diferencia. Para empezar, obtendré datos de 3 sitios web (puede subir a más de 10 más tarde) cada 10 segundos. Entonces, en el caso de 3 sitios web, habrá alrededor de 10,000 registros (corredores) cada día y cada registro podría leerse 3 veces cada 10 segundos y actualizarse si hay cambios en las probabilidades.

  1. ¿DynamoDB es adecuado para ese tipo de aplicación o debo ceñirme a RDBMS?
  2. ¿Habrá algún problema de consistencia con DyanmoDB cuando actualice las probabilidades (de diferentes sitios web) para el mismo corredor (registro) simultáneamente?
  3. La aplicación puede convertirse en otros deportes y carreras y obtener datos de más sitios web, ¿eso incurrirá en un costo enorme con DyamoDB ya que hará más lectura y escritura?

ACTUALIZACIÓN - 21/07/2020 9:30 a. m. La estructura del registro será similar a la siguiente. Habrá algunos servicios programados en ejecución y cada servicio se encargará de un corredor de apuestas. Hay posibilidades de que los servicios lean un registro y lo actualicen simultáneamente. El valor de la columna calculada se basará en el valor de la columna Bookies. Por lo tanto, quiero poder leer el valor más reciente de la columna Bookies de manera consistente.

 RUNNER EVENTID BOOKIE1 BOOKIE2 BOOKIE3 BOOKIE... CALCULATED Runner 1 12345 Odds1 Odds2 Odds3 Odds... Value Runner 2 67890 Odds1 Odds2 Odds3 Odds... Value

ACTUALIZACIÓN - 21/07/2020 12:20 p. m.

Después de actualizar mi publicación, aparecen algunos números en mi cabeza y DynamoDB parece ser muy costoso. Aquí están mis números, por favor hágamelo saber si algo es incorrecto.

Suposiciones:

  1. 10.000 corredor
  2. Cada 10 segundos durante un mes aproximadamente se redondean a 270 000 llamadas
  3. 3 casas de apuestas
  4. Suponiendo que cada registro/elemento tenga menos de 4 KB.
  5. Una RCU puede leer 5,2 millones de lecturas por mes (se encuentra en alguna parte)
  6. Una WCU puede leer 2,5 millones de lecturas al mes

RCU Requerido por mes: (3 * 1,0000 * 270,000)/5.2 mill = 1558 RCU

WCU requerido por mes: (3 * 1,0000 * 270,000)/2.5 mill = 3240 WCU

over 4 years ago · Santiago Trujillo
3 answers
Answer question

0

DynamoDB está diseñado para el rendimiento y la escalabilidad (específicamente para lecturas de destino), tiene soporte para transacciones .

De hecho, mientras que una base de datos relacional utiliza el modelo ACID , DynamoDB como clave-valor NoSQL utiliza el modelo BASE. Esto intercambia características como la consistencia (que garantiza que una transacción se haya escrito en el disco antes de responder con éxito) por la capacidad de tener un rendimiento de vanguardia.

Definitivamente podría usar DynamoDB, pero debe tener en cuenta las limitaciones, por ejemplo, no debe intentar varias actualizaciones en el mismo elemento al mismo tiempo. Usted menciona que está haciendo esto una vez cada 10 segundos, por lo que un proceso podría agregar los cambios y luego aplicarlos.

Si le interesan los datos en tiempo real, deberá usar una lectura fuerte y consistente para asegurarse de que está leyendo los datos más precisos.

Puede reducir parte de su costo de consistencia de lectura a través de DAX , la capa de almacenamiento en caché integrada que se encuentra frente a DynamoDB.

Además, si tiene periodos de bajo uso, DynamoDB proporciona escalado automático incorporado, lo que puede reducir la capacidad que paga (lecturas y escrituras) cuando está más tranquilo.

Aparte de esto, si desea rendimiento mientras mantiene escrituras transaccionales, Redis es un almacén de datos en memoria que admite transacciones . Existe una versión administrada por AWS con ElastiCache .

Por supuesto, también existe la opción Base de datos relacional, aunque esto permitirá escrituras transaccionales, deberá considerar el rendimiento de lectura (ya sea a través de un caché o mediante la funcionalidad de solo lectura ).

En última instancia, la elección depende de usted, cada una de estas opciones tiene limitaciones, pero se reduce a cómo espera usarlas. Es probable que DynamoDB sea la opción más económica, pero debe considerar la arquitectura para su demanda esperada.

over 4 years ago · Santiago Trujillo Report

0

DynamoDB es absolutamente capaz de mantenerse al día con este tipo de carga y mucho más. En ese sentido, no te preocupes por DynamoDB

Para mantener la coherencia, DynamoDB tiene la capacidad de realizar lecturas muy coherentes . Además, para que sepa cómo funcionan las escrituras, DynamoDB reconoce las escrituras solo una vez que llega a al menos dos de los tres nodos de almacenamiento para esa partición. Uno de esos dos debe ser el nodo líder para esa partición. Las lecturas muy consistentes siempre provienen del nodo líder.

En cuanto al costo, depende de muchos factores y sin saber más sobre su carga de trabajo y cómo crecerá, dudo en adivinar. Si desea verlo, puede pagar sobre la marcha con el modo de capacidad bajo demanda en la(s) mesa(s) y solo paga exactamente por lo que usa.

over 4 years ago · Santiago Trujillo Report

0

La recomendación para una alta escalabilidad para este tipo de situación con DynamoDb es DAX ( https://aws.amazon.com/en/dynamodb/dax/ ), que hace que Dynamo sea adecuado.

Acerca de la consistencia, dependerá de su modelo de datos, pero Dynamo con DAX maneja esto bien, aquí hay un enlace de recomendaciones de consistencia para DAX + Dynamo: https://docs.aws.amazon.com/amazondynamodb /latest/developerguide/DAX.consistencia.html

Y por último, sí, todos los servicios que usas en cualquier proveedor de Cloud tienen una cuota o tarifa de E/S, por lo que cuando la aplicación crezca el precio lo hará.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!