DynoTable
Avanzado7 min de lectura

Parallel scans en DynamoDB

Un parallel scan divide un Scan en N peticiones Scan independientes, cada una reclamando un Segment de la tabla, para que múltiples workers la lean a la vez. Es la única forma de leer una tabla entera más rápido de lo que permite el throughput de una sola partición.

¿Qué es un parallel scan en DynamoDB?

Un parallel scan de DynamoDB divide un Scan en N peticiones independientes, cada una reclamando un Segment de la tabla mediante Segment y TotalSegments, para que múltiples workers la lean de forma concurrente. Es la única forma de leer una tabla entera más rápido de lo que permite el throughput de una sola partición — pero sigue siendo una lectura completa, así que pagas por cada item escaneado.

  • Un Scan secuencial lee una partición a la vez — su velocidad está topada al throughput de una sola partición, por grande que sea la tabla.
  • Segment + TotalSegments fragmentan la lectura entre TotalSegments workers; cada worker escanea su propio trozo en paralelo.
  • DynamoDB hashea la clave de partición para asignar segmentos, así que los trozos pueden quedar desiguales — más workers no siempre significa más rápido.
  • Sigue siendo un Scan: pagas por leer cada item, y un parallel scan gordo puede drenar el throughput de la tabla por debajo de tu tráfico en vivo.

Por qué un Scan secuencial es lento

Viniendo de SQL, una lectura de tabla completa parece una operación de streaming única. En DynamoDB no lo es. Los datos de la tabla viven a lo largo de muchas particiones físicas, pero un solo Scan las recorre una a una, 1 MB por página.

Eso significa que un Scan plano solo puede tirar del presupuesto de throughput de una partición en un momento dado — aunque la tabla esté repartida en docenas de particiones con capacidad ociosa. Cuanto más grande la tabla, más lento se arrastra. (AWS: Parallel scan)

Divide la lectura con Segment y TotalSegments

Un parallel scan arregla el cuello de botella. Eliges un número de workers, fijas TotalSegments a ese número y das a cada worker un Segment distinto basado en cero. Cada worker lanza su propio Scan; DynamoDB los sirve de forma concurrente.

Worker 0 →  Scan  Segment=0  TotalSegments=4
Worker 1 →  Scan  Segment=1  TotalSegments=4
Worker 2 →  Scan  Segment=2  TotalSegments=4
Worker 3 →  Scan  Segment=3  TotalSegments=4

Cada worker sigue paginando con LastEvaluatedKey de forma independiente — posee su segmento desde la primera página hasta la última. La aplicación vuelve a coser los cuatro flujos. Ahora estás leyendo el throughput de cuatro particiones a la vez en lugar de una.

Un ejemplo trabajado: la exportación nocturna

Digamos que ejecutas una tabla de telemetría, sensor-readings. Cada item es una lectura de un dispositivo de campo:

PK = "DEVICE#a83f"          (partition key — the device id)
SK = "TS#2026-06-22T03:14"  (sort key — ISO timestamp)
batteryMv  = 3120
tempC      = 41.8
firmwareTag = "fw-7.2.1"

Cada noche un cron job vuelca la tabla entera a S3 para el almacén de analítica. Un Scan secuencial de 80 GB tarda horas y apenas roza tu capacidad de lectura provisionada. Así que lo despliegas en abanico sobre ocho workers:

Scan  sensor-readings  Segment=0  TotalSegments=8  ConsistentRead=false
…
Scan  sensor-readings  Segment=7  TotalSegments=8  ConsistentRead=false

Ocho workers, ocho segmentos, una lectura de tabla aproximadamente ocho veces más rápida. Si solo necesitas lecturas recientes, añade una FilterExpression para descartar timestamps viejos antes de que las filas lleguen al cable — construye e inspecciona esa expresión en el constructor de expresiones:

FilterExpression:  begins_with(SK, :today)

Cómo asigna DynamoDB los items a los segmentos

Aquí está la parte que confunde a la gente. DynamoDB asigna cada item a un segmento hasheando su clave de partición — no por conteo de filas, no por conteo de bytes.

Así que cada item que comparte una PK aterriza en el mismo segmento. En sensor-readings, todas las lecturas de DEVICE#a83f van a un worker, sin importar cuántos timestamps tenga ese dispositivo o cuán grande sea su colección de items. (AWS: Parallel scan)

tabla sensor-readingshashear clave de particiónSegmento 0DEVICE#a83fDEVICE#1c20Segmento 1DEVICE#9be4Segmento 2 (vacío)

La consecuencia: los segmentos quedan desiguales. Un worker podría poseer tres dispositivos parlanchines con millones de lecturas; otro podría sacar un trozo vacío. Subir TotalSegments más alto no ayudará si tus claves de partición se agrupan — solo añades workers ociosos esperando al caliente. Una distribución de claves uniforme es lo que hace que el despliegue en abanico rinda.

Ve el coste de lectura antes de ejecutarlo

Un parallel scan es un evento de throughput, no un almuerzo gratis. La pregunta honesta es "¿cuántas unidades de lectura costará leer toda esta tabla?" — y DynoTable te muestra el coste de lectura medido de un scan contra tu tabla real, segmento por segmento, para que el trabajo nocturno no te sorprenda en la factura.

Trampas y cuándo no molestarse

  • El precipicio de throughput. Un scan con TotalSegments alto puede consumir toda la capacidad de lectura de la tabla en segundos, dejando sin recursos al tráfico en vivo. En una tabla que sirve a usuarios, throttlea cada worker con el parámetro Limit o escanea fuera de las horas pico. (AWS: Parallel scan)
  • Sigue siendo la herramienta equivocada para un patrón de acceso. Los parallel scans son para trabajos deliberados de tabla completa — exportaciones, backfills, migraciones. Si recurres a uno para responder una query recurrente, eso es una señal de modelado: añade un GSI y conviértelo en una Query.
  • SELECT * en PartiQL es el mismo scan disfrazado. Compila a un Scan secuencial. Cuando realmente necesitas analítica entre items — un GROUP BY, un JOIN, un agregado — el SQL Workbench de DynoTable ejecuta esos en cliente sobre un conjunto de resultados acotado, en lugar de martillear la tabla.
  • La consistencia fuerte dobla la factura. Un Scan por defecto usa lecturas eventualmente consistentes. Para una exportación, deja ConsistentRead=false a menos que de verdad necesites un snapshot en un punto del tiempo.

Próximos pasos

Modela tus claves para que las lecturas del día a día nunca necesiten un scan — empieza con diseño de tabla única y Query vs Scan. Cuando un trabajo de tabla completa sea genuinamente la opción correcta, prueba DynoTable para ejecutar un parallel scan contra tus propias tablas y observar el coste de lectura en tiempo real.

Actualizado