Precios de BigQuery

Esta página trata sobre precios de BigQuery.

Si te interesa, consulta los precios de BigQuery ML.

Si quieres, también puedes consultar los precios de BigQuery Data Transfer Service.

Información general

BigQuery pone a tu disposición opciones de precios escalables y flexibles que se adaptan a tus necesidades técnicas y a tu presupuesto.

Los costes del almacenamiento se basan en la cantidad de datos que se almacenan en BigQuery. Las tarifas de almacenamiento pueden ser de dos tipos:

  • Activo: te cobraremos una tarifa mensual por los datos almacenados en tablas o particiones que hayas modificado en los últimos 90 días.
  • A largo plazo: te cobraremos una tarifa mensual inferior por los datos almacenados en tablas o particiones que no se hayan modificado en los últimos 90 días.

Los costes de las consultas tienen dos modelos de precios entre los que puedes elegir:

  • Bajo demanda: es la opción más flexible, ya que se basa en la cantidad de datos procesados por cada consulta que ejecutas.
  • Tarifa fija: esta opción está destinada a los clientes que quieren costes predecibles. Aquellos que eligen esta tarifa compran recursos dedicados para el procesamiento de consultas y no se les cobran las consultas concretas.

Para obtener más información sobre los precios del almacenamiento y las consultas, echa un vistazo a la lista de SKUs de Google Cloud. Los precios de las consultas bajo demanda corresponden a los precios de análisis en la página de SKUs.

Resumen de precios

En la siguiente tabla se resumen los precios de BigQuery. Estas operaciones están sujetas a las cuotas y límites de BigQuery.

Información sobre la facturación

Cada proyecto que creas está vinculado a una cuenta de facturación. Todos los cargos que se aplican a BigQuery por las tareas que se ejecutan en el proyecto se facturan en dicha cuenta. Los costes de almacenamiento de BigQuery también se facturan en la cuenta de facturación vinculada.

Análisis de los datos de facturación

Puedes ver los costes y las tendencias de BigQuery en la página de informes de facturación de Google Cloud que se encuentra en la consola de Cloud. Para obtener más información sobre cómo analizar datos de facturación mediante informes, consulta el artículo que enseña a ver los informes de facturación y las tendencias de costes.

Para aprender a analizar estos datos en BigQuery, consulta la página Exportar datos de Facturación de Cloud a BigQuery de la documentación de Facturación de Cloud.

Operaciones gratuitas

En la siguiente tabla se muestran las operaciones de BigQuery que son gratuitas en todas las ubicaciones. Estas operaciones están sujetas a las cuotas y límites de BigQuery.

Operación Detalles
Cargar datos

Cuando cargas datos en BigQuery desde Cloud Storage, no te cobramos la operación de carga, pero sí el almacenamiento de dichos datos en Cloud Storage. Para obtener más información, consulta la sección sobre el almacenamiento de datos de la página de precios de Cloud Storage. Cuando los datos se cargan en BigQuery, pasan a estar sujetos a los precios de almacenamiento de dicho servicio. Para obtener más información, consulta el artículo sobre cómo cargar datos en BigQuery.

Cuando creas un conjunto de datos en BigQuery, tienes que elegir una ubicación para ellos. Si escoges US, puedes cargar datos en tablas del conjunto de datos desde un segmento de Cloud Storage de cualquier otra región. Actualmente no realizamos ningún cargo por la salida de Internet si cargas datos de otra región en un conjunto de datos de EE. UU.

Si eliges una ubicación que no sea US, tienes estas opciones:

  • Cargar los datos desde un segmento de Cloud Storage de esa misma región (el segmento puede ser multirregional o estar en la misma región que el conjunto de datos).
  • Copiar los datos en un segmento de la misma región.

Al copiar datos de una región de Cloud Storage a otra, se aplican los precios de red de dicho servicio.

Copiar datos No te cobramos nada por copiar una tabla, pero sí por almacenar la tabla nueva y la que hayas copiado. Para obtener más información, consulta el apartado sobre cómo copiar una tabla.
Exportar datos Cuando exportas datos desde BigQuery a Cloud Storage, no te cobramos la operación de exportación, pero sí el almacenamiento de los datos correspondientes en Cloud Storage. Para obtener más información, consulta la sección sobre el almacenamiento de datos de la página de precios de Cloud Storage o la página sobre cómo exportar datos de BigQuery.
Eliminar conjuntos de datos No te cobramos por eliminar conjuntos de datos.
Eliminar tablas, vistas, particiones y funciones No te cobramos por eliminar una tabla, una vista, particiones de tablas concretas o funciones definidas por el usuario.
Operaciones de metadatos No te cobramos por realizar las acciones list, get, patch, update y delete en llamadas. Entre los ejemplos de operaciones se incluyen los siguientes: mostrar conjuntos de datos, actualizar la lista de control de acceso de un conjunto de datos, actualizar la descripción de una tabla o mostrar las funciones definidas por el usuario de un conjunto de datos.
Leer pseudocolumnas No se te cobrará por consultar el contenido de las siguientes pseudocolumnas:

_TABLE_SUFFIX: se utiliza cuando realizas consultas en tablas comodín o para obtener la semántica del decorador de tablas en SQL estándar.
_PARTITIONDATE: se utiliza cuando realizas consultas en tablas con particiones por hora de ingestión.
_PARTITIONTIME: se utiliza cuando realizas consultas en tablas con particiones por hora de ingestión.
_FILE_NAME: se utiliza cuando realizas consultas en tablas basadas en fuentes de datos externas.
Leer metatablas No se te cobrará por consultar el contenido de las siguientes metatablas:

__PARTITIONS_SUMMARY__: se utiliza cuando obtienes los metadatos sobre las particiones de las tablas con particiones o de las tablas con particiones por hora de ingestión.
__TABLES_SUMMARY__: se utiliza cuando obtienes los metadatos sobre las tablas y las vistas de un conjunto de datos.
Crear, sustituir o llamar a funciones definidas por el usuario Actualmente, no se te cobra por crear, sustituir ni invocar funciones definidas por el usuario persistentes. Estas funciones están actualmente en versión beta y los precios pueden cambiar.

Límites de uso de Always Free

Como parte del nivel gratuito de Google Cloud, BigQuery ofrece determinados recursos sin coste dentro de un límite específico. Estos límites de uso gratuito están disponibles tanto durante como después del periodo de prueba gratuito. Si los superas una vez finalizado dicho periodo, se te cobrará el servicio según los precios que aparecen en esta página.

Recurso Límites mensuales de uso gratuito Detalles
Almacenamiento Los 10 primeros GB del mes son gratuitos. Los modelos de BigQuery ML y los datos de entrenamiento almacenados en BigQuery están incluidos en el nivel gratuito de almacenamiento de BigQuery.
Consultas (análisis) El primer TB de datos de consultas procesado del mes es gratuito. Las consultas que utilizan las funciones de predicción, inspección y evaluación de BigQuery ML están incluidas en el nivel gratuito de análisis de BigQuery. Las consultas de BigQuery ML que incluyen declaraciones CREATE MODEL no lo están.
También hay una tarifa fija de BigQuery para clientes que tengan un gran volumen de consultas y prefieran pagar un coste mensual estable.
Consultas CREATE MODEL de BigQuery ML Los 10 primeros GB de datos procesados al mes mediante consultas con declaraciones CREATE MODEL son gratuitos. Las consultas CREATE MODEL de BigQuery ML son independientes del nivel gratuito de análisis de BigQuery y solo se aplican a los modelos integrados de BigQuery ML (aquellos que se han entrenado en BigQuery).

Precio de las consultas

El precio de las consultas hace referencia al coste de ejecutar los comandos de SQL, las funciones definidas por el usuario y las declaraciones del lenguaje de manipulación de datos (DML) y del lenguaje de definición de datos (DDL) que reúnen los requisitos.

BigQuery ofrece dos modelos de precios entre los que puedes elegir:

  • Los precios bajo demanda son flexibles y eficaces, porque solo pagas por las consultas que ejecutas.
  • La tarifa fija ofrece costes predecibles, uniformes y mensuales.

De forma predeterminada, se te factura de acuerdo con el modelo de precios bajo demanda. Puedes cambiar tu modelo de facturación a una tarifa fija o combinar los dos modelos de facturación en cada proyecto y ubicación.

Precios bajo demanda

En el modelo de precios bajo demanda de BigQuery, las consultas se cobran según una métrica: el número de bytes procesados (también denominados "bytes leídos"), tanto si los datos se almacenan en BigQuery como en una fuente de datos externa (por ejemplo, Cloud Storage, Drive o Cloud Bigtable), ya que se basa únicamente en el uso.

Los precios de las consultas bajo demanda son los siguientes:

Debes tener en cuenta los siguientes aspectos acerca de los cargos por las consultas:

  • BigQuery usa una estructura de datos en columnas. Te cobraremos en función del total de los datos procesados en las columnas que selecciones. Los datos totales por columna se calculan según los tipos de datos en cada una. Si quieres obtener más información, consulta la sección sobre cómo se calcula el tamaño de tus datos.
  • No se aplican cargos por las consultas que devuelven un error ni por aquellas que extraen resultados almacenados en caché.
  • Los cargos se redondean al megabyte más próximo, con un mínimo de 10 MB de datos procesados por tabla a la que se haga referencia en la consulta y un mínimo de 10 MB de datos procesados por consulta.
  • Si cancelas una tarea de consulta en ejecución, podemos cobrarte hasta alcanzar el coste total de la consulta si hubieras dejado que se ejecutara hasta el final.
  • Cuando ejecutas una consulta, te cobramos en función del total de datos procesados en las columnas que has seleccionado, incluso si has establecido un LIMIT concreto en los resultados.
  • Realizar particiones en tus tablas y agruparlas en clústeres puede servir para reducir la cantidad de datos que procesan las consultas. Recomendamos realizar estas dos acciones siempre que sea posible.
  • Los precios de las consultas bajo demanda corresponden a los precios de análisis en la página de SKUs de Google Cloud.

