Comment fonctionne la facturation dans Aurora DSQL

Avec Amazon Aurora DSQL, vous ne payez que ce que vous utilisez, sans frais initiaux. Cette section explique comment Aurora DSQL mesure l'activité de votre base de données et la traduit en frais sur votre AWS facture. Pour connaître les tarifs actuels par région, consultez la page de tarification d'Aurora DSQL.

Comment fonctionne le comptage

Contrairement aux bases de données traditionnelles qui facturent la capacité provisionnée, Aurora DSQL facture uniquement le travail réellement effectué. Aurora DSQL mesure deux composants principaux : l'activité de la base de données, mesurée en unités de traitement distribuées (DPU), et le stockage, mesuré en. GiB-month

Les DPU mesurent la quantité de travail effectuée par le système pour exécuter votre charge de travail SQL et sont composés de trois composants pour les clusters à région unique : les DPU de calcul, les DPU de lecture et les DPU d'écriture. Multi-Region les clusters font appel à un composant DPU MultiRegion d'écriture supplémentaire. Pour plus d'informations sur la Multi-Region facturation, consultez la section Multi-Region Facturation. Les clusters pour lesquels la capture des données de modification (CDC) est activée nécessitent un composant Stream DPU supplémentaire. Pour plus d'informations sur la facturation CDC, consultez Stream DPU.

Le tableau suivant récapitule les composants qu'Aurora DSQL utilise pour mesurer l'activité de votre base de données. Sur votre facture, vous ne voyez que deux rubriques : l'une pour le stockage et l'autre pour le DPU, qui est la somme de chacun des composants individuels.

Explication de la mesure des composants DPU

Pour chaque transaction, Aurora DSQL calcule le DPU total comme la somme de trois composants : DPU de calcul, DPU de lecture et DPU d'écriture. Les sections suivantes expliquent comment Aurora DSQL mesure chaque composant.

Total DPU = ComputeDPU + ReadDPU + WriteDPU

PU informatique

Les DPU de calcul sont mesurés en fonction du temps de traitement total passé à exécuter votre requête, y compris les jointures, les fonctions, les agrégations, le tri et la planification des requêtes. Comme certaines parties de votre requête peuvent être traitées en parallèle, le DPU de calcul reflète la somme de tous les temps de traitement, et non l'heure de l'horloge murale de la requête.

La formule suivante résume la façon de calculer les DPU de calcul :

ComputeDPU = Total Compute time (in seconds)

PU écrit

Pour chaque transaction, Aurora DSQL mesure les DPU d'écriture en fonction du nombre total d'octets écrits dans le stockage. Les DPU d'écriture incluent le total des données écrites dans votre table de base ainsi que tous les index secondaires. Aurora DSQL facture chaque ligne écrite dans votre table de base et dans vos index secondaires dont la taille est inférieure à 128 octets comme si elle était de 128 octets. Aurora DSQL facture une transaction d'écriture qui écrit moins de 1 024 octets comme si elle écrivait 1 024 octets.

Les formules suivantes indiquent les étapes à suivre pour calculer les DPU d'écriture :

Étape 1 : Calculez les octets écrits

Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written

Étape 2 : Calculez le processeur écrit

WriteDPU = max(Bytes Written, 1024) × 0.00004883

Lire le DPU

Pour chaque transaction, Aurora DSQL mesure les DPU de lecture en fonction du nombre total d'octets lus depuis le stockage. Les DPU de lecture incluent les données lues depuis votre table de base ainsi que tous les index secondaires.

Per-partition minimum : Aurora DSQL mesure les octets lus par partition de stockage, et non par ligne. Si une demande de lecture vers une partition de stockage renvoie moins de 128 octets, Aurora DSQL l'arrondit à 128 octets. Par exemple, si votre requête est lue à partir de 4 partitions (200 octets d'une partition et 50 octets de chacune des trois autres), les trois lectures de 50 octets sont arrondies à 128 octets, soit un total de 200 + 128 + 128 + 128 + 128 = 584 octets facturés.

Transaction minimale : Aurora DSQL facture une transaction de lecture qui lit moins de 2 048 octets au total comme si elle lisait 2 048 octets.

Les formules suivantes indiquent les étapes à suivre pour calculer les DPU de lecture :

Étape 1 : Calcul des octets lus

Bytes Read = # of rows read × size of each row

Étape 2 : Calculez ReadDPU

ReadDPU = max(Bytes Read, 2048) × 0.00000183105

Diffusez le DPU

Les DPU Stream s'appliquent uniquement lorsque vous activez la capture des données de modification (CDC) sur votre cluster. Aurora DSQL mesure les DPU des flux en fonction du nombre total d'octets transmis à votre flux Amazon Kinesis Data Streams cible. Lorsqu'aucune modification n'est apportée au stream, aucun frais de DPU Stream ne vous sera facturé.

La formule suivante montre comment calculer les DPU Stream :

StreamDPU = Bytes Streamed × 0.0000023283

Aurora DSQL facture les DPU Stream au même tarif que tous les autres composants DPU. Pour plus d'informations sur les flux CDC, consultezModifier les flux de capture de données.

Exemples de facturation

Les exemples suivants montrent comment Aurora DSQL calcule les DPU pour les opérations courantes. Les valeurs de coût de ces exemples utilisent le prix de la région us-east-1. Pour connaître les tarifs dans les autres régions, consultez la page de tarification d'Aurora DSQL.

CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    customer_id VARCHAR(50) NOT NULL,
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    total_amount DECIMAL(10,2),
    status VARCHAR(20)
);
-- Average row size: ~100 bytes

SELECT * FROM orders WHERE customer_id = 'cust-12345';

ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375

ComputeDPU: 0.003
ReadDPU:    0.00375
WriteDPU:   0.0
-------------------
Total DPU:  0.00675

CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    customer_id VARCHAR(50) NOT NULL,
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    total_amount DECIMAL(10,2),
    status VARCHAR(20)
);
-- Average row size: ~100 bytes
-- Table contains 100 orders for customer 'cust-12345'

SELECT * FROM orders
WHERE customer_id = 'cust-12345'
  AND total_amount > 500.00;

ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831

ComputeDPU: 0.008
ReadDPU:    0.01831
WriteDPU:   0.0
-------------------
Total DPU:  0.02631

CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    customer_id VARCHAR(50) NOT NULL,
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    total_amount DECIMAL(10,2),
    status VARCHAR(20)
);
-- Average row size: ~100 bytes

INSERT INTO orders (customer_id, total_amount, status)
VALUES ('cust-67890', 150.00, 'pending');

1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes

WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05

ReadDPU = 0.00375 (transaction minimum)

ComputeDPU: 0.008
ReadDPU:    0.00375
WriteDPU:   0.05
-------------------
Total DPU:  0.06175

CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    customer_id VARCHAR(50) NOT NULL,
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    total_amount DECIMAL(10,2),
    status VARCHAR(20)
);
-- Average row size: ~100 bytes

INSERT INTO orders (customer_id, total_amount, status)
VALUES
    ('cust-001', 100.00, 'pending'),
    ('cust-002', 150.00, 'pending'),
    ... -- 100 rows total
    ('cust-100', 200.00, 'pending');

100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes

WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625

ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375

ComputeDPU: 0.08
ReadDPU:    0.00375
WriteDPU:   0.625
-------------------
Total DPU:  0.70875

Multi-Region facturation

Multi-Region les clusters comportent un composant DPU d' MultiRegion écriture supplémentaire en plus des DPU de calcul, de lecture et d'écriture standard. Cette section s'applique uniquement aux clusters multirégionaux. Single-Region les clusters ne sont pas soumis à ces frais.

Multi-Region Les DPU d'écriture mesurent le nombre total d'octets écrits dans la région correspondante. Aurora DSQL charge ce DPU dans la région d'origine de l'écriture, et non dans la région correspondante. Par exemple, dans une configuration d'appairage à deux régions actives et à deux témoins, Aurora DSQL facture le DPU d'écriture de la transaction d'origine pour chaque région homologue active lors du calcul du. MultiRegionWriteDPU Cela signifie qu'une transaction qui cumule 8 WriteDPU entraîne 8 transactions supplémentaires MultiRegionWriteDPU pour cette configuration. Ce montant est de 8 pour la région d'origine, de 8 pour la région correspondante, et c'est gratuit pour la région témoin. Aurora DSQL facture tous les frais à la région à l'origine de la transaction.

Tous les clusters de la configuration multi-régions sont soumis à des frais de taille de stockage. Comme Aurora DSQL reproduit de manière synchrone les données que vous écrivez dans la région homologue, les frais de taille de stockage s'appliquent individuellement à tous les clusters de la configuration multirégion. Cela s'applique également aux clusters dont l'état est en attente de suppression. Pour plus d'informations sur l'état de suppression en attente, consultez la page du cycle de vie du cluster Aurora DSQL.

MultiRegionWriteDPU = WriteDPU

Surveillance de l'utilisation du DPU avec CloudWatch

Aurora DSQL publie des mesures d'utilisation sur Amazon CloudWatch, ce qui vous permet de surveiller la consommation en temps quasi réel.

Métriques DPU disponibles

Affichage des métriques DPU

Mesures d'observabilité supplémentaires

Pour obtenir la liste complète des mesures et des fonctionnalités de surveillance d'Aurora DSQL, consultezSurveillance et journalisation pour Aurora DSQL.

Utiliser EXPLAIN ANALYZE VERBOSE pour mieux connaître les coûts

Aurora DSQL s'étend EXPLAIN ANALYZE VERBOSE pour inclure une estimation de l'utilisation du DPU au niveau de l'instruction à la fin de la sortie. Cela fournit une visibilité immédiate sur le coût des requêtes, ce qui vous permet d'identifier les facteurs de coût de la charge de travail, d'ajuster les performances des requêtes et de mieux prévoir l'utilisation des ressources.

Exemple 1 : requête SELECT

EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;

QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table  (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
  Output: id, context
  -> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
      Projections: id, context
      -> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
  Compute: 0.01607 DPU
  Read: 0.04312 DPU
  Write: 0.00000 DPU
  Total: 0.05919 DPU

Dans cet exemple, l'instruction SELECT effectue une analyse d'index uniquement. La majeure partie des coûts provient donc de la DPU de lecture (0,04312), qui représente les données extraites du stockage, et de la DPU de calcul (0,01607), qui reflète les ressources de calcul utilisées pour traiter et renvoyer les résultats. Il n'y a pas de DPU d'écriture car la requête ne modifie pas les données. Le DPU total (0,05919) est la somme de Compute + Read + Write.

Exemple 2 : requête INSERT

EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');

QUERY PLAN
----------------------------------------------------
Insert on public.test_table  (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
  ->  Values Scan on "*VALUES*"  (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
        Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
  Compute: 0.01550 DPU
  Read: 0.00307 DPU (Transaction minimum: 0.00375)
  Write: 0.01875 DPU (Transaction minimum: 0.05000)
  Total: 0.03732 DPU

Cette instruction effectue principalement des écritures, de sorte que la majeure partie des coûts est associée à Write DPU. Le DPU de calcul (0.01550) représente le travail effectué pour traiter et insérer les valeurs. Le DPU de lecture (0,00307) reflète les lectures mineures du système (pour les recherches dans le catalogue ou les vérifications d'index).

Notez les minimums de transactions indiqués entre parenthèses à côté des DPU en lecture et en écriture. Ces minimums s'appliquent au niveau de la transaction, ce qui signifie que le DPU total en lecture ou en écriture pour l'ensemble d'une transaction n'est jamais inférieur à ces valeurs. Si vous utilisez EXPLAIN ANALYZE VERBOSE pour prévoir les coûts et qu'il s'agit du seul relevé de la transaction, utilisez les valeurs minimales de la transaction plutôt que les estimations brutes du relevé. Si la transaction contient plusieurs relevés, les minimums s'appliquent au cumul de tous les relevés. Étant donné que EXPLAIN ANALYZE VERBOSE les rapports fournissent des estimations au niveau des relevés alors que la facturation applique des minimums au niveau des transactions, les valeurs peuvent ne pas correspondre CloudWatch exactement aux mesures ou aux données de facturation.

Utilisation des informations DPU à des fins d'optimisation

Per-statement Les estimations DPU constituent un moyen puissant d'optimiser les requêtes au-delà du simple temps d'exécution. Cas d’utilisation courants :

Interprétation des informations DPU

Gardez les bonnes pratiques suivantes à l'esprit lorsque vous utilisez les données DPU provenant de EXPLAIN ANALYZE VERBOSE :

Meilleures pratiques en matière d'estimation des coûts