Preguntas frecuentes sobre precios de BigQuery

Depende del workload. Si tenías slots inactivos con flat-rate, Editions con Autoscaling puede reducir tu factura de cómputo. Compressed Storage puede bajar la parte de almacenamiento. Analízalo como TCO, no como una línea aislada.

Son cosas distintas. Un commit de BigQuery te da un mejor precio por slot/hora. Un commit a 3 años te da aproximadamente un 40% de descuento en los costos de análisis. El precio del almacenamiento no tiene descuento.

Sí. El comportamiento de Editions, en especial los mínimos de Autoscaling y el scale-down de un minuto, puede cambiar los costos de formas poco evidentes. Haz una POC con un workload representativo antes de comprometerte.

Los workloads estables, de larga duración y que escanean muchos datos son ideales para Editions. Las consultas cortas y con picos suelen ser más baratas en on-demand, porque Autoscaling asigna bloques de 100 slots y factura un mínimo de un minuto completo.

Depende de la compresibilidad. Los datos con muchos strings se comprimen bien. Los datos con muchos enteros se comprimen mal. Tenemos una consulta en este gist de GitHub que compara tus opciones: https://gist.github.com/sayle-doit/264d28dd990c478beb90b90ac3923681

Sí. Duplica nuestra hoja BigQuery Current Usage Analysis Tool y sigue las instrucciones: https://docs.google.com/spreadsheets/d/1Sv6SzATtAyGYID2Wg0qGdcpLfe7YdOsH4dFKHHtS59c/edit

Sí. Un proyecto puede funcionar en on-demand, otro en Standard Edition y otro en Enterprise. Separar los workloads en distintos proyectos es una de las mejores palancas de optimización que tienes.

El SQL funciona tal cual. Si tienes código que compra slots Flex de forma dinámica, dejará de funcionar. El soporte para Terraform está en desarrollo, así que mientras tanto usa ignore_changes. Aun así, puede convenirte refactorizar para reducir el consumo total de slots.

Sí. Los commits flat-rate se convierten a Enterprise Edition al precio comprometido durante toda su vigencia. Los slots por encima de tu línea base se facturan al precio estándar de Enterprise. El Autoscaler puede escalar hasta el máximo que definas.

No. Las herramientas de Google bloquean activamente Compressed Storage cuando existe una reservación flat-rate. Necesitas proyectos con Editions o puramente on-demand.

Sin comprimir. No hay ventaja en costos de cómputo al consultar datos comprimidos desde un proyecto on-demand. El ahorro es únicamente en almacenamiento.

No. El mecanismo de almacenamiento a largo plazo sigue aplicando tanto a datos comprimidos como sin comprimir.

Sí. Las consultas en Editions tienen un mínimo de un minuto debido al scale-down de un minuto del Autoscaler. Una consulta de 10 segundos cuesta un minuto de slots.

En Google Cloud Console, abre Monitoring, ve a Metric Explorer y busca las métricas de slots. Los clientes de DoiT pueden abrir un ticket y revisarlo con un especialista en BigQuery.

Sí. Define una línea base con los slots que siempre usas y un máximo en el techo con el que te sientas cómodo. Si tienes períodos de inactividad, pon la línea base en 0 para no pagar por slots asignados sin usar.

dbt en BigQuery es intensivo en cómputo. El cómputo ahora es más caro en Editions, así que los workloads de dbt suelen costar más, a menos que ajustes el uso de slots y los aísles en el proyecto adecuado.

El time-travel no se puede desactivar, pero puedes reducir la ventana de 7 días a 3. El fail-safe sí se puede desactivar. Restaurar desde fail-safe requiere un ticket de soporte de Google Cloud.

Sí. Las actualizaciones de metadatos de BigLake, por ejemplo, consumen slot-horas pero escanean cero bytes, lo que significa que son gratis en on-demand. En Editions, pagas por los slots. Aísla esos trabajos en un proyecto on-demand.