DynamoDB vs Redshift

DynamoDB et Amazon Redshift sont rarement des alternatives. DynamoDB est une base de données opérationnelle — des lectures et des écritures de l'ordre de la milliseconde sur des clés connues, au service du trafic applicatif en direct. Redshift est « un service d'entrepôt de données entièrement managé, à l'échelle du pétaoctet, dans le cloud », conçu pour parcourir et agréger de grands jeux de données à des fins de reporting et d'analytique. Les équipes qui font tourner les deux sont le cas normal, et AWS propose une intégration managée pour déplacer les données dans un sens entre eux.

Faut-il utiliser DynamoDB ou Redshift ?

Utilise DynamoDB pour les données vivantes de l'application : les commandes en cours de passage, les sessions lues, les enregistrements récupérés par clé. Utilise Redshift quand quelqu'un a besoin de poser des questions sur l'ensemble du jeu de données — le chiffre d'affaires par région et par mois, la rétention par cohorte, un tableau de bord joignant plusieurs sources. La question « lequel des deux » se résout généralement en « DynamoDB pour le chemin d'écriture, Redshift pour les analystes », avec l'intégration zéro-ETL au milieu.

DynamoDB vs Redshift en un coup d'œil

Caractéristique	DynamoDB	Redshift
Charge de travail	Opérationnelle (de type OLTP) — lectures et écritures par clé à haut volume	Analytique — parcours et agrégations sur de grands jeux de données
Modèle de données	Éléments NoSQL sans schéma jusqu'à 400 Ko ; les attributs varient d'un élément à l'autre	Tables relationnelles avec colonnes déclarées, clés de distribution et clés de tri
Langage de requête	API native (`GetItem`, `Query`, `Scan`, …) plus PartiQL	SQL complet, avec l'outillage BI et SQL que cela implique
Jointures et agrégats	Aucune jointure côté serveur ; l'agrégation n'est pas une opération côté serveur	Jointures, fonctions de fenêtrage, `GROUP BY` et le reste du SQL analytique
Pattern d'accès	Conçu autour de clés connues ; les parcours sont l'exception coûteuse	Conçu pour parcourir — lire beaucoup de lignes est le cas normal
Latence	De l'ordre de la milliseconde par requête	De quelques secondes à quelques minutes par requête analytique, sur bien plus de données
Montée en charge	Serverless ; partitions gérées par AWS	Workgroups serverless ou clusters provisionnés ; capacité dimensionnée selon la charge de requêtes
Fraîcheur	Lecture de ses propres écritures à la demande	Aussi fraîche que ce qui l'alimente — l'intégration zéro-ETL dépose les mises à jour toutes les 15 à 30 minutes
Modèle tarifaire	À la requête ou capacité provisionnée, plus le stockage	Capacité de calcul plus stockage ; les entrepôts serverless inactifs ne sont pas facturés au calcul

Quand DynamoDB est le meilleur choix

Le trafic applicatif en direct. Des lectures et écritures prévisibles de l'ordre de la milliseconde sur des clés connues, à n'importe quel débit de requêtes.
Un schéma qui varie d'un élément à l'autre. Des éléments hétérogènes dans une seule table sont la norme dans DynamoDB ; un entrepôt veut des colonnes déclarées.
Des opérations serverless. Aucun cluster à dimensionner, à patcher ni à mettre en pause.
Les chemins à écriture intensive. DynamoDB absorbe des écritures à haut volume : c'est son métier premier ; un entrepôt est optimisé pour le chargement en masse et la lecture.

Quand Redshift est le meilleur choix

Les questions qui traversent toute la table. Agréger une année de commandes est un parcours par nature, c'est-à-dire exactement le pattern d'accès que DynamoDB te demande d'éviter et pour lequel Redshift est conçu.
Les jointures entre de nombreuses sources. Les entrepôts joignent. DynamoDB n'a pas de jointure côté serveur.
L'outillage BI. Redshift parle SQL via JDBC/ODBC : il s'insère donc dans les tableaux de bord existants et dans « les mêmes outils SQL et applications de business intelligence que ceux que tu utilises aujourd'hui ».
Une analyse qui ne doit pas perturber la production. Faire tourner l'analytique sur une copie répliquée épargne la charge à la table qui sert tes utilisateurs.

Les utiliser ensemble

Le pattern standard est unidirectionnel : DynamoDB sert l'application, une copie atterrit dans Redshift, les analystes travaillent sur la copie. AWS propose deux voies — l'ancienne commande COPY, qui charge directement « depuis Amazon S3 ou Amazon DynamoDB vers Amazon Redshift », et l'intégration zéro-ETL managée, qui maintient la copie à jour toute seule.

Ce que fait réellement l'intégration zéro-ETL

« Zéro-ETL » évoque une vue en direct. Ce n'en est pas une, et les détails comptent avant de concevoir un tableau de bord autour.

C'est un pipeline de réplication déclenché par une minuterie. AWS est précis : « À l'activation, l'intégration exporte l'intégralité de la table DynamoDB pour peupler la base de données Amazon Redshift. » Ensuite, « l'intégration zéro-ETL réplique alors de façon incrémentale les mises à jour de DynamoDB vers Amazon Redshift toutes les 15 à 30 minutes, à l'aide des exports incrémentaux DynamoDB ». Les données dans Redshift ont donc jusqu'à une demi-heure de retard. C'est très bien pour du reporting quotidien et faux pour tout ce qu'un utilisateur est censé voir refléter sa dernière action.

La récupération à un instant précis est obligatoire — et la raison saute maintenant aux yeux. Le prérequis est énoncé sans détour : « Une intégration zéro-ETL entre Amazon DynamoDB et Amazon Redshift exige que la table DynamoDB source ait la récupération à un instant précis (PITR) activée. » AWS documente l'exigence à un endroit et le mécanisme à un autre, sans jamais les relier, mais la politique basée sur les ressources que tu dois attacher vend la mèche — elle accorde à redshift.amazonaws.com l'action dynamodb:ExportTableToPointInTime. L'intégration est bâtie sur la machinerie d'export vers S3 de DynamoDB, et cette machinerie lit la sauvegarde continue. Pas de PITR, pas d'export, pas d'intégration.

Cela a une conséquence budgétaire que l'on découvre tard : activer PITR sur une grande table est un coût permanent proportionnel à la taille de la table, engagé pour le pipeline d'analytique plutôt que pour la restauration. Chiffre l'intégration comme « Redshift plus PITR », pas comme Redshift seul — le calculateur de tarifs DynamoDB gratuit dimensionnera le volet stockage avant que tu ne t'engages.

Deux contraintes qui bloquent les tables existantes. Les deux sont des limitations documentées, et les deux sont pénibles à corriger après coup :

« La table DynamoDB et le cluster Amazon Redshift doivent se trouver dans la même Région. » Un entrepôt qui consolide plusieurs Régions ne peut pas toutes les récupérer par cette voie.
« La table DynamoDB source doit être chiffrée avec une clé AWS KMS détenue par Amazon ou gérée par le client. Le chiffrement géré par Amazon n'est pas pris en charge pour la table DynamoDB source. » Les tables créées sous chiffrement géré par AWS doivent voir leurs paramètres de chiffrement modifiés avant qu'une intégration puisse être créée.

Là où la forme de tes données mord. Les éléments DynamoDB sont hétérogènes par conception ; les tables d'entrepôt ont des colonnes. Un single-table design qui héberge plusieurs types d'entités sous une même convention de clé de partition ne devient pas un schéma en étoile propre du simple fait d'être répliqué. Prévois du travail de modélisation dans Redshift une fois les données arrivées — l'intégration supprime le pipeline, pas la conception du schéma.

Quand tu n'as pas encore besoin d'un entrepôt

Tout agrégat n'est pas un problème d'analytique. Une grande part des « il faudrait mettre ça dans Redshift » commence par une seule question — combien d'éléments sont dans cet état, quel est le total pour ce client, quelles clés de partition dominent — posée de temps en temps, par un ingénieur, sur une seule table.

Le SQL Workbench de DynoTable répond directement à cette catégorie de question contre DynamoDB, à la demande : du vrai SQL avec COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING et DISTINCT, plus INNER/LEFT JOIN. Le positionnement est délibérément étroit — du SQL dans les règles de patterns d'accès de DynamoDB. C'est un unique SELECT ; il n'y a ni CTE, ni UNION, ni fonctions de fenêtrage, ni sous-requêtes scalaires ; une cible de jointure doit être une clé de partition ou une clé de partition de GSI. Les résultats arrivent en flux avec un badge « partiel » et deviennent exacts une fois la requête exécutée jusqu'au bout, et lire les données coûte toujours les lectures que cela coûte.

Ce n'est pas un substitut à un entrepôt, et les limites ci-dessus en sont la frontière honnête. Mais c'est une réponse plus rapide qu'un pipeline de réplication, un coût PITR et une conception de schéma — et cela te dit si la question valait un entrepôt avant que tu n'en construises un. L'exécution des requêtes Workbench est une fonctionnalité payante ; l'éditeur et l'autocomplétion sont gratuits. DynoTable est une application commerciale à code source fermé ; cette page décrit ce qu'elle fait, pas comment elle est construite.

FAQ

Redshift peut-il remplacer DynamoDB ?

Non, pas pour le trafic applicatif. Redshift est un entrepôt de données conçu pour parcourir et agréger ; il n'est pas fait pour servir des recherches par clé à haut volume avec une latence de l'ordre de la milliseconde. Les deux tournent côte à côte, DynamoDB servant l'application et une copie répliquée dans Redshift servant l'analytique.

Quelle est la fraîcheur des données DynamoDB dans Redshift ?

Avec l'intégration zéro-ETL, jusqu'à environ 30 minutes de retard. AWS documente qu'après l'export complet initial, elle « réplique de façon incrémentale les mises à jour de DynamoDB vers Amazon Redshift toutes les 15 à 30 minutes, à l'aide des exports incrémentaux DynamoDB ». Considère-la comme du reporting quasi temps réel, pas comme une vue en direct.

Pourquoi l'intégration zéro-ETL exige-t-elle PITR ?

Parce qu'elle est bâtie sur l'export à un instant précis de DynamoDB. La politique basée sur les ressources dont l'intégration a besoin accorde à Amazon Redshift l'action dynamodb:ExportTableToPointInTime, et cet export lit la sauvegarde continue que PITR entretient. Activer PITR est donc un coût réel et permanent de l'intégration.

Voir aussi

Apprends quand utiliser DynamoDB et pourquoi les scans coûtent cher.
Compare DynamoDB et PostgreSQL pour la question du relationnel opérationnel.
Modélise tes patterns d'accès en amont avec le single-table design.
Dimensionne le volet stockage et capacité avec le calculateur de tarifs DynamoDB gratuit.
Télécharger DynoTable pour interroger et agréger tes tables DynamoDB directement.

Références

Dernière vérification le 2026-08-02 par rapport à l'AWS Redshift Management Guide et à l'AWS DynamoDB Developer Guide officiels.