Precios de BigQuery

En esta página se detallan los precios de BigQuery.

Para conocer los precios de BigQuery ML, consulta esta página.

Si quieres conocer los precios de BigQuery Data Transfer Service, consulta esta otra página.

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 les conviene más a los clientes con un presupuesto fijo, ya que siempre sabrán lo que pagan. Los clientes que eligen la tarifa fija compran recursos dedicados para el procesamiento de consultas y no se les cobran las consultas individuales.

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 se denominan "precios de análisis" en la página de SKUs.

Resumen de precios

En la siguiente tabla se resumen los precios de BigQuery. Las cuotas y los límites de BigQuery se aplican a estas operaciones.

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 el análisis de datos de facturación mediante los informes, consulta el artículo sobre cómo ver las tendencias de costes con los informes de facturación.

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

Operaciones gratuitas

En la siguiente tabla se muestran las operaciones de BigQuery que son gratuitas en todas las ubicaciones. Las cuotas y los límites de BigQuery se aplican a estas operaciones.

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 en esa 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 en esa 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 o 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 preparación 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 disponible 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 mediante consultas con declaraciones CREATE MODEL del mes son gratuitos. Las consultas CREATE MODEL de BigQuery ML son independientes del nivel gratuito de análisis de 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. No obstante, puedes elegir el que se adapte a tus necesidades, así como combinar ambos 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, Google Drive o 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. Para obtener más información sobre cómo se calcula el tamaño de tus datos, consulta la sección correspondiente.
  • 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, como si se hubiera ejecutado 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 se denominan "precios de análisis" en la página de SKUs de Google Cloud Platform.

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 saber más, 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:

Precios de los datos con particiones externas en Cloud Storage

Se aplicarán tarifas adicionales por consultar tablas con particiones de Hive almacenadas en Cloud Storage.

BigQuery calcula la cantidad total de la longitud de los nombres de archivos sin recortar. El cargo total de la partición mediante Hive se redondea al alza a la cantidad de MB más cercana; con un mínimo de 10 MB datos procesados por tabla con particiones incluida en la consulta.

Tarifa fija

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

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 (denominadas ranuras en 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 se utilizan en 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 región no se pueden utilizar en otra.
  • Permite a los clientes aumentar las cuotas de simultaneidad por proyecto si se ponen en contacto con el equipo de asistencia de Google Cloud Platform.
  • El compromiso de permanencia puede ser mensual o anual.
  • Se pueden compartir en toda tu organización, por lo que no es necesario comprar confirmaciones de ranuras para cada proyecto.

Confirmaciones de tarifas fijas mensuales

Puedes darte de alta en la tarifa fija al comprar confirmaciones de ranuras, que se miden en ranuras de BigQuery. Las confirmaciones de ranuras comienzan a partir de las 500 ranuras. Se te cobrará por segundo en función de la duración de tu confirmación. En la siguiente tabla figura el coste de tu confirmación de ranuras mensual.

Confirmaciones de tarifa fija anuales

Puedes darte de alta en la tarifa fija al comprar confirmaciones de ranuras, que se miden en ranuras de BigQuery. Las confirmaciones de ranuras comienzan a partir de las 500 ranuras. En la siguiente tabla figura el coste de tu confirmación de ranuras anual. Cuando te das de alta en una confirmación anual, se te factura por segundo mientras dure dicha confirmación.

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 $.
  • 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, su precio 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.

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.
Uso del lenguaje de manipulación de datos (DML) Uso de una declaración de DML para modificar datos de tablas.
Uso del lenguaje de definición de datos (DDL) Uso de una declaración de DDL de tipo "CREATE OR REPLACE TABLE" para sustituir tablas.
Transmitir datos a una tabla Ingestión de datos mediante la llamada tabledata.insertAll a la API.

El resto de las acciones no provocan que el temporizador empiece de cero. 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.

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.

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 Google Drive).

Precios de la API de almacenamiento de BigQuery

La API de almacenamiento 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 de almacenamiento 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 de almacenamiento 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 de almacenamiento de BigQuery bajo demanda son los siguientes:

Debes tener en cuenta los siguientes aspectos acerca de los cargos de la API de almacenamiento 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 ver una explicación detallada de cómo calculamos esa cifra, consulta la sección Cálculo del tamaño de los datos.
  • 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. Puedes obtener más información en 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) binarios, 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 dato 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 x 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 de acuerdo con 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 analizadas con 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.
Su 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 objetivo (en el momento en que comienza MERGE).

Precio de DML para tablas con particiones

En 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 analizadas con 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 los 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 evitar 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 para conocer las últimas novedades sobre el precio.

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 que no han referencia a las expresiones condicionales. No te cobraremos las declaraciones del bloque WHILE que no se ejecuten.
  • CONTINUE/ITERATE: no tiene ningún coste asociado.
  • BREAK/LEAVE: no tiene ningún coste asociado.
  • BEGIN/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 creen, modifiquen o consulten dichas secuencias.

Ejemplos de precios de BigQuery

Estimar precios de consulta

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

Estimar precios de almacenamiento

Para ver ejemplos de precios de almacenamiento, consulta la secció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 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 con 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 en qué gastos se incurre (si es que se incurre en 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;
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.