Controles de costes de las consultas bajo demanda

BigQuery proporciona mecanismos de control de costes que te permiten limitar los costes de las consultas. Dentro de esta función, puedes hacer lo siguiente:

Consultar datos de Cloud Storage

Cuando consultas una fuente de datos externa de BigQuery, se te cobra por el número de bytes leídos con la consulta. Para obtener más información, consulta los precios de las consultas. También se te cobrará por almacenar los datos en Cloud Storage. Para obtener más información, consulta los precios de Cloud Storage.

Hacer consultas en formatos con columnas de Cloud Storage

Si los datos externos están almacenados en ORC o Parquet, el número de bytes que se te cobrará está limitado a la cantidad de columnas que lea BigQuery. Como la consulta convierte los tipos de datos de las fuentes externas en tipos de datos de BigQuery, el número de lecturas de bytes se calcula en función del tamaño de los tipos de datos de BigQuery. Para obtener más información sobre las conversiones de tipos de datos, consulta las siguientes páginas:

Tarifa fija

BigQuery ofrece una tarifa fija a los clientes que prefieran pagar un coste estable por las consultas, en lugar de un precio bajo demanda por TB de datos procesados.

Si prefieres un modelo de precios con una tarifa fija, utiliza las reservas de BigQuery.

Cuando te das de alta en la tarifa fija, adquieres confirmaciones de ranuras; es decir, capacidad de procesamiento de consultas específica (que se mide en ranuras de BigQuery). Tus consultas consumen esta capacidad, pero no se te cobra por los bytes procesados. Si tu demanda de capacidad sobrepasa tu capacidad confirmada, BigQuery pondrá las ranuras en cola y no se te cobrará ninguna tarifa adicional. Consulta el artículo sobre las ranuras de BigQuery para obtener más información sobre cómo las utiliza esta herramienta para procesar consultas.

Tarifa fija:

  • Se aplica a los costes de las consultas, incluidas las declaraciones de BigQuery ML, DML y DDL.
  • No se aplica a los costes de almacenamiento, de ingestión de flujos ni de BI Engine.
  • Se compra como un recurso regional, por lo que las confirmaciones de ranuras que se compren en una o varias regiones no se pueden utilizar en otra (ni individual ni múltiple), ni tampoco se pueden mover.
  • Permite a los clientes aumentar las cuotas de simultaneidad por proyecto si se ponen en contacto con el equipo de Asistencia de Google Cloud.
  • Está disponible en confirmaciones por segundo, mensuales y anuales.
  • Se puede compartir en toda tu organización, por lo que no es necesario comprar confirmaciones de ranuras para cada proyecto.
  • Tiene un mínimo de 500 ranuras y se adquiere en incrementos de 500.
  • Se factura por segundo mientras dure tu confirmación.

Tarifa fija: confirmaciones mensuales

En la siguiente tabla figura el coste de la confirmación de ranuras mensual.

Tarifa fija: confirmaciones anuales

En la siguiente tabla figura el coste de la confirmación de ranuras anual.

Ranuras flexibles: confirmaciones a corto plazo

Las ranuras flexibles son un tipo de confirmación especial:

  • La confirmación solo dura 60 segundos.
  • A partir de ahí, puedes cancelar las ranuras flexibles cuando quieras.
  • Solo se te cobrará por los segundos que la confirmación haya estado desplegada.

En la siguiente tabla figura el coste de tu confirmación de ranuras flexibles.

Ranuras de prueba (promoción)

El 20 de mayo del 2020, BigQuery lanzó una promoción limitada para clientes nuevos y ya existentes. Los clientes que reúnen ciertos requisitos pueden comprar ranuras de prueba, que equivalen a una confirmación de 500 ranuras durante 6 meses a un precio considerablemente reducido.

Las ranuras de prueba funcionan de la siguiente manera:

  • Debes aceptar un compromiso de 6 meses.
  • No puedes cancelar el compromiso durante 182 días a partir del momento de la compra.
  • Solo puedes comprar 500 ranuras.
  • Puedes comprar otros tipos de confirmaciones y combinarlas con ranuras de prueba.
  • Las ranuras de prueba solo están disponibles en las multirregiones de EE. UU. y la Unión Europea.
  • Las ranuras de prueba tienen disponibilidad limitada y se distribuyen por orden de solicitud.
  • No hay diferencias de rendimiento ni de disponibilidad entre las ranuras de prueba y otros tipos de confirmaciones de ranuras.

Las ranuras de prueba están sujetas a una serie de requisitos y están disponibles para los clientes que se indican a continuación:

  • Clientes nuevos de Google Cloud que se registren en BigQuery.
  • Clientes ya existentes de Google Cloud que se registren en BigQuery.
  • Clientes ya existentes de BigQuery que no hayan gastado más de 500 USD al mes durante los últimos 3 meses.
  • Clientes que se hayan registrado con su dirección de correo electrónico de empresa.
  • La oferta solo está disponible para las compras que se hagan directamente desde Google; no se aceptan compras a través de distribuidores.

Si quieres obtener más información sobre las ranuras de prueba, consulta la información sobre planes de compromiso.

Si quieres participar en esta promoción, rellena el formulario de la promoción de ranuras de prueba de BigQuery y nos pondremos en contacto contigo en un plazo máximo de cinco días laborables.

Precio de almacenamiento

Una vez que los datos se cargan en BigQuery, te cobramos por almacenarlos. El precio del almacenamiento se basa en la cantidad de datos que hayas almacenado en tus tablas cuando están sin descomprimir.

El tamaño de los datos se calcula según los tipos de datos que haya en cada columna. Para obtener una explicación detallada de cómo calculamos esa cifra, consulta la sección correspondiente.

Almacenamiento activo

Los precios del almacenamiento activo son los siguientes:

El precio del almacenamiento se prorratea por MB y por segundo. Por ejemplo:

  • Si almacenas 100 MB durante medio mes, pagas 0,001 USD (la décima parte de un centavo).
  • Si almacenas 500 GB durante medio mes, pagas 5 USD.
  • Si almacenas 1 TB durante un mes, pagas 20 USD.

Almacenamiento a largo plazo

Si no se edita una tabla durante 90 días consecutivos, el precio de almacenamiento disminuirá automáticamente en un 50 % aproximadamente. Cuando se considera que una tabla está almacenada a largo plazo, no se produce ninguna degradación del rendimiento, la durabilidad, la disponibilidad ni de ninguna otra funcionalidad.

Cada partición de una tabla se valora por separado a la hora de establecer el precio del almacenamiento a largo plazo. Si no se ha modificado una partición en los últimos 90 días, se considera que sus datos están almacenados a largo plazo y se cobrará según el precio con descuento.

Los precios del almacenamiento a largo plazo son los siguientes:

Si se edita la tabla, el precio cambia al del almacenamiento habitual y el temporizador de 90 días empieza a contar de cero. El temporizador vuelve a cero si se realiza cualquier acción que modifique los datos de la tabla, incluidas las siguientes:

Acción Detalles
Cargar datos en una tabla Cualquier tarea de carga o de consulta que añada datos a una tabla de destino o la sobrescriba.
Copiar datos en una tabla Cualquier tarea de copia que añada datos a una tabla de destino o la sobrescriba.
Escribir los resultados de una consulta en una tabla Cualquier tarea de consulta que añada datos a una tabla de destino o la sobrescriba.
Usar el lenguaje de manipulación de datos (DML) Utilizar una declaración de DML para modificar datos de tablas.
Usar el lenguaje de definición de datos (DDL) Utilizar una declaración de DDL de tipo CREATE OR REPLACE TABLE para sustituir una tabla.
Transmitir datos a una tabla Ingestión de datos mediante la llamada tabledata.insertAll a la API.

Las demás acciones no provocan que el temporizador se reinicie. Por ejemplo:

  • Realizar una consulta a una tabla.
  • Crear una vista que realice una consulta a una tabla.
  • Exportar datos de una tabla.
  • Copiar una tabla a otra de destino.
  • Actualizar un recurso de tabla o aplicarle un parche.

En el caso de las tablas que superan el umbral de 90 días durante un ciclo de facturación, el precio se prorratea como corresponde.

El precio del almacenamiento a largo plazo solo se aplica a los datos almacenados en BigQuery, no a los almacenados en fuentes de datos externas (como Cloud Bigtable, Cloud Storage y Drive).

Precios de la API Storage de BigQuery

La API Storage de BigQuery tiene un modelo de precios bajo demanda. Se te cobrará por los datos que leas. Los clientes que se hayan dado de alta en el plan de la tarifa fija pueden usar la API Storage de BigQuery para leer hasta 300 TB de datos al mes sin coste alguno. Las lecturas que superen los 300 TB al mes se facturan con la tarifa bajo demanda.

Precios bajo demanda

En el modelo de precios bajo demanda, los cargos de la API Storage de BigQuery se basan en el número de bytes leídos desde el almacenamiento de BigQuery por las llamadas a ReadRows.

En el número de bytes leídos se incluyen los datos usados para el filtrado que no se te han devuelto como resultados desde ReadRows. No se te cobrará por los datos leídos desde las tablas temporales.

Los precios de la API Storage de BigQuery bajo demanda son los siguientes:

Debes tener en cuenta los siguientes aspectos acerca de los cargos de la API Storage de BigQuery:

  • Se te cobra por la cantidad total de datos leídos. El número total de datos leídos por columna y su tamaño se calculan según el tipo de datos de la columna. Para obtener una explicación detallada de cómo calculamos esa cifra, consulta la sección correspondiente.
  • Se te cobrará por todos los datos que leas en una sesión de lectura, aunque se produzca un fallo en la llamada a ReadRows.
  • Si cancelas una llamada a ReadRows antes de que la transmisión haya finalizado, se te cobrará por todos los datos que hayas leído antes de cancelarla. Entre estos cargos se pueden incluir los datos leídos que no se te hayan devuelto antes de cancelar la llamada a ReadRows.
  • Recomendamos usar tablas con particiones y agrupadas en clústeres siempre que sea posible. Puedes reducir la cantidad de datos leídos si usas una cláusula WHERE para recortar las particiones. Para obtener más información, lee la información sobre cómo consultar tablas con particiones.

Cálculo del tamaño de los datos

Cuando cargas datos en BigQuery o los consultas, se te cobra según el tamaño de dichos datos. A la hora de calcularlo, nos basamos en el tamaño del tipo de datos de cada columna.

El tamaño de los datos almacenados y de los datos que procesan tus consultas se calcula en gigabytes (GB), donde 1 GB equivale a 230 bytes. Esta unidad de medida también se denomina gibibyte (GiB). Del mismo modo, 1 TB equivale a 240 bytes (1024 GB).

El tamaño de los tipos de datos de BigQuery es el siguiente:

Tipo de datos Tamaño
INT64/INTEGER 8 bytes
FLOAT64/FLOAT 8 bytes
NUMERIC 16 bytes
BOOL/BOOLEAN 1 byte
STRING 2 bytes + tamaño de la cadena codificada en UTF‑8
BYTES 2 bytes + número de bytes del valor
DATE 8 bytes
DATETIME 8 bytes
TIME 8 bytes
TIMESTAMP 8 bytes
STRUCT/RECORD 0 bytes + tamaño de los campos que contiene
GEOGRAPHY 16 bytes + 24 bytes * número de vértices del tipo geográfico (para verificar este número, usa la función ST_NumPoints)

Los valores nulos de cualquier tipo de datos se computan como 0 bytes.

Las columnas repetidas se almacenan como matrices y el tamaño se calcula según el número de valores. Por ejemplo, una columna que sea un número entero (INT64), se repita (ARRAY<INT64>) y contenga 4 entradas se calcula como 32 bytes (4 entradas x 8 bytes).

Precios de transmisión

La carga de datos en BigQuery es gratuita, con la salvedad de un pequeño importe que se cobra por los datos transmitidos.

Los precios de las inserciones de transmisión son los siguientes:

Precio del lenguaje de manipulación de datos

BigQuery cobra por las consultas de lenguaje de manipulación de datos (DML) según el número de bytes que se hayan procesado.

Precios de DML para tablas sin particiones

En las tablas sin particiones, el número de bytes procesados se calcula de la siguiente forma:

Declaración de DML Bytes procesados
INSERT La suma de bytes procesados de todas las columnas a las que se hace referencia desde las tablas que analiza la consulta.
UPDATE La suma de bytes procesados en todas las columnas a las que se hace referencia desde las tablas analizadas con la consulta
y la suma de bytes de todas las columnas de la tabla que se actualiza en el momento en que comienza UPDATE.
DELETE La suma de bytes procesados en todas las columnas a las que se hace referencia desde las tablas analizadas con la consulta
y la suma de bytes de todas las columnas de la tabla que se modifica en el momento en que comienza DELETE.
MERGE Si solo hay cláusulas INSERT en la declaración MERGE, se te cobrará la suma de bytes procesados de todas las columnas a las que se hace referencia en todas las tablas analizadas con la consulta.
Si hay una cláusula UPDATE o DELETE en la declaración MERGE, se te cobrará la suma de bytes procesados de todas las columnas a las que se hace referencia en las tablas de origen analizadas con la consulta
y la suma de bytes de todas las columnas de la tabla de destino (en el momento en que comienza MERGE).

Precio de DML para tablas con particiones

En las tablas con particiones, el número de bytes procesados se calcula de la siguiente forma:

Declaración de DML Bytes procesados
INSERT La suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones analizadas con la consulta.
UPDATE La suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones de las tablas analizadas con la consulta
y la suma de bytes de todas las columnas en las particiones analizadas o actualizadas de la tabla que se actualiza (en el momento en que comienza UPDATE).
DELETE La suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones de las tablas analizadas con la consulta
y la suma de bytes de todas las columnas en las particiones analizadas o modificadas de la tabla que se modifica (en el momento en que comienza DELETE).
MERGE Si solo hay cláusulas INSERT en la declaración MERGE, se te cobrará la suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones analizadas con la consulta.
Si hay una cláusula UPDATE o DELETE en la declaración MERGE, se te cobrará la suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones de las tablas de origen analizadas con la consulta
y la suma de bytes de todas las columnas en las particiones analizadas, actualizadas o eliminadas de la tabla de destino (en el momento en que comienza MERGE).

Precios del lenguaje de definición de datos

En BigQuery, se te cobra por las consultas de lenguaje de definición de datos (DDL) según el número de bytes que hayan procesado. Este número se calcula de la siguiente forma:

Declaración de DDL Bytes procesados
CREATE TABLE Ninguno
CREATE TABLE ... AS SELECT ... La suma de bytes procesados de todas las columnas a las que se hace referencia desde las tablas que analiza la consulta.
CREATE VIEW Ninguno
DROP TABLE Ninguno
DROP VIEW Ninguno

Precios de las tablas agrupadas en clústeres

Si creas tablas agrupadas en clústeres para usarlas en BigQuery, los cargos se basan en la cantidad de datos almacenados en ellas y en las consultas que realizas en los datos. Este tipo de tablas te permiten rebajar el coste de las consultas, ya que reducen los datos para que las consultas no los procesen. Este proceso se denomina "recorte de bloques".

Recorte de bloques

BigQuery ordena los datos de las tablas agrupadas en clústeres según los valores de las columnas de este tipo de agrupamiento y los organiza en bloques.

Cuando envías una consulta que incluye un filtro en una columna agrupada en clústeres, BigQuery emplea la información de dicho agrupamiento para determinar de forma eficiente si algún bloque contiene datos pertinentes para la consulta. De ese modo, BigQuery se limita a analizar solo los bloques que sean relevantes. Ese proceso se denomina recorte de bloques.

El precio de las consultas se basa en el número de bytes procesados. Si ejecutas una consulta en una tabla agrupada en clústeres y la consulta tiene un filtro de las columnas agrupadas de dicha forma, BigQuery emplea la expresión del filtro y los metadatos de los bloques para recortar los bloques que analiza dicha consulta.

Los bloques recortados no se analizan. Para calcular los bytes de datos que procesa la consulta, solo se tienen en cuenta los bloques analizados. El número de bytes que procesa una consulta sobre una tabla agrupada en clústeres equivale a la suma de bytes leídos en cada columna de los bloques analizados a la que hace referencia la consulta.

Si una consulta que aplica varios filtros hace varias referencias a una tabla agrupada en clústeres, BigQuery cobra por analizar las columnas de los bloques correspondientes con cada uno de los filtros.

Precios de las secuencias de comandos

En la versión beta de las secuencias de comandos, el equipo de BigQuery recomienda usar proyectos con reservas de tarifa fija para no tener que pagar por consultas no autorizadas, ya que el número de bytes que analizan las secuencias de comandos no suele conocerse antes de ejecutarlas. También puedes usar la zona de pruebas de BigQuery, que ofrece una serie limitada de funciones gratuitas de ejecución de secuencias de comandos. El equipo de BigQuery ofrecerá un control más pormenorizado de la cantidad total de bytes que analizan a lo largo del tiempo las secuencias de comandos y las declaraciones específicas de estas secuencias. Esta función todavía está en fase beta. Consulta las notas de la versión de BigQuery para conocer las últimas novedades sobre los precios.

Ten en cuenta que si la secuencia de comandos no se ejecuta correctamente, se aplicará cualquier declaración que se realice antes del error en cuestión. No te cobraremos la declaración que produzca el error.

En el caso de los tipos de declaración públicos (como SELECT, INSERT o UPDATE), los gastos de ejecución de la declaración aparecen en el documento de precios público. Se aplican los siguientes precios a los tipos de declaración específicos de las secuencias de comandos:

  • DECLARE: la suma de bytes analizados de todas las tablas a las que se hace referencia en la expresión DEFAULT. No te cobraremos las declaraciones DECLARE que no hagan referencia a ninguna tabla.
  • SET: la suma de bytes analizados de todas las tablas a las que se hace referencia en la expresión. No te cobraremos las declaraciones SET que no hagan referencia a ninguna tabla.
  • IF: la suma de bytes analizados de todas las tablas a las que se hace referencia en la expresión condicional. No te cobraremos las expresiones condicionales IF que no hagan referencia a ninguna tabla. No te cobraremos las declaraciones del bloque IF que no se ejecuten.
  • WHILE: la suma de bytes analizados de todas las tablas a las que se hace referencia en la expresión condicional. No te cobraremos las declaraciones WHILE sin referencia a tablas dentro de la expresión condicional. No te cobraremos las declaraciones del bloque WHILE que no se ejecuten.
  • CONTINUE o ITERATE: no tiene ningún coste asociado.
  • BREAK o LEAVE: no tiene ningún coste asociado.
  • BEGIN o END: no tiene ningún coste asociado.

Las tablas temporales no generan costes de almacenamiento mientras se ejecuta la secuencia de comandos. Sin embargo, se aplican los precios habituales a las declaraciones que las creen, modifiquen o consulten.

Ejemplos de precios de BigQuery

Estimar precios de consulta

Para ver ejemplos de precios de consulta, lee la información correspondiente.

Estimar precios de almacenamiento

Para ver ejemplos de precios de almacenamiento, consulta la información correspondiente.

Ejemplos de precios de DML para tablas sin particiones

En los siguientes ejemplos se demuestra cómo calcula BigQuery los bytes leídos para las declaraciones de DML que modifican las tablas sin particiones.

Ejemplo 1: Actualizar tabla sin particiones (UPDATE)

table1 tiene dos columnas: col1 de tipo INTEGER y col2 de tipo STRING.

UPDATE table1 SET col1 = 1 WHERE col2 = 2;

Bytes procesados en este ejemplo:

  • Suma del número de bytes de col1 +
  • Suma del número de bytes de col2

Ejemplo 2: Actualizar tabla sin particiones (UPDATE)

table1 tiene dos columnas: col1 de tipo INTEGER y col2 de tipo STRING. table2 tiene una columna: field1 de tipo INTEGER.

UPDATE table1 SET col1 = 1 WHERE col1 in (SELECT field1 from table2)

Bytes procesados en este ejemplo:

  • Suma del número de bytes de table1.col1 antes de UPDATE +
  • Suma del número de bytes de table1.col2 antes de UPDATE +
  • Suma del número de bytes de table2.field1

Ejemplos de precios de DML para tablas con particiones

En los siguientes ejemplos se demuestra cómo calcula BigQuery los bytes leídos para las declaraciones de DML que modifican las tablas con particiones y por hora de ingestión. Para ver las representaciones del esquema JSON de las tablas que se usan en los ejemplos, consulta la sección de tablas utilizadas en ejemplos de la página de actualización de datos de tablas con particiones mediante declaraciones de DML.

Ejemplo 1: Insertar tabla con particiones por hora de ingestión (INSERT)

mytable2 tiene dos columnas: id de tipo INTEGER y ts de tipo TIMESTAMP. mytable tiene dos columnas: field1 de tipo INTEGER y field2 de tipo STRING.

INSERT INTO mytable (_PARTITIONTIME, field1) AS SELECT TIMESTAMP(DATE(ts)), id from mytable2

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mytable2.ts +
  • Suma del número de bytes de mytable2.id

El tamaño de la tabla en la que se insertan las filas (mytable) no afecta al coste de la consulta.

Ejemplo 2: Insertar tabla con particiones (INSERT)

mytable2 tiene dos columnas: id de tipo INTEGER y ts de tipo TIMESTAMP. mycolumntable tiene cuatro columnas: field1 de tipo INTEGER, field2 de tipo STRING, field3 de tipo BOOLEAN y ts de tipo TIMESTAMP.

INSERT INTO mycolumntable (ts, field1) AS SELECT ts, id from mytable2

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mytable2.ts +
  • Suma del número de bytes de mytable2.id

El tamaño de la tabla en la que se insertan las filas (mycolumntable) no afecta al coste de la consulta.

Ejemplo 3: Actualizar tabla con particiones por hora de ingestión (UPDATE)

Declaración de DML 1: Actualizar una sola partición

mytable2 tiene dos columnas: id de tipo INTEGER y ts de tipo TIMESTAMP. mytable tiene dos columnas: field1 de tipo INTEGER y field2 de tipo STRING.

UPDATE project.mydataset.mytable T SET T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mytable2.id +
  • Suma del número de bytes de mytable.field1 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mytable.field2 en la partición "2017‑05‑01"

Declaración de DML 2: Actualizar una partición basada en otra partición de la tabla

UPDATE project.mydataset.mytable T SET T._PARTITIONTIME = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT 1 from project.mydataset.mytable S WHERE S.field1 = T.field1 AND S._PARTITIONTIME = TIMESTAMP("2017-06-01") )

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mytable.field1 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mytable.field2 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mytable.field1 en la partición "2017‑06‑01" +
  • Suma del número de bytes de mytable.field2 en la partición "2017‑06‑01"

En este caso, el coste de la declaración UPDATE se calcula al sumar los tamaños de todos los campos en las particiones que corresponden a "2017-05-01" y "2017-06-01".

Ejemplo 4: Actualizar tabla con particiones (UPDATE)

Declaración de DML 1: Actualizar una sola partición

mytable2 tiene dos columnas: id de tipo INTEGER y ts de tipo TIMESTAMP. mycolumntable tiene cuatro columnas: field1 de tipo INTEGER, field2 de tipo STRING, field3 de tipo BOOLEAN y ts de tipo TIMESTAMP.

UPDATE project.mydataset.mycolumntable T SET T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mytable2.id +
  • Suma del número de bytes de mycolumntable.field1 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.field2 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.field3 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.ts en la partición "2017‑05‑01"

Declaración de DML 2: Actualizar una partición basada en otra partición de la tabla

UPDATE project.mydataset.mycolumntable T SET T.ts = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT 1 from project.mydataset.mycolumntable S WHERE S.field1 = T.field1 AND DATE(S.ts) = "2017-06-01")

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mycolumntable.field1 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.field2 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.field3 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.ts en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.field1 en la partición "2017‑06‑01" +
  • Suma del número de bytes de mycolumntable.field2 en la partición "2017‑06‑01" +
  • Suma del número de bytes de mycolumntable.field3 en la partición "2017‑06‑01" +
  • Suma del número de bytes de mycolumntable.ts en la partición "2017‑06‑01"

En este caso, el coste de la declaración UPDATE se calcula al sumar los tamaños de todos los campos en las particiones que corresponden a "2017-05-01" y "2017-06-01".

Ejemplo 5: Eliminar tabla con particiones por hora de ingestión (DELETE)

mytable2 tiene dos columnas: id de tipo INTEGER y ts de tipo TIMESTAMP. mytable tiene dos columnas: field1 de tipo INTEGER y field2 de tipo STRING.

DELETE project.mydataset.mytable T WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mytable2.id +
  • Suma del número de bytes de mytable.field1 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mytable.field2 en la partición "2017‑05‑01"

Ejemplo 6: Eliminar tabla con particiones (DELETE)

mytable2 tiene dos columnas: id de tipo INTEGER y ts de tipo TIMESTAMP. mycolumntable tiene cuatro columnas: field1 de tipo INTEGER, field2 de tipo STRING, field3 de tipo BOOLEAN y ts de tipo TIMESTAMP.

DELETE project.mydataset.mycolumntable T WHERE DATE(T.ts) =“2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

Bytes procesados en este ejemplo:

  • Suma del número de bytes de mytable2.id +
  • Suma del número de bytes de mycolumntable.field1 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.field2 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.field3 en la partición "2017‑05‑01" +
  • Suma del número de bytes de mycolumntable.ts en la partición "2017‑05‑01"

Ejemplo de precios de las tablas agrupadas en clústeres

Imaginemos que tienes una tabla ClusteredSalesData que cuenta con particiones por la columna timestamp y que está agrupada en clústeres por la columna customer_id. Los datos están organizados en el siguiente conjunto de bloques:

Identificador de partición ID de bloque Valor mínimo de customer_id en el bloque Valor máximo de customer_id en el bloque
20160501 B1 10000 19999
20160501 B2 20000 24999
20160502 B3 15000 17999
20160501 B4 22000 27999

Decides ejecutar en la tabla la consulta que aparece a continuación, que incluye un filtro en la columna customer_id.

SELECT
  SUM(totalSale)
FROM
  `mydataset.ClusteredSalesData`
WHERE
  customer_id BETWEEN 20000
  AND 23000
  AND DATE(timestamp) = "2016-05-01"

Esta consulta hace lo siguiente:

  • Analiza las columnas timestamp, customer_id y totalSale de los bloques B2 y B4.
  • Recorta el bloque B3 por el predicado de filtrado DATE(timestamp) = "2016-05-01" de la columna con partición timestamp.
  • Recorta el bloque B1 por el predicado de filtrado customer_id BETWEEN 20000 AND 23000 de la columna agrupada en clústeres customer_id.

Ejemplo de precios de las secuencias de comandos

La siguiente secuencia de comandos de ejemplo incluye comentarios en cada declaración en los que se explica qué gastos se generan (si es que se genera alguno).

-- No cost, since no tables are referenced.
DECLARE x DATE DEFAULT CURRENT_DATE();
-- Incurs the cost of scanning string_col from dataset.table.
DECLARE y STRING DEFAULT (SELECT MAX(string_col) FROM dataset.table);
-- Incurs the cost of copying the data from dataset.big_table.  Once the
-- table is created, you are not charged for storage while the rest of the
-- script runs.
CREATE TEMP TABLE t AS SELECT * FROM dataset.big_table;
-- Incurs the cost of scanning column1 from temporary table t.
SELECT column1 FROM t;
-- No cost, since y = 'foo' doesn't reference a table.
IF y = 'foo' THEN
  -- Incurs the cost of scanning all columns from dataset.other_table, if
  -- y was equal to 'foo', or otherwise no cost since it is not executed.
  SELECT * FROM dataset.other_table;
ELSE
  -- Incurs the cost of scanning all columns from dataset.different_table, if
  -- y was not equal to 'foo', or otherwise no cost since it is not executed.
  UPDATE dataset.different_table
  SET col = 10
  WHERE true;
END IF;
-- Incurs the cost of scanning date_col from dataset.table for each
-- iteration of the loop.
WHILE x < (SELECT MIN(date_col) FROM dataset.table) DO
  -- No cost, since the expression does not reference any tables.
  SET x = DATE_ADD(x, INTERVAL 1 DAY);
  -- No cost, since the expression does not reference any tables.
  IF true THEN
    -- LEAVE has no associated cost.
    LEAVE;
  END IF;
  -- Never executed, since the IF branch is always taken, so does not incur
  -- a cost.
  SELECT * FROM dataset.big_table;
END WHILE;