Optimizar Consultas

¡Hubble tiene terabytes de datos por explorar—eso es mucho dato! Con acceso a tantos datos al alcance de tu mano, es crucial optimizar el rendimiento de tus consultas.

Una de las fortalezas de BigQuery también es su trampa: tienes acceso a capacidades de cómputo enormes, pero pagas por lo que usas. Si optimizas tus consultas, tendrás acceso a potentes información a una fracción del costo de mantener un almacén de datos tú mismo. Sin embargo, es fácil incurrir en costos elevados si no tienes cuidado.

Prácticas recomendadas

Presta atención a la estructura de la tabla.

Las tablas grandes están particionadas y agrupadas según patrones de acceso comunes. Recorta solo las particiones que necesitas y filtra o agrega por campos agrupados cuando sea posible.

Unir tablas por cadenas es costoso. Evita unirte por claves de cadenas si puedes utilizar claves de enteros en su lugar.

Lee la documentación sobre Ver Metadatos para aprender más sobre los metadatos de la tabla.

Ejemplo - Perfilando Tipos de Operaciones

Supongamos que deseas perfilar los tipos de operaciones enviados a la Stellar Network mensualmente. ======== Supongamos que deseas perfilar los tipos de operaciones enviados a la Stellar Network mensualmente.

# Inefficient query
select datetime_trunc(batch_run_date, month) as `month`,
  type_string,
  count(id) as count_operations
from `crypto-stellar.crypto_stellar.history_operations`
group by `month`,
  type_string
order by `month`

La tabla history_operations está particionada por batch_run_date y agrupada por transaction_id, source_account y type. Los costos de consulta se reducen enormemente al recortar particiones no utilizadas. En este caso, podrías filtrar las operaciones enviadas antes de 2023. Esto reduce el costo de la consulta en 4x.

# Prune out partitions you do not need
select datetime_trunc(batch_run_date, month) as `month`,
  type_string,
  count(id) as count_operations
from `crypto-stellar.crypto_stellar.history_operations`
-- batch_run_date is a datetime object, formatted as ISO 8601
where batch_run_date > '2023-01-01T00:00:00'
group by `month`,
  type_string
order by `month`

Cambiar el campo de agregación a type, que es un campo agrupado, reducirá los costos en un tercio:

# Prune out partitions you do not need
# Aggregate by clustered field, `type`
select datetime_trunc(batch_run_date, month) as `month`,
  `type`,
  count(id) as count_operations
from `crypto-stellar.crypto_stellar.history_operations`
where batch_run_date >= '2023-01-01T00:00:00'
group by `month`,
  `type`
order by `month`

Resumen de Rendimiento

Al recortar particiones y agregar en un campo agrupado, los costos de procesamiento de consultas se reducen en un factor de 8.

	Bytes Procesados	Costo
Consulta Original	408.1 GB	$2.041
Consulta Mejorada 1	83.06 GB	$0.415
Consulta Mejorada 2	54.8 GB	$0.274

Sé lo más específico posible.

No escribas declaraciones SELECT * a menos que necesites que se devuelvan todas las columnas en la respuesta de la consulta. Dado que BigQuery es una base de datos columnar, puede omitir la lectura de datos completamente si las columnas no están incluidas en la declaración select. Cuanto más ancha es la tabla, más crucial es seleccionar solo lo que necesitas.

Ejemplo - Tasas de Transacción

Supongamos que necesitas ver las tarifas de todas las transacciones enviadas en mayo de 2023. ¿Qué pasa si escribes un SELECT *?

# Inefficient query
select *
from `crypto-stellar.crypto_stellar.history_transactions`
where batch_run_date >= '2023-05-01'
  and batch_run_date < '2023-06-01'

¡Se estima que esta consulta costará casi $4!

Si solo necesitas información sobre tarifas, puedes filtrar los datos, reduciendo los costos de consulta en un factor de 50x:

# Select only the columns you need
select id,
  transaction_hash,
  ledger_sequence,
  account,
  fee_account,
  max_fee,
  fee_charged,
  new_max_fee
from `crypto-stellar.crypto_stellar.history_transactions`
where batch_run_date >= '2023-05-01'
  and batch_run_date < '2023-06-01'

Resumen de Rendimiento

Hubble almacena tablas amplias. El rendimiento de las consultas mejora enormemente al seleccionar solo los datos que necesitas. Este principio es crítico al explorar las tablas de operaciones y transacciones, que son las más grandes en Hubble.

	Bytes Procesados	Costo
Consulta Original	769.45 GB	$3.847
Consulta Mejorada	16.6 GB	$0.083

consejo

La consola de BigQuery te permite previsualizar los datos de la tabla de forma gratuita, lo que equivale a escribir un SELECT *. Haz clic en el nombre de la tabla y aparecerá el panel de vista previa.

Filtra temprano.

Al escribir consultas complejas, filtra los datos lo antes posible. Coloca las cláusulas WHERE y GROUP BY en la parte superior de la consulta para reducir la cantidad de datos escaneados.

advertencia

Las cláusulas LIMIT aceleran el rendimiento, pero no reducen la cantidad de datos escaneados. Solo los resultados finales devueltos al usuario están limitados. Usa con precaución.

Coloca las transformaciones y funciones matemáticas al final de la consulta cuando sea posible. Funciones como TRIM(), CAST(), SUM() y REGEXP_* son intensivas en recursos y deben aplicarse solo a los resultados finales de la tabla.

Estimando Costos

Si necesitas estimar costos antes de ejecutar una consulta, tienes varias opciones disponibles:

Consola de BigQuery

La Consola de BigQuery viene con un validador de consultas incorporado. Verifica la sintaxis de la consulta y proporciona una estimación del número de bytes procesados. El validador se puede encontrar en la esquina superior derecha del Editor de Consultas, junto a la marca de verificación verde.

Para calcular el costo de la consulta, convierte el número de bytes procesados en terabytes y multiplica el resultado por $5:

(bytes estimados leídos / 1TB) * $5

Pega la siguiente consulta en el Editor para ver los bytes procesados estimados.

select timestamp_trunc(closed_at, month) as month,
  sum(tx_set_operation_count) as total_operations
from `crypto-stellar.crypto_stellar.history_ledgers`
where batch_run_date >= '2023-01-01T00:00:00'
  and batch_run_date < '2023-06-01T00:00:00'
  and closed_at >= '2023-01-01T00:00:00'
  and closed_at < '2023-06-01T00:00:00'
group by month

El validador estima que se leerán 51.95MB de datos.

0.00005195 TB * $5 =$ 0.000259. Parámetro de Configuración dryRun

parámetro de configuración dryRun

Si envías una consulta a través de una biblioteca cliente de BigQuery, puedes realizar una ejecución en seco para estimar los bytes totales procesados antes de enviar el trabajo de consulta.

Python

from google.cloud import bigquery

# Construct a BigQuery client object
client = bigquery.Client()

# Set dry run to True to get bytes processed
job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Pass in job config
sql = """
    select timestamp_trunc(closed_at, month) as month,
      sum(tx_set_operation_count) as total_operations
    from `crypto-stellar.crypto_stellar.history_ledgers`
    where batch_run_date >= '2023-01-01T00:00:00'
      and batch_run_date < '2023-06-01T00:00:00'
      and closed_at >= '2023-01-01T00:00:00+00'
      and closed_at < '2023-06-01T00:00:00'
    group by month
"""

# Make API request
query_job = client.query((sql), job_config = job_config)

# Calculate the cost
cost = (query_job.total_bytes_processed / 1000000000000) * 5

print(f'This query will process {query_job.total_bytes_processed} bytes')
print(f'This query will cost approximately ${cost}')

También hay complementos de IDE que pueden aproximar el costo.

Para obtener más información sobre los costos de consulta, lee la documentación de BigQuery.

Prácticas recomendadas​

Presta atención a la estructura de la tabla.​

Ejemplo - Perfilando Tipos de Operaciones​

Sé lo más específico posible.​

Ejemplo - Tasas de Transacción​

Filtra temprano.​

Estimando Costos​

Consola de BigQuery​

parámetro de configuración dryRun​