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.
Sélection d'une base de données pour une application SaaS
Pour de nombreuses applications SaaS à locataires multiples, la sélection d'une base de données opérationnelle peut se résumer à un choix entre des bases de données relationnelles et non relationnelles, ou à une combinaison des deux. Pour prendre votre décision, tenez compte de ces exigences et caractéristiques de haut niveau en matière de données d'application :
-
Modèle de données de l'application
-
Modèles d'accès aux données
-
Exigences de latence de la base
-
Exigences relatives à l'intégrité des données et à l'intégrité transactionnelle (atomicité, cohérence, isolation et durabilité, ou ACID)
-
Exigences relatives à la disponibilité et à la restauration entre les régions
Le tableau suivant répertorie les exigences et les caractéristiques des données des applications, et les aborde dans le contexte des offres de AWS base de données : compatible avec Aurora PostgreSQL et Amazon RDS for PostgreSQL (relationnel), et Amazon DynamoDB (non relationnel). Vous pouvez faire référence à cette matrice lorsque vous essayez de choisir entre des offres de bases de données opérationnelles relationnelles et non relationnelles.
| Bases de données | Exigences et caractéristiques des données des applications SaaS | ||||
|---|---|---|---|---|---|
| Modèle de données | Modèles d'accès | Exigences de latence | Intégrité des données et des transactions | Disponibilité et restauration entre les régions | |
Relationnel (compatible avec Aurora PostgreSQL et Amazon RDS pour PostgreSQL) |
Relationnel ou hautement normalisé. | Il n'est pas nécessaire de le planifier minutieusement à l'avance. | Tolérance de latence de préférence plus élevée ; permet d'obtenir des latences plus faibles par défaut avec Aurora et en implémentant des répliques de lecture, la mise en cache et des fonctionnalités similaires. | Intégrité élevée des données et des transactions maintenue par défaut. | Dans Amazon RDS, vous pouvez créer une réplique en lecture pour le dimensionnement et le basculement entre régions. Aurora automatise principalement ce processus. |
Non relationnel (Amazon DynamoDB) |
Généralement dénormalisé. Ces bases de données tirent parti des modèles pour modéliser many-to-manyles relations, les éléments volumineux et les données de séries chronologiques. | Tous les modèles d'accès (requêtes) aux données doivent être parfaitement compris avant qu'un modèle de données ne soit produit. | Très faible latence grâce à des options telles qu'Amazon DynamoDB Accelerator (DAX) capables d'améliorer encore les performances. | Intégrité transactionnelle optionnelle au détriment des performances. Les problèmes d'intégrité des données sont transférés à l'application. | Restauration facile entre régions et configuration active-active avec des tables globales. (La conformité ACID n'est réalisable que dans une seule AWS région.) |
Certaines applications SaaS mutualisées peuvent avoir des modèles de données uniques ou des circonstances particulières qui sont mieux desservies par des bases de données non incluses dans le tableau précédent. Par exemple, les ensembles de données chronologiques, les ensembles de données hautement connectés ou la gestion d'un registre de transactions centralisé peuvent nécessiter l'utilisation d'un autre type de base de données. L'analyse de toutes les possibilités dépasse le cadre de ce guide. Pour obtenir une liste complète des offres de AWS base de données et savoir comment elles peuvent répondre à différents cas d'utilisation à un niveau élevé, consultez la section Base de données du livre blanc Présentation d'Amazon Web Services.
Le reste de ce guide se concentre sur les services de base de données AWS relationnelle compatibles avec PostgreSQL : Amazon RDS et Aurora PostgreSQL compatibles. DynamoDB nécessite une approche différente pour optimiser les applications SaaS, ce qui dépasse le cadre de ce guide. Pour plus d'informations sur DynamoDB, consultez le billet de blog Partitioning Pooled AWS Multi-Tenant SaaS
Choisir entre Amazon RDS et Aurora
Dans la plupart des cas, nous recommandons d'utiliser Aurora PostgreSQL compatible plutôt qu'Amazon RDS for PostgreSQL. Le tableau suivant indique les facteurs à prendre en compte au moment de choisir entre ces deux options.
| composant DBMS | Amazon RDS for PostgreSQL | Compatible avec Aurora avec PostgreSQL |
|---|---|---|
| Evolutivité | Délai de réplication de quelques minutes, maximum de 5 répliques de lecture | Retard de réplication inférieur à une minute (généralement inférieur à 1 seconde avec les bases de données globales), maximum de 15 répliques de lecture |
| Reprise après un crash | Les points de contrôle espacés de 5 minutes (par défaut) peuvent ralentir les performances de la base de données | Restauration asynchrone avec threads parallèles pour une restauration rapide |
| Basculement | 60 à 120 secondes en plus du temps de récupération en cas de panne | Généralement environ 30 secondes (y compris la récupération en cas de panne) |
| Stockage | Nombre maximal d'IOPS de 256 000 | Les IOPS sont limitées uniquement par la taille et la capacité de l'instance Aurora |
| Haute disponibilité et reprise après sinistre | Deux zones de disponibilité avec une instance de secours, basculement entre régions pour lire les répliques ou les sauvegardes copiées | Trois zones de disponibilité par défaut, basculement entre régions avec les bases de données globales Aurora, transfert d'écriture Régions AWS pour les configurations active-active |
| Sauvegarde | Pendant la fenêtre de sauvegarde, cela peut avoir un impact sur les performances | Sauvegardes incrémentielles automatiques, sans impact sur les performances |
| classes d'instances de base de données | Voir la liste des classes d'instances Amazon RDS | Voir la liste des classes d'instances Aurora |
Dans toutes les catégories décrites dans le tableau précédent, la compatibilité avec Aurora PostgreSQL est généralement la meilleure option. Cependant, Amazon RDS for PostgreSQL peut toujours être utile pour les charges de travail petites et moyennes, car il propose un plus grand choix de classes d'instances, ce qui peut constituer une option plus rentable au détriment de l'ensemble de fonctionnalités plus robustes d'Aurora.
