Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Come funziona la fatturazione in Aurora SQL Con Amazon Aurora DSQL, paghi solo per ciò che usi senza costi iniziali. Questa sezione spiega come Aurora DSQL misura l'attività del database e la traduce in addebiti sulla fattura. AWS Per i prezzi correnti per regione, consulta la pagina dei prezzi di [Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/). **Topics** + [Come funziona la misurazione](#billing-how-metering-works) + [Spiegazione della misurazione dei componenti della DPU](#billing-dpu-components) + [Fatturazione multiregionale](#billing-multiregion-write-dpu) + [Monitoraggio dell'utilizzo della DPU con CloudWatch](#billing-cloudwatch-monitoring) + [Utilizzo di EXPLAIN ANALYZE VERBOSE per la consapevolezza dei costi](#billing-explain-analyze) + [Le migliori pratiche di stima dei costi](#billing-best-practices) ## Come funziona la misurazione A differenza dei database tradizionali che addebitano un costo per la capacità fornita, Aurora DSQL addebita solo il lavoro effettivamente svolto. Aurora DSQL misura due componenti principali: l'attività del database, misurata in unità di elaborazione distribuite (DPUs), e lo storage, misurata in GiB-mese. DPUs misurano il lavoro svolto dal sistema per eseguire il carico di lavoro SQL e sono composti da tre componenti per i cluster a regione singola: Compute, Read e Write. DPUs DPUs DPUs I cluster multi-regione richiedono un componente Write DPU aggiuntivo. MultiRegion [Per i dettagli, consulta Fatturazione per più regioni.](#billing-multiregion-write-dpu) La tabella seguente riassume i componenti utilizzati da Aurora DSQL per misurare l'attività del database. Nella fattura vengono visualizzate solo due voci: una per l'archiviazione e una per la DPU, che è la somma di ciascuno dei singoli componenti. | Unità di misurazione | Tipo di attività | Misura | | --- | --- | --- | | Calcola DPU | Elaborazione query | Tempo della CPU | | Leggi DPU | Leggi i dati dal tuo database | Byte letti dalla memoria | | Scrivi DPU | Scrivi dati nel tuo database | Byte scritti nella memoria | | Archiviazione | Archiviazione in tabelle | GiB-mese | ## Spiegazione della misurazione dei componenti della DPU Per ogni transazione, Aurora DSQL calcola la DPU totale come la somma di tre componenti: Compute DPU, Read DPU e Write DPU. Le sezioni seguenti spiegano come Aurora DSQL misura ogni componente. ``` Total DPU = ComputeDPU + ReadDPU + WriteDPU ``` ### PU computerizzata L'elaborazione DPUs viene misurata utilizzando il tempo di elaborazione totale impiegato per l'esecuzione della query, inclusi join, funzioni, aggregazioni, ordinamento e pianificazione delle query. Poiché alcune parti della query possono essere elaborate in parallelo, la Compute DPU riflette la somma di tutti i tempi di elaborazione, non il tempo dell'orologio a parete della query. La formula seguente riassume come calcolare Compute: DPUs ``` ComputeDPU = Total Compute time (in seconds) ``` ### PU scritto Per ogni transazione, Aurora DSQL misura la scrittura in DPUs base al totale dei byte scritti nello storage. Write DPUs include i dati totali scritti nella tabella di base e gli eventuali indici secondari. Aurora DSQL fattura ogni riga scritta nella tabella di base e negli indici secondari inferiori a 128 byte come se fosse 128 byte. Aurora DSQL fattura una transazione di scrittura che scrive meno di 1.024 byte come se avesse scritto 1.024 byte. **Nota** Le operazioni di scrittura comportano anche costi ReadDPU perché Aurora DSQL legge l'indice della chiave primaria per verificare l'unicità prima della scrittura. Le seguenti formule mostrano i passaggi per calcolare Write: DPUs **Passaggio 1: calcola i byte scritti** ``` Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written ``` **Fase 2: Calcolare la PU scritta** ``` WriteDPU = max(Bytes Written, 1024) × 0.00004883 ``` ### Leggi DPU Per ogni transazione, Aurora DSQL misura il numero di byte letti DPUs dallo storage in base al totale dei byte letti. La lettura DPUs include i dati letti dalla tabella di base e da eventuali indici secondari. **Minimo per partizione: Aurora** DSQL misura i byte letti per partizione di archiviazione, non per riga. Se una richiesta di lettura a una partizione di archiviazione restituisce meno di 128 byte, Aurora DSQL la arrotonda a 128 byte. Ad esempio, se la query viene letta da 4 partizioni, 200 byte da una partizione e 50 byte da ciascuna delle altre tre, le tre letture da 50 byte vengono arrotondate ciascuna a 128 byte, per un totale di 200 \+ 128 \+ 128 \+ 128 \+ 128 = 584 byte fatturati. **Transazione minima:** Aurora DSQL fattura una transazione di lettura che legge meno di 2.048 byte in totale come se leggesse 2.048 byte. Le seguenti formule mostrano i passaggi per il calcolo della lettura: DPUs **Passaggio 1: calcola i byte letti** ``` Bytes Read = # of rows read × size of each row ``` **Nota** I byte effettivamente letti dipendono da come i dati vengono distribuiti tra le partizioni di archiviazione, poiché per ogni partizione viene applicato il minimo di 128 byte per partizione. Se tutte le dimensioni delle righe sono superiori a 128 byte, puoi semplicemente moltiplicare il numero di righe lette per la dimensione di ogni riga. **Fase 2: Calcola ReadDPU** ``` ReadDPU = max(Bytes Read, 2048) × 0.00000183105 ``` ### Esempi di fatturazione Gli esempi seguenti mostrano come Aurora DSQL calcola DPUs le operazioni comuni. I valori di costo in questi esempi utilizzano il prezzo della regione us-east-1. Per i prezzi in altre regioni, consulta la pagina dei prezzi di [Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/). #### Esempio: ricerca semplice in punti (lettura) Questo esempio dimostra un calcolo ReadDPU con ricerca puntuale in cui si applica il minimo di transazione. **Schema:** ``` 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 ``` **Interrogazione:** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345'; ``` **Scenario:** la query restituisce 5 righe, ciascuna di circa 100 byte. Supponendo che tutte le righe risiedano in una partizione di archiviazione, il totale dei byte letti è 5 × 100 = 500 byte. Poiché 500 byte superano il minimo di 128 byte per partizione, non si applica alcun valore minimo per partizione. **Calcola ReadDPU:** ``` ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` Il minimo di transazione di 2.048 byte si applica poiché 500 < 2.048. **Costo totale della transazione:** Supponendo un tempo di esecuzione della query di 3 ms (0,003 secondi): ``` ComputeDPU: 0.003 ReadDPU: 0.00375 WriteDPU: 0.0 ------------------- Total DPU: 0.00675 ``` #### Esempio: scansione con intervallo filtrato (lettura) **Schema:** ``` 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' ``` **Interrogazione:** ``` SELECT * FROM orders WHERE customer_id = 'cust-12345' AND total_amount > 500.00; ``` **Scenario:** la query analizza 100 righe alla ricerca del cliente 'cust-12345', ma il `total_amount > 500.00` filtro riduce il risultato a sole 10 righe restituite. Fatture Aurora DSQL per tutte le 100 righe scansionate. Supponendo che tutte le righe risiedano in una partizione di archiviazione, il totale dei byte letti è 100 × 100 = 10.000 byte. **Calcola ReadDPU:** ``` ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831 ``` Poiché 10.000 byte superano il minimo di transazione di 2.048 byte, vengono utilizzati i byte effettivamente letti. **Costo totale della transazione:** Supponendo un tempo di esecuzione della query di 8 ms (0,008 secondi): ``` ComputeDPU: 0.008 ReadDPU: 0.01831 WriteDPU: 0.0 ------------------- Total DPU: 0.02631 ``` **Importante** Per ridurre al minimo i costi di ReadDPU, progetta query e indici per scansionare solo le righe necessarie. In questo esempio, l'aggiunta di un indice `(customer_id, total_amount)` potrebbe consentire alla query di scansionare un numero inferiore di righe. #### Esempio: inserto singolo (lettura e scrittura) **Schema:** ``` 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 ``` **Interrogazione:** ``` INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-67890', 150.00, 'pending'); ``` **Scenario:** inserire 1 riga, circa 100 byte. **Calcolo WritedPU:** *Fase 1 - Calcola i byte scritti:* ``` 1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes ``` *Fase 2 - Calcolo del PU scritto:* ``` WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05 ``` Il minimo di transazione di 1.024 byte si applica poiché 128 < 1.024. **ReadDPU (controllo della chiave primaria):** Aurora DSQL legge l'indice della chiave primaria per verificare l'unicità prima della scrittura. Ciò comporta il costo minimo di lettura della transazione. ``` ReadDPU = 0.00375 (transaction minimum) ``` **Costo totale della transazione:** Supponendo un tempo di esecuzione della query di 8 ms (0,008 secondi): ``` ComputeDPU: 0.008 ReadDPU: 0.00375 WriteDPU: 0.05 ------------------- Total DPU: 0.06175 ``` #### Esempio: inserimento in blocco (lettura e scrittura) **Schema:** ``` 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 ``` **Interrogazione:** ``` 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'); ``` **Scenario:** inserire 100 righe, ciascuna di circa 100 byte. **Calcolo WritedPU:** *Fase 1 - Calcola i byte scritti:* ``` 100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes ``` *Fase 2 - Calcolo del PU scritto:* ``` WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625 ``` **ReadDPU (controlli delle chiavi primarie):** Aurora DSQL legge l'indice della chiave primaria per ogni riga per verificarne l'unicità. Supponendo che tutte le 100 ricerche chiave risiedano in una partizione di archiviazione, il totale di byte letti è 100 × 16 byte (UUID) = 1.600 byte: ``` ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375 ``` Il minimo di transazione di 2.048 byte si applica poiché 1.600 < 2.048. **Costo totale della transazione:** Supponendo un tempo di esecuzione della query di 80 ms (0,08 secondi): ``` ComputeDPU: 0.08 ReadDPU: 0.00375 WriteDPU: 0.625 ------------------- Total DPU: 0.70875 ``` ## Fatturazione multiregionale I cluster multi-regione prevedono un componente MultiRegion Write DPU aggiuntivo oltre agli standard Compute, Read e Write. DPUs Questa sezione si applica solo ai cluster multiregionali. I cluster a regione singola non sono soggetti a questo costo. MultiRegion Write DPUs misura i byte totali scritti nella regione peer. Poiché Aurora DSQL replica in modo sincrono i dati scritti nell'area peered, il valore Write DPU è equivalente alla MultiRegion Write DPU. Aurora DSQL carica questa DPU nella regione in cui ha avuto origine la scrittura, non nella regione peer. ``` MultiRegionWriteDPU = WriteDPU ``` ## Monitoraggio dell'utilizzo della DPU con CloudWatch Aurora DSQL pubblica i parametri di utilizzo su Amazon CloudWatch, consentendoti di monitorare il consumo quasi in tempo reale. ### Metriche DPU disponibili **Metriche DPU** | CloudWatch parametro | Description | Dimensione | | --- | --- | --- | | WriteDPU | Componente di utilizzo della scrittura | ClusterId | | ReadDPU | Leggi il componente di utilizzo | ClusterId | | ComputeDPU | Componente di elaborazione delle query | ClusterId | | MultiRegionWriteDPU | Replica multiregione (solo cluster multiregione) | ClusterId | | TotalDPU | Somma di tutti i componenti della DPU | ClusterId | ### Visualizzazione delle metriche DPU **Per visualizzare le metriche DPU in CloudWatch** 1. Apri la [CloudWatch console](https://console.aws.amazon.com/cloudwatch). 1. Vai a **Metriche**, quindi a **AuroradSQL**, quindi. **ClusterId** 1. Seleziona il cluster e le metriche DPU che desideri monitorare. **Suggerimento** Utilizza la statistica **Sum** for DPU per visualizzare l'utilizzo totale in un periodo di tempo. Aggiungi l'etichetta **LAST** per vedere il valore più recente. ### Metriche di osservabilità aggiuntive Per un elenco completo delle metriche e delle funzionalità di monitoraggio di Aurora DSQL, vedere. [Monitoraggio e registrazione dei log per Aurora DSQL](monitoring-overview.md) **Parametri di osservabilità** | Metrica | Description | | --- | --- | | ClusterStorageSize | Dimensione di archiviazione corrente in byte | | TotalTransactions | Transazioni totali eseguite | | ReadOnlyTransactions | Transazioni di sola lettura eseguite | | QueryTimeouts | Interrogazioni che hanno superato il limite di tempo | | OccConflicts | Transazioni interrotte a causa di conflitti OCC | | BytesWritten | Byte non elaborati scritti nello storage | | BytesRead | Byte non elaborati letti dallo storage | ## Utilizzo di EXPLAIN ANALYZE VERBOSE per la consapevolezza dei costi Aurora DSQL si estende `EXPLAIN ANALYZE VERBOSE` per includere una stima dell'utilizzo della DPU a livello di dichiarazione alla fine dell'output. Ciò offre una visibilità immediata sui costi delle query, aiutandoti a identificare i fattori di costo del carico di lavoro, ottimizzare le prestazioni delle query e prevedere meglio l'utilizzo delle risorse. **Nota** È necessario utilizzare `EXPLAIN ANALYZE VERBOSE` (con VERBOSE) per visualizzare le stime della DPU. Un piano `EXPLAIN ANALYZE` senza VERBOSE non mostra le informazioni sulla DPU. ### Esempio 1: interrogazione 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 ``` In questo esempio, l'istruzione SELECT esegue una scansione solo indicizzata, quindi la maggior parte del costo proviene da Read DPU (0.04312), che rappresenta i dati recuperati dallo storage, e Compute DPU (0,01607), che riflette le risorse di elaborazione utilizzate per elaborare e restituire i risultati. Non esiste una DPU di scrittura poiché la query non modifica i dati. La DPU totale (0,05919) è la somma di Compute\+Read\+Write. ### Esempio 2: query 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 ``` Questa istruzione esegue principalmente le scritture, quindi la maggior parte del costo è associata a Write DPU. La Compute DPU (0,01550) rappresenta il lavoro svolto per elaborare e inserire i valori. La Read DPU (0.00307) riflette le letture secondarie del sistema (per le ricerche nel catalogo o il controllo degli indici). Notate i valori minimi delle transazioni indicati tra parentesi accanto a Lettura e scrittura. DPUs Questi minimi si applicano a livello di transazione, il che significa che la DPU totale di lettura o scrittura per un'intera transazione non è mai inferiore a questi valori. Se utilizzi `EXPLAIN ANALYZE VERBOSE` la modalità di previsione dei costi e questa è l'unica dichiarazione della transazione, utilizza i valori minimi della transazione anziché le stime non elaborate dei rendiconti. Se la transazione contiene più rendiconti, i minimi si applicano all'aggregato di tutti i rendiconti. Poiché `EXPLAIN ANALYZE VERBOSE` i report stimati a livello di rendiconto durante la fatturazione applicano i minimi a livello di transazione, i valori potrebbero non corrispondere esattamente alle metriche o ai dati di fatturazione. CloudWatch ### Utilizzo delle informazioni DPU per l'ottimizzazione Le stime DPU per dichiarazione offrono un modo efficace per ottimizzare le query oltre il semplice tempo di esecuzione. Casi di utilizzo comune comprendono: + **Consapevolezza dei costi:** scopri quanto è costosa una query rispetto alle altre. + **Ottimizzazione dello schema:** confronta l'impatto degli indici o delle modifiche allo schema sulle prestazioni e sull'efficienza delle risorse. + **Pianificazione del budget:** stima del costo del carico di lavoro in base all'utilizzo della DPU osservato. + **Confronto tra query:** valuta gli approcci di interrogazione alternativi in base al consumo relativo di DPU. ### Interpretazione delle informazioni sulla DPU Tieni a mente le seguenti best practice quando utilizzi dati DPU da: `EXPLAIN ANALYZE VERBOSE` + **Usalo in modo direzionale:** considera la DPU segnalata come un modo per comprendere il costo *relativo* di una query piuttosto che come una corrispondenza esatta con le CloudWatch metriche o i dati di fatturazione. Le differenze sono previste perché `EXPLAIN ANALYZE VERBOSE` riporta i costi a livello di rendiconto, mentre aggrega l'attività a livello di transazione. CloudWatch CloudWatch include anche operazioni in background (come ANALYZE o compattazioni asincrone) e il sovraccarico delle transazioni (/) che esclude intenzionalmente. `BEGIN` `COMMIT` `EXPLAIN ANALYZE VERBOSE` + **Esegui test con dati rappresentativi per la dimostrazione dei concetti:** quando esegui un proof of concept per valutare i costi, assicurati che le tabelle contengano volumi e distribuzioni di dati simili al carico di lavoro di produzione previsto. Le stime della DPU, basate su tabelle vuote `EXPLAIN ANALYZE VERBOSE` o CloudWatch scarsamente popolate, non rifletteranno i costi reali. + La **variabilità della DPU tra le esecuzioni è normale nei sistemi distribuiti** e non indica errori. Fattori come la memorizzazione nella cache, le modifiche al piano di esecuzione, la concorrenza, le operazioni in background come l'analisi asincrona o i cambiamenti nella distribuzione dei dati possono tutti far sì che la stessa query utilizzi risorse diverse da un'esecuzione all'altra. + **Operazioni di piccole dimensioni in batch:** se il carico di lavoro genera molte istruzioni di piccole dimensioni, valuta la possibilità di raggrupparle in batch in operazioni di scrittura più grandi all'interno di una singola transazione (le modifiche non devono superare i 10 MB per transazione, sebbene le letture siano limitate solo dal timeout della transazione di 5 minuti). In questo modo si ammortizzano i minimi delle transazioni per una maggiore quantità di lavoro e si ottengono stime dei costi più significative. + **Utilizzabile per il tuning, non per la fatturazione:** DPU Data In `EXPLAIN ANALYZE VERBOSE` è progettato per la consapevolezza dei costi, l'ottimizzazione delle query e l'ottimizzazione. Non è una metrica adatta alla fatturazione. Affidati sempre alle CloudWatch metriche o ai rapporti di fatturazione mensili per dati autorevoli su costi e utilizzo. ## Le migliori pratiche di stima dei costi + **Monitora prima di ottimizzare:** utilizza le CloudWatch metriche per comprendere il modello di utilizzo attuale prima di prendere decisioni di ottimizzazione. Per informazioni dettagliate, vedi [Monitoraggio dell'utilizzo della DPU con CloudWatch](#billing-cloudwatch-monitoring). + **Concentrati sull'efficienza delle transazioni:** poiché a livello di transazione si applicano dei requisiti minimi, raggruppa le operazioni correlate per ammortizzare i costi minimi. + **Usa EXPLAIN ANALYZE VERBOSE durante lo sviluppo:** `EXPLAIN ANALYZE VERBOSE` esegui query critiche durante lo sviluppo per comprenderne le caratteristiche di costo. Quando esegui una dimostrazione concettuale per valutare i costi, esegui test con tabelle con volumi di dati e distribuzioni rappresentativi: le stime basate su tabelle vuote o scarsamente popolate non rifletteranno i costi di produzione. Per informazioni dettagliate, vedi [Utilizzo di EXPLAIN ANALYZE VERBOSE per la consapevolezza dei costi](#billing-explain-analyze). + **Imposta CloudWatch allarmi: crea allarmi** in base alle metriche della DPU per ricevere notifiche in caso di picchi di utilizzo imprevisti.