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.

Comparaison des comportements de l'API Amazon RDS Data pour Aurora Serverless v2 et des clusters provisionnés avec Aurora Serverless v1 clusters

Les dernières améliorations apportées aux données Amazon RDS APIs rendent les données APIs disponibles pour les clusters qui utilisent des versions récentes des moteurs PostgreSQL ou MySQL. Ces clusters peuvent être configurés pour utiliser Aurora Serverless v2 ou des classes d'instances provisionnées telles que db.r6g oudb.r6i.

Les sections suivantes décrivent les différences entre les API de données Amazon RDS : Aurora Serverless v2 et des clusters de bases de données provisionnés, et Aurora Serverless v1 Clusters de bases de données. Aurora Serverless v1 Les clusters de base de données utilisent le mode serverless moteur. Les clusters de base de données provisionnés utilisent le mode provisioned moteur. Un Aurora Serverless v2 Le cluster de base de données utilise également le mode provisioned moteur et contient un ou plusieurs Aurora Serverless v2 Instances de base de données avec la classe d'db.serverlessinstance.

Nombre maximum de demandes par seconde

Aurora Serverless v1

Les données APIs peuvent effectuer jusqu'à 1 000 demandes par seconde.

Aurora Serverless v2

Les données APIs peuvent effectuer un nombre illimité de demandes par seconde.

Activation ou désactivation de l'API Amazon RDS Data sur une base de données existante

CloudTrail événements

Aurora Serverless v1

Les événements issus des appels d'API de données sont des événements de gestion. Ces événements sont automatiquement inclus dans un parcours par défaut. Pour de plus amples informations, veuillez consulter Exclure les événements de l'API de données d' AWS CloudTrail un historique (Aurora Serverless v1 uniquement).

Aurora Serverless v2

Les événements issus des appels d'API de données sont des événements de données. Ces événements sont automatiquement exclus d'un parcours par défaut. Pour de plus amples informations, veuillez consulter Inclure les événements de l'API de données dans un AWS CloudTrail historique.

Support multi-déclarations

Aurora Serverless v2

Les multiinstructions ne sont pas prises en charge. Une tentative d'exécution de plusieurs instructions dans un seul appel d'API est renvoyée“An error occurred (ValidationException) when calling the ExecuteStatement operation: Multistatements aren't supported.”. Pour exécuter plusieurs instructions, effectuez des appels ExecuteStatement d'API distincts ou utilisez-les BatchExecuteStatement pour le traitement par lots.

L'exemple suivant montre le message d'erreur résultant d'un appel d'API qui tente d'exécuter une instruction multiple.

 aws rds-data execute-statement \    
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \    
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \    
    --database "your_database" \
    --sql "SELECT * FROM your_table; Select * FROM next_table;
                                
                                "An error occurred (ValidationException) when calling the ExecuteStatement operation: Multistatements aren't supported.

L'exemple suivant exécute plusieurs instructions avec des appels d'ExecuteStatementAPI distincts.

aws rds-data execute-statement \
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
    --database "your_database" \
    --sql "SELECT * FROM your_table;"

aws rds-data execute-statement \
    --resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
    --secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
    --database "your_database" \
    --sql "SELECT * FROM next_table;"

Demandes simultanées pour le même numéro de transaction

Aurora Serverless v1

Les demandes suivantes attendent que la demande en cours soit terminée. Votre application doit gérer les erreurs de temporisation si le délai d'attente est trop long.

Aurora Serverless v2

Lorsque l'API Data reçoit plusieurs demandes avec le même identifiant de transaction, elle renvoie immédiatement cette erreur :

DatabaseErrorException: Transaction is still running a query

Cette erreur se produit dans deux situations :

L'exemple suivant montre toutes les requêtes exécutées en parallèle avecpromise.all().

const api_calls = [];
for (let i = 0; i < 10; i++) {
api_calls.push(
    client.send(
    new ExecuteStatementCommand({
        ...params,
        sql: `insert into table_name values (i);`,
        transactionId
    })
    )
);
}
await Promise.all(api_calls);

Pour résoudre cette erreur, attendez que la demande en cours soit terminée avant d'envoyer une autre demande avec le même ID de transaction ou supprimez l'ID de transaction pour autoriser les requêtes parallèles.

L'exemple suivant montre un appel d'API qui utilise une exécution séquentielle avec le même identifiant de transaction.

 for (let i = 0; i < 10; i++) {
    await client.send(
    new ExecuteStatementCommand({
        ...params,
        sql: `insert into table_name values (i);`,
        transactionId
    })
    ).promise()
);
}

BatchExecuteStatement comportement

Pour plus d’informations sur BatchExecuteStatement, consultez BatchExecuteStatement.

Aurora Serverless v1

L'objet des champs générés dans le résultat de la mise à jour inclut les valeurs insérées.

Comportement d'ExecuteSQL

Pour plus d'informationsExecuteSQL, consultez ExecuteSQL.

Aurora Serverless v1

L'ExecuteSQLopération est obsolète.

Aurora Serverless v2

L'ExecuteSQLopération n'est pas prise en charge.

ExecuteStatement comportement

Pour plus d’informations sur ExecuteStatement, consultez ExecuteStatement.

Aurora Serverless v1

Le ExecuteStatement paramètre prend en charge la récupération de colonnes de tableaux multidimensionnels et de tous les types de données avancés.

Aurora Serverless v2

Le ExecuteStatement paramètre ne prend pas en charge les colonnes de tableau multidimensionnelles. Il ne prend pas non plus en charge certains types de données PostgreSQL, notamment les types géométriques et monétaires. Lorsqu'une API de données rencontre un type de données non pris en charge, elle renvoie cette erreur :. UnsupportedResultException: The result contains the unsupported data type data_type

Pour contourner ce problème, convertissez le type de données non pris en charge en. TEXT L'exemple suivant convertit un type de données non pris en charge en. TEXT

SELECT custom_type::TEXT FROM my_table;-- 
ORSELECT CAST(custom_type AS TEXT) FROM my_table;

Pour obtenir la liste des types de données pris en charge pour chaque moteur de base de données Aurora, consultez la section Référence des opérations de l'API de données.

Comportement des paramètres du schéma

Aurora Serverless v1

Le Schema paramètre n'est pas pris en charge. Lorsque vous incluez le Schema paramètre dans un appel d'API, l'API Data ignore le paramètre.

Aurora Serverless v2

Le paramètre Schema est obsolète. Lorsque vous incluez le Schema paramètre dans un appel d'API, l'API Data renvoie cette erreur :ValidationException: The schema parameter isn't supported. L'exemple suivant montre un appel d'API de données qui renvoie l'ValidationExceptionerreur.

aws rds-data execute-statement \
--resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \
--secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \
--database "your_database" \
--schema "your_schema" \
--sql "SELECT * FROM your_table LIMIT 10"
                

Pour résoudre ce problème, supprimez le Schema paramètre de votre appel d'API.

L'exemple suivant montre un appel d'API de données dont le Schema paramètre a été supprimé.

aws rds-data execute-statement \   
--resource-arn "arn:aws:rds:region:account:cluster:cluster-name" \    
--secret-arn "arn:aws:secretsmanager:region:account:secret:secret-name" \    
--database "your_database" \    
--sql "SELECT * FROM your_table LIMIT 10"