Funcionamiento de la facturación en Aurora DSQL
Con Amazon Aurora DSQL, solo paga por lo que usa sin costos iniciales. En esta sección, se explica cómo Aurora DSQL mide la actividad de la base de datos y la traduce en cargos en la factura de AWS. Para conocer los precios actuales por región, consulte la página de precios de Aurora DSQL
Temas
Funcionamiento de la medición
A diferencia de las bases de datos tradicionales que cobran por la capacidad aprovisionada, Aurora DSQL solo cobra por el trabajo real realizado. Aurora DSQL mide dos componentes principales: la actividad de la base de datos, medida en unidades de procesamiento distribuidas (DPU), y el almacenamiento, medido en GiB-mes.
Las DPU miden la cantidad de trabajo que realiza el sistema para ejecutar la carga de trabajo de SQL y están compuestas por tres componentes para clústeres de una sola región: DPU de computación, DPU de lectura y DPU de escritura. Los clústeres multirregionales incluyen un componente adicional de DPU de escritura multirregional. Para obtener más información, consulte Facturación multirregional.
En la siguiente tabla, se resumen los componentes que Aurora DSQL utiliza para medir la actividad de la base de datos. En la factura, solo se verán dos partidas: una para almacenamiento y otra para DPU, que es la suma de cada uno de los componentes individuales.
| Unidad de medición | Tipo de actividad | Medida |
|---|---|---|
| DPU de computación | Procesamiento de consultas | Tiempo de CPU |
| DPU de lectura | Lectura de datos desde la base de datos | Bytes leídos del almacenamiento |
| DPU de escritura | Escritura de datos en la base de datos | Bytes escritos en el almacenamiento |
| Almacenamiento | Almacenamiento de tablas | GiB-mes |
Medición de los componentes de la DPU explicada
Para cada transacción, Aurora DSQL calcula la DPU total como la suma de tres componentes: DPU de computación, DPU de lectura y DPU de escritura. En las secciones siguientes, se explica cómo Aurora DSQL mide cada componente.
Total DPU = ComputeDPU + ReadDPU + WriteDPU
ComputeDPU
Las DPU de computación se miden con el tiempo total de procesamiento dedicado a ejecutar la consulta, incluidas las uniones, las funciones, las agregaciones, la clasificación y la planificación de las consultas. Como algunas partes de la consulta se pueden procesar en paralelo, la DPU de computación refleja la suma de todo el tiempo de procesamiento, no el tiempo de la consulta durante el reloj de pared.
La siguiente fórmula resume cómo calcular las DPU de computación:
ComputeDPU = Total Compute time (in seconds)
WriteDPU
Para cada transacción, Aurora DSQL mide las DPU de escritura por el total de bytes escritos en el almacenamiento. Las DPU de escritura incluyen el total de datos escritos en la tabla base, así como cualquier índice secundario. Aurora DSQL factura cada fila escrita en la tabla base y en los índices secundarios que sea inferior a 128 bytes como si fuera de 128 bytes. Aurora DSQL factura una transacción de escritura que escribe menos de 1024 bytes como si escribiera 1024 bytes.
nota
Las operaciones de escritura también conllevan gastos de ReadDPU, ya que Aurora DSQL lee el índice de la clave principal para comprobar la exclusividad antes de escribir.
Las siguientes fórmulas muestran los pasos para calcular las DPU de escritura:
Paso 1: Calcular los bytes escritos
Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written
Paso 2: Calcular WriteDPU
WriteDPU = max(Bytes Written, 1024) × 0.00004883
ReadDPU
Para cada transacción, Aurora DSQL mide las DPU de lectura por el total de bytes escritos del almacenamiento. Las DPU de lectura incluyen los datos leídos de la tabla base, así como cualquier índice secundario.
Mínimo por partición: Aurora DSQL mide los bytes de lectura por partición de almacenamiento, no por fila. Si una solicitud de lectura a una partición de almacenamiento devuelve menos de 128 bytes, Aurora DSQL la redondea a 128 bytes. Por ejemplo, si la consulta lee desde 4 particiones (200 bytes de una partición y 50 bytes de cada una de las otras tres), las tres lecturas de 50 bytes se redondean cada una a 128 bytes, lo que da como resultado un total de 200 + 128 + 128 + 128 = 584 bytes facturados.
Transacción mínima: Aurora DSQL factura una transacción de lectura que lee menos de 2048 bytes en total como si leyera 2048 bytes.
Las siguientes fórmulas muestran los pasos para calcular las DPU de lectura:
Paso 1: Calcular los bytes leídos
Bytes Read = # of rows read × size of each row
nota
La lectura de bytes real depende de cómo se distribuyan los datos entre las particiones de almacenamiento, ya que se aplica el mínimo de 128 bytes por partición. Si todos los tamaños de fila son superiores a 128 bytes, simplemente puede multiplicar el número de filas leídas por el tamaño de cada fila.
Paso 2: Calcular ReadDPU
ReadDPU = max(Bytes Read, 2048) × 0.00000183105
Ejemplos de facturación
En los siguientes ejemplos, se muestra cómo Aurora DSQL calcula DPU para operaciones comunes. Los valores de costos en estos ejemplos usan el precio de la región us-east-1. Para conocer los precios en otras regiones, consulte la página de precios de Aurora DSQL
En este ejemplo, se muestra un cálculo de ReadDPU de búsqueda de puntos en el que se aplica el mínimo de transacciones.
Esquema:
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
Query:
SELECT * FROM orders WHERE customer_id = 'cust-12345';
Escenario: la consulta devuelve 5 filas, cada una de aproximadamente 100 bytes. Suponiendo que todas las filas residen en una partición de almacenamiento, el total de bytes leídos es de 5 × 100 = 500 bytes. Como 500 bytes superan el mínimo de 128 bytes por partición, no se aplica ningún mínimo por partición.
Cálculo de ReadDPU:
ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
se aplica el mínimo de transacción de 2048 bytes, ya que 500 < 2048.
Costo de transacción total:
suponiendo que el tiempo de ejecución de la consulta sea de 3 ms (0,003 segundos):
ComputeDPU: 0.003 ReadDPU: 0.00375 WriteDPU: 0.0 ------------------- Total DPU: 0.00675
Esquema:
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'
Query:
SELECT * FROM orders WHERE customer_id = 'cust-12345' AND total_amount > 500.00;
Escenario: la consulta analiza 100 filas en busca del cliente “cust-12345”, pero el filtro total_amount > 500.00 reduce el resultado a solo 10 filas devueltas. Aurora DSQL factura las 100 filas analizadas. Suponiendo que todas las filas residen en una partición de almacenamiento, el total de bytes leídos es de 100 × 100 = 10 000 bytes.
Cálculo de ReadDPU:
ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831
dado que 10 000 bytes superan el mínimo de transacción de 2048 bytes, se utilizan los bytes reales leídos.
Costo de transacción total:
suponiendo que el tiempo de ejecución de la consulta sea de 8 ms (0,008 segundos):
ComputeDPU: 0.008 ReadDPU: 0.01831 WriteDPU: 0.0 ------------------- Total DPU: 0.02631
importante
para minimizar los costos de ReadDPU, diseñe consultas e índices para analizar solo las filas que necesite. En este ejemplo, agregar un índice en (customer_id, total_amount) podría permitir que la consulta analice menos filas.
Esquema:
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
Query:
INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-67890', 150.00, 'pending');
Escenario: inserte 1 fila, aproximadamente 100 bytes.
Cálculo de WriteDPU:
Paso 1: Calcular los bytes escritos:
1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes
Paso 2: Calcular WriteDPU:
WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05
se aplica el mínimo de transacción de 1024 bytes, ya que 128 < 1024.
ReadDPU (comprobación de clave principal):
Aurora DSQL lee el índice de clave principal para comprobar la exclusividad antes de escribir. Esto implica el cargo mínimo de lectura de la transacción.
ReadDPU = 0.00375 (transaction minimum)
Costo de transacción total:
suponiendo que el tiempo de ejecución de la consulta sea de 8 ms (0,008 segundos):
ComputeDPU: 0.008 ReadDPU: 0.00375 WriteDPU: 0.05 ------------------- Total DPU: 0.06175
Esquema:
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
Query:
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');
Escenario: inserte 100 filas, cada una de aproximadamente 100 bytes.
Cálculo de WriteDPU:
Paso 1: Calcular los bytes escritos:
100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes
Paso 2: Calcular WriteDPU:
WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625
ReadDPU (comprobación de clave principal):
Aurora DSQL lee el índice de clave principal para cada fila para comprobar la exclusividad. Suponiendo que 100 búsquedas de claves residen en una partición de almacenamiento, el total de bytes leídos es de 100 × 16 bytes (UUID) = 1600 bytes:
ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
se aplica el mínimo de transacción de 2048 bytes, ya que 1600 < 2048.
Costo de transacción total:
suponiendo que el tiempo de ejecución de la consulta sea de 80 ms (0,08 segundos):
ComputeDPU: 0.08 ReadDPU: 0.00375 WriteDPU: 0.625 ------------------- Total DPU: 0.70875
facturación multirregional
Los clústeres multirregionales incorporan un componente adicional de DPU de escritura multirregional, además de las DPU de computación, lectura y escritura estándar. Esta sección se aplica solo a los clústeres multirregionales. Los clústeres de una sola región no incurren en este cargo.
Las DPU de escritura multirregionales miden el total de bytes escritos en la región emparejada. Dado que Aurora DSQL replica de forma sincrónica los datos que se escriben en la región emparejada, el valor de la DPU de escritura multirregional equivale a la DPU de escritura. Aurora DSQL carga esta DPU en la región en la que se originó la escritura, no en la región emparejada.
MultiRegionWriteDPU = WriteDPU
Supervisión del uso de DPU con CloudWatch
Aurora DSQL publica métricas de uso en Amazon CloudWatch, lo que permite supervisar el consumo casi en tiempo real.
Métricas de DPU disponibles
| Métrica de CloudWatch | Descripción | Dimensión |
|---|---|---|
WriteDPU |
Componente de uso de escritura | ClusterId |
ReadDPU |
Componente de uso de lectura | ClusterId |
ComputeDPU |
Componente de procesamiento de consultas | ClusterId |
MultiRegionWriteDPU |
Replicación multirregional (solo clústeres multirregionales). | ClusterId |
TotalDPU |
Suma de todos los componentes de la DPU | ClusterId |
Visualización de métricas de DPU
Visualización de métricas de DPU en CloudWatch
-
Vaya a Métricas, después a AuroraDSQL y, a continuación, ClusterId.
-
Seleccione el clúster y las métricas de DPU que desea supervisar.
sugerencia
Use la estadística Suma de las métricas de DPU para ver el uso total durante un periodo de tiempo. Agregue la ÚLTIMA etiqueta para ver el valor más reciente.
Métricas de observabilidad adicionales
Para ver una lista completa de las métricas de Aurora DSQL y capacidades de supervisión, consulte Supervisión y registro para Aurora DSQL.
| Métrica | Descripción |
|---|---|
ClusterStorageSize |
Tamaño de almacenamiento actual en bytes |
TotalTransactions |
Transacciones totales ejecutadas |
ReadOnlyTransactions |
Transacciones de solo lectura ejecutadas |
QueryTimeouts |
Consultas que superaron el límite de tiempo |
OccConflicts |
Transacciones canceladas debido a conflictos de OCC |
BytesWritten |
Bytes sin procesar escritos en el almacenamiento |
BytesRead |
Bytes sin procesar leídos del almacenamiento |
Uso de EXPLAIN ANALYZE VERBOSE para conocer los costos
Aurora DSQL amplía EXPLAIN ANALYZE VERBOSE para incluir una estimación del uso de la DPU por instrucción al final del resultado. Esto proporciona una visibilidad inmediata del costo de las consultas, lo que le ayuda a identificar los factores de costo de la carga de trabajo, ajustar el rendimiento de las consultas y pronosticar mejor el uso de los recursos.
nota
Debe usar EXPLAIN ANALYZE VERBOSE (con VERBOSE) para ver las estimaciones de DPU. Un EXPLAIN ANALYZE plano sin VERBOSE no muestra la información de la DPU.
Ejemplo 1: Consulta 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
En este ejemplo, la instrucción SELECT realiza un análisis solo de índices, por lo que la mayor parte del costo proviene de la DPU de lectura (0,04312), que representa los datos recuperados del almacenamiento y Compute DPU (0,01607), que refleja los recursos informáticos utilizados para procesar y devolver los resultados. No hay ninguna DPU de escritura, ya que la consulta no modifica los datos. La DPU total (0,05919) es la suma de Informática + Lectura + Escritura.
Ejemplo 2: Consulta 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
Esta instrucción realiza principalmente escrituras, por lo que la mayor parte del costo está asociado a una DPU de escritura. La DPU de informática (0,01550) representa el trabajo realizado para procesar e insertar los valores. La DPU de lectura (0,00307) refleja las lecturas menores del sistema (para búsquedas en catálogos o comprobaciones de índices).
Observe los mínimos de transacciones que se muestran entre paréntesis junto a las DPU de lectura y escritura. Estos mínimos se aplican por transacción, lo que significa que la DPU total de lectura o escritura de una transacción completa nunca es inferior a estos valores. Si utiliza EXPLAIN ANALYZE VERBOSE para pronosticar los costos y esta es la única instrucción de la transacción, utilice los valores mínimos de la transacción en lugar de las estimaciones de instrucciones sin procesar. Si la transacción contiene varias instrucciones, los mínimos se aplican al agregado de todas las instrucciones. Como EXPLAIN ANALYZE VERBOSE informa de las estimaciones por instrucción mientras que la facturación aplica los mínimos por transacción, los valores puede que no coincidan exactamente con las métricas de CloudWatch o los datos de facturación.
Uso de la información de la DPU para la optimización
Las estimaciones de la DPU por instrucción ofrecen una forma eficaz de optimizar las consultas más allá del tiempo de ejecución. Los casos de uso comunes incluyen:
-
Conocimiento de los costos: comprenda lo caro que es una consulta en relación con otras.
-
Optimización del esquema: compare el impacto de los índices o los cambios en el esquema en el rendimiento y en la eficiencia de los recursos.
-
Planificación presupuestaria: calcule el costo de la carga de trabajo en función del uso observado de la DPU.
-
Comparación de consultas: evalúe los enfoques de consulta alternativos según su consumo relativo de DPU.
Interpretación de la información de la DPU
Tenga en cuenta las siguientes prácticas recomendadas al utilizar datos de DPU de EXPLAIN ANALYZE
VERBOSE:
-
Úselo de forma direccional: trate la DPU de la que se ha informado como una forma de entender el costo relativo de una consulta, en lugar de una coincidencia exacta con las métricas o los datos de facturación de CloudWatch. Se esperan diferencias porque
EXPLAIN ANALYZE VERBOSEinforma del costo por instrucción, mientras que CloudWatch agrega la actividad por transacción. CloudWatch también incluye operaciones en segundo plano (como ANALYZE o compactaciones asíncronas) y gastos de transacción (BEGIN/COMMIT) queEXPLAIN ANALYZE VERBOSEexcluye intencionadamente. -
Realice pruebas con datos representativos para pruebas de concepto: cuando ejecute una prueba de concepto para evaluar los costos, asegúrese de que las tablas contengan volúmenes y distribuciones de datos similares a la carga de trabajo de producción prevista. Las estimaciones de la DPU (ya sean métricas de
EXPLAIN ANALYZE VERBOSEo de CloudWatch) que se basan en tablas vacías o poco pobladas no reflejarán los costos reales. -
La variabilidad de la DPU entre las ejecuciones es normal en los sistemas distribuidos y no indica errores. Factores como el almacenamiento en caché, los cambios en el plan de ejecución, la simultaneidad, las operaciones en segundo plano como ANALYZE asíncrona o los cambios en la distribución de los datos pueden provocar que la misma consulta consuma recursos diferentes de una ejecución a la siguiente.
-
Operaciones pequeñas por lotes: si la carga de trabajo emite muchas instrucciones pequeñas, considere agruparlas por lotes en operaciones de escritura más grandes dentro de una sola transacción (las modificaciones no deben superar los 10 MB por transacción, aunque las lecturas solo están limitadas por el tiempo de espera de transacción de 5 minutos). Esto amortiza los mínimos de transacciones en más trabajo y produce estimaciones de costos más significativas.
-
Úselo para ajustar, no para facturar: los datos de la DPU en
EXPLAIN ANALYZE VERBOSEestán diseñados para conocer los costos, ajustar las consultas y optimizar. No es una métrica apta para la facturación. Confíe siempre en las métricas de CloudWatch o en los informes de facturación mensuales para obtener datos fiables sobre costos y uso.
Prácticas recomendadas de estimación de costos
-
Supervise antes de optimizar: utilice las métricas de CloudWatch para comprender el patrón de uso actual antes de tomar decisiones de optimización. Para obtener más información, consulte Supervisión del uso de DPU con CloudWatch.
-
Céntrese en la eficiencia de las transacciones: dado que los mínimos se aplican por transacción, agrupe las operaciones relacionadas para amortizar los cargos mínimos.
-
Utilice EXPLAIN ANALYZE VERBOSE durante el desarrollo: ejecute
EXPLAIN ANALYZE VERBOSEen consultas críticas durante el desarrollo para comprender sus características de costos. Al realizar una prueba de concepto para evaluar los costos, compruébela con tablas con distribuciones y volúmenes de datos representativos; las estimaciones basadas en tablas vacías o con poca información no reflejarán los costos de producción. Para obtener más información, consulte Uso de EXPLAIN ANALYZE VERBOSE para conocer los costos. -
Configure alarmas de CloudWatch: cree alarmas en las métricas de la DPU para recibir notificaciones de picos de uso inesperados.