View a markdown version of this page

PERF04-BP04 Choisir le stockage de données en fonction des modèles d'accès - AWS Well-Architected Framework
Directives d'implémentationRessources

PERF04-BP04 Choisir le stockage de données en fonction des modèles d'accès

Utilisez les modèles d'accès de la charge de travail et les exigences des applications pour décider des services et technologies de données optimaux à utiliser.

Résultat souhaité : le stockage des données a été sélectionné en fonction des modèles d'accès aux données identifiés et documentés. Cela peut inclure les requêtes de lecture, d'écriture et de suppression les plus courantes, la nécessité d'effectuer des calculs et des agrégations, la complexité des données, l'interdépendance des données et les besoins de cohérence requis.

Anti-modèles courants :

  • Sélectionnez un seul moteur de base de données afin de simplifier la gestion des opérations.

  • Vous partez du principe que les modèles d'accès aux données n'évolueront pas dans le temps.

  • Vous implémentez des transactions complexes, la restauration et une logique de cohérence dans l'application.

  • La base de données est configurée pour prendre en charge une rafale de trafic potentiellement élevé. Dès lors, les ressources de la base de données restent inactives la plupart du temps.

  • Vous utilisez une base de données partagée pour des usages transactionnels et analytiques.

Avantages liés au respect de cette bonne pratique : la sélection et l'optimisation de votre stockage de données en fonction des modèles d'accès contribuent à réduire la complexité du développement et à optimiser vos opportunités de performances. Savoir quand utiliser les réplicas en lecture, les tables globales, le partitionnement des données et la mise en cache vous aidera à réduire les frais généraux opérationnels et à évoluer en fonction des besoins de votre charge de travail.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : moyen

Directives d'implémentation

Identifiez et évaluez votre modèle d'accès aux données pour sélectionner la configuration de stockage appropriée. Chaque solution de base de données dispose d'options pour configurer et optimiser votre solution de stockage. Utilisez les métriques et les journaux collectés et testez les options pour trouver la configuration optimale. Utilisez le tableau suivant pour passer en revue les options de stockage par service de base de données.

AWS Services Amazon RDS Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Scaling Storage Storage can be scaled up manually or configured to scale automatically to a maximum of 64 TiB based on engine types. Provisioned storage cannot be decreased. Storage scales automatically up to maximum of 128 TiB and decreases when data is removed. Maximum storage size also depends upon specific Aurora MySQL or Aurora Postgres engine versions. Storage automatically scales. Tables are unconstrained in terms of size. Storage scales automatically up to maximum of 64 TiB. Starting Amazon DocumentDB 4.0 storage can decrease by comparable amounts for data removal through dropping a collection or index. With Amazon DocumentDB 3.6 allocated space remains same and free space is reused when data volume increases. Storage is in-memory, tied to instance type or count. Storage scales automatically can grow up to 128 TiB (or 64 TiB in few Regions). Upon data removal from, total allocated space remains same and is reused in the future. Organizes your time series data to optimize query processing and reduce storage costs. Retention period can be configured through in-memory and magnetic tiers. Scales table storage up and down automatically as your application writes, updates, and deletes data. Storage automatically scales. Tables are unconstrained in terms of size.

Étapes d'implémentation :

  1. Comprenez les exigences relatives aux transactions, à l'atomicité, à la cohérence, à l'isolement et à la durabilité (ACID), ainsi qu'à la cohérence des lectures. Toutes les bases de données ne prennent pas en charge ces opérations, et la plupart des bases de données NoSQL fournissent un modèle de cohérence éventuel.

  2. Les applications distribuées à l'échelle mondiale doivent tenir compte des modèles de trafic, de la latence et des exigences d'accès afin d'identifier la solution de stockage optimale.

  3. Analysez les modèles de requête, les modèles d'accès aléatoires et les requêtes ponctuelles. Les considérations relatives aux fonctionnalités de requête hautement spécialisées pour le traitement du texte et du langage naturel, les séries chronologiques et les graphiques doivent également être prises en considération.

  4. Identifiez et documentez la croissance prévue des données et du trafic.

    1. Amazon RDS et Aurora prennent en charge la mise à l'échelle automatique du stockage jusqu'aux limites documentées. Au-delà de ces limites, envisagez de transférer des données plus anciennes vers Amazon S3 pour l'archivage, d'agréger les données historiques à des fins d'analyse ou de les mettre à l'échelle horizontalement à l'aide du partitionnement.

    2. DynamoDB et Amazon S3 se mettent automatiquement à l'échelle pour atteindre un volume de stockage presque illimité.

    3. Les instances Amazon RDS et les bases de données exécutées sur EC2 peuvent être redimensionnées manuellement, et de nouveaux volumes EBS peuvent être ajoutés ultérieurement sur les instances EC2 pour un stockage supplémentaire. 

    4. Les types d'instance peuvent être modifiés en fonction des changements d'activité. Par exemple, vous pouvez commencer avec une instance plus petite en phase de test, puis mettre à l'échelle l'instance lorsque vous commencez à recevoir du trafic de production vers le service. Aurora Serverless V2 se met automatiquement à l'échelle en fonction des changements de charge. 

  5. Exigences de base de référence relatives aux performances normales et maximales (transactions par seconde, TPS, et requêtes par seconde, QPS) et à la cohérence (ACID et cohérence éventuelle).

  6. Documentez les aspects de déploiement de la solution et les exigences d'accès à la base de données (comme la réplication mondiale, le multi-AZ, la réplication en lecture et plusieurs nœuds d'écriture).

Niveau d'effort du plan d'implémentation : faible. Si vous ne disposez pas de journaux ni de métriques pour votre solution de gestion des données, vous devrez les mettre en place avant d'identifier et de documenter vos modèles d'accès aux données. Une fois que votre modèle d'accès aux données sera identifié, la sélection et la configuration de votre stockage de données présenteront un niveau d'effort faible.

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :