Les parallel scans DynamoDB

Un parallel scan découpe un Scan en N requêtes Scan indépendantes, chacune réclamant un Segment de la table, pour que plusieurs workers la lisent en même temps. C'est le seul moyen de lire une table entière plus vite que le débit d'une seule partition ne le permet.

Qu'est-ce qu'un parallel scan DynamoDB ?

Un parallel scan DynamoDB découpe un Scan en N requêtes indépendantes, chacune réclamant un Segment de la table via Segment et TotalSegments, pour que plusieurs workers la lisent en parallèle. C'est le seul moyen de lire une table entière plus vite que le débit d'une seule partition ne le permet — mais c'est quand même une lecture complète, donc tu paies pour chaque item scanné.

Un Scan séquentiel lit une partition à la fois — sa vitesse est plafonnée au débit d'une seule partition, quelle que soit la taille de la table.
Segment + TotalSegments shardent la lecture entre TotalSegments workers ; chaque worker parcourt sa propre tranche en parallèle.
DynamoDB hache la clé de partition pour assigner les segments, donc les tranches peuvent être déséquilibrées — plus de workers ne signifie pas toujours plus rapide.
C'est quand même un Scan : tu paies pour lire chaque item, et un gros parallel scan peut vider le débit de la table sous le nez de ton trafic en direct.

Pourquoi un Scan séquentiel est lent

En venant de SQL, une lecture de table complète ressemble à une seule opération en streaming. Dans DynamoDB ce n'est pas le cas. Les données de la table vivent à travers de nombreuses partitions physiques, mais un seul Scan les parcourt une à la fois, 1 Mo par page.

Cela signifie qu'un Scan simple ne peut jamais puiser que dans le budget de débit d'une seule partition à un instant donné — même si la table est répartie sur des dizaines de partitions avec de la capacité inutilisée. Plus la table est grosse, plus il rampe longtemps. (AWS : Parallel scan)

Découper la lecture avec Segment et TotalSegments

Un parallel scan corrige le goulot d'étranglement. Tu choisis un nombre de workers, tu fixes TotalSegments à ce nombre et tu donnes à chaque worker un Segment distinct indexé à partir de zéro. Chaque worker émet son propre Scan ; DynamoDB les sert en concurrence.

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

Chaque worker pagine encore avec LastEvaluatedKey indépendamment — il possède son segment de la première page à la dernière. L'application recoud les quatre flux ensemble. Tu lis maintenant le débit de quatre partitions à la fois au lieu d'une.

Un exemple concret : l'export nocturne

Disons que tu exploites une table de télémétrie, sensor-readings. Chaque item est une mesure d'un appareil de terrain :

PK = "DEVICE#a83f"          (clé de partition — l'id de l'appareil)
SK = "TS#2026-06-22T03:14"  (clé de tri — timestamp ISO)
batteryMv  = 3120
tempC      = 41.8
firmwareTag = "fw-7.2.1"

Chaque nuit, un cron job déverse la table entière vers S3 pour l'entrepôt analytique. Un Scan séquentiel de 80 Go prend des heures et entame à peine ta capacité de lecture provisionnée. Donc tu l'éclates sur huit workers :

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

Huit workers, huit segments, une lecture de table à peu près huit fois plus rapide. Si tu n'as besoin que des mesures récentes, ajoute une FilterExpression pour écarter les vieux timestamps avant que les lignes ne passent sur le réseau — construis et inspecte cette expression dans le constructeur d'expressions :

FilterExpression:  begins_with(SK, :today)

Comment DynamoDB assigne les items aux segments

Voici la partie qui fait trébucher les gens. DynamoDB assigne chaque item à un segment en hachant sa clé de partition — pas par nombre de lignes, pas par nombre d'octets.

Donc chaque item partageant un PK atterrit dans le même segment. Dans sensor-readings, toutes les mesures de DEVICE#a83f vont à un seul worker, quel que soit le nombre de timestamps de cet appareil ou la taille de sa collection d'items. (AWS : Parallel scan)

La conséquence : les segments sont inégaux. Un worker peut posséder trois appareils bavards avec des millions de mesures ; un autre peut tirer une tranche vide. Pousser TotalSegments plus haut n'aidera pas si tes clés de partition se regroupent — tu ajoutes juste des workers inactifs qui attendent le worker chaud. Une distribution de clés homogène est ce qui rend l'éclatement payant.

Voir le coût de lecture avant de lancer

Un parallel scan est un événement de débit, pas un repas gratuit. La vraie question est « combien d'unités de lecture coûtera la lecture de toute cette table ? » — et DynoTable te montre le coût de lecture mesuré d'un scan contre ta vraie table, segment par segment, pour que le job nocturne ne te surprenne pas sur la facture.

Pièges et quand ne pas s'embêter

La falaise de débit. Un scan à TotalSegments élevé peut consommer toute la capacité de lecture de la table en quelques secondes, affamant le trafic en direct. Sur une table qui sert des utilisateurs, throttle chaque worker avec le paramètre Limit ou scanne en heures creuses. (AWS : Parallel scan)
C'est quand même le mauvais outil pour un access pattern. Les parallel scans sont pour des jobs de table complète délibérés — exports, backfills, migrations. Si tu en attrapes un pour répondre à une requête récurrente, c'est un signal de modélisation : ajoute un GSI et fais-en un Query à la place.
SELECT * en PartiQL est le même scan déguisé. Il compile en un Scan séquentiel. Quand tu as réellement besoin d'analytique inter-items — un GROUP BY, un JOIN, un agrégat — le SQL Workbench de DynoTable exécute ça côté client sur un ensemble de résultats borné, au lieu de marteler la table.
La cohérence forte double la facture. Un Scan est par défaut en cohérence à terme. Pour un export, laisse ConsistentRead=false à moins d'avoir vraiment besoin d'un instantané à un point dans le temps.

Étapes suivantes

Modélise tes clés pour que les lectures quotidiennes n'aient jamais besoin d'un scan — commence par le single-table design et Query vs Scan. Quand un job de table complète est vraiment le bon choix, essaie DynoTable pour lancer un parallel scan contre tes propres tables et regarder le coût de lecture en temps réel.