Aurora/RDS Postgres comme cible - Amazon Timestream

Pour des fonctionnalités similaires à celles d'Amazon Timestream pour, pensez à Amazon Timestream LiveAnalytics pour InfluxDB. Il permet une ingestion simplifiée des données et des temps de réponse aux requêtes à un chiffre en millisecondes pour des analyses en temps réel. Pour en savoir plus, cliquez ici.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Aurora/RDS Postgres comme cible

Cette section explique l'ingestion des données de séries chronologiques par étapes S3 dans Amazon RDS/Aurora PostgreSQL. Le processus d'ingestion se concentrera principalement sur les fichiers CSV générés par l'outil d'exportation de Timestream pour être ingérés dans Postgres. Nous recommandons de concevoir le schéma et la table PostgreSQL avec des stratégies d'indexation appropriées pour les requêtes temporelles. Utilisez n'importe quel processus ETL pour transformer les structures spécialisées de Timestream en tables relationnelles optimisées pour vos besoins spécifiques. Lorsque vous migrez des données Timestream vers une base de données relationnelle, structurez votre schéma avec une colonne d'horodatage comme index temporel principal, des colonnes d'identifiant de mesure dérivées du measure_name de Timestream et des colonnes de dimension provenant des dimensions de Timestream et de vos mesures réelles. Créez des index stratégiques sur des plages de temps et des combinaisons de dimensions fréquemment demandées afin d'optimiser les performances lors du processus de transformation et de chargement des données. Lors de la migration de données chronologiques vers PostgreSQL, il est essentiel de dimensionner correctement les instances pour maintenir les performances des requêtes à grande échelle. Tenez compte du volume de données attendu, de la complexité des requêtes et des exigences de simultanéité lorsque vous sélectionnez une classe d'instance, en portant une attention particulière à l'allocation de mémoire pour les charges de travail d'agrégation de séries chronologiques. Pour les ensembles de données dépassant des dizaines de millions de lignes, tirez parti des fonctionnalités de partitionnement natives de PostgreSQL et des stratégies d'indexation avancées pour optimiser les modèles d'accès aux séries chronologiques.

Nous vous recommandons d'effectuer des tests fonctionnels et de performance pour choisir la bonne instance et de régler votre base de données PostgreSQL afin de remédier à tout problème de performance. Il est essentiel d'effectuer des contrôles rigoureux de l'intégrité des données en comparant des exemples de requêtes entre votre base de données Timestream source et le système cible pour garantir le succès de la migration et garantir l'exactitude des requêtes. En exécutant des requêtes identiques sur les deux systèmes et en comparant les résultats (y compris le nombre d'enregistrements, les agrégations et les valeurs aberrantes), vous pouvez identifier tout écart susceptible d'indiquer des erreurs de transformation, une perte de données ou des différences sémantiques dans l'interprétation des requêtes. Ce processus de vérification confirme que vos données conservent leur valeur analytique après la migration, renforce la confiance dans le nouveau système auprès des parties prenantes qui s'appuient sur ces informations, aide à identifier les ajustements de requête nécessaires pour tenir compte des différences syntaxiques ou fonctionnelles entre les plateformes et établit une base de référence quantifiable pour déterminer quand la migration peut être considérée comme terminée et réussie. Sans ces contrôles systématiques, de subtiles incohérences dans les données risquent de passer inaperçues, ce qui peut entraîner des décisions commerciales incorrectes ou saper la confiance dans l'ensemble du projet de migration.

Ingestion

Nous recommandons d'utiliser AWS Database Migration Service (DMS) avec le code source S3 (CSV et Parquet sont tous deux pris en charge) avec PostgreSQL comme cible. Pour les scénarios dans lesquels le AWS DMS ne convient pas à vos besoins spécifiques, nous fournissons un utilitaire supplémentaire basé sur Python (PostgreSQL CSV Ingestion Tool) pour migrer les données CSV de S3 vers PostgreSQL.

Présentation de l'outil d'ingestion de fichiers CSV de PostgreSQL

L'outil d'ingestion de fichiers CSV de PostgreSQL est un utilitaire performant conçu pour charger efficacement des fichiers CSV dans les bases de données PostgreSQL. Il utilise le multi-threading et le regroupement de connexions pour traiter plusieurs fichiers en parallèle, réduisant ainsi considérablement le temps de chargement des données. Nous vous recommandons d'exécuter ce script à l'aide d'une EC2 instance. Envisagez d'utiliser des types d'instance optimisés pour les opérations réseau, tels que C5N.

Fonctions principales

  • Traitement multithread : charge plusieurs fichiers CSV simultanément.

  • Regroupement de connexions : gère efficacement les connexions aux bases de données.

  • Détection automatique des colonnes : extrait dynamiquement les noms de colonnes des en-têtes CSV.

  • Logique de réessai : gère les erreurs transitoires avec un recul exponentiel.

  • Gestion des fichiers ; déplace les fichiers traités vers un répertoire désigné. Toute nouvelle tentative revient à reprendre, mais pas à redémarrer.

  • Journalisation complète : journaux détaillés pour la surveillance et le dépannage.

  • Notifications d'erreur : notifications SNS facultatives en cas d'échec.

  • Informations d'identification sécurisées : récupère les mots de passe des bases de données depuis AWS Secrets Manager.

Prérequis et installation

Consultez les conditions requises et l'installation dans le fichier Readme in de l'outil d'ingestion CSV de PostgreSQL. GitHub

Utilisation

python copy_postgres.py \ --database 'postgres_testing' \ --table 'demolarge_restored' \ --csv-files-dir '/data/csv_files/*partition*/*.csv' \ --host database-1.cluster-xxxxxxxx.us-east-1.rds.amazonaws.com \ --secret-arn 'arn:aws:secretsmanager:<region>:<account_id>:secret:rds!cluster-xxxxx-xx-xx-xx-xxxxxxxx-xxxxx' \ --sns-topic-arn 'arn:aws:sns:<region>:<account_id>:<topic_name>'

Validation

Vous pouvez utiliser DynamoDB pour les lignes exportées ou les journaux générés par l'outil d'exportation de Timestream et les comparer aux lignes ingérées à partir des journaux d'automatisation de PostgreSQL Ingestion. Vous pouvez effectuer des comptages par rapport aux tables source et cible avec un temps d'exportation et d'importation constant. Si les données sont continuellement ingérées pendant le processus de migration, les chiffres varieront. Il est donc recommandé de comparer les lignes exportées aux lignes importantes depuis la journalisation.

Nettoyage

  • Nettoyer les données déchargées créées dans le cadre de l'outil Timestream for export. LiveAnalytics

  • Supprimez les données téléchargées et connectez-vous EC2 pour récupérer de l'espace.

  • Supprimez la table DynamoDB si elle est utilisée pour la journalisation dans le cadre de l'outil LiveAnalytics Timestream for export.