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 Platform. 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 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 Google Cloud Platform. 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 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 al uso o de las tablas con particiones basadas en el momento de la 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 No se te cobrará 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 Platform, 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 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. 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 extraigan 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:

Tarifa fija

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

Cuando te das de alta en la tarifa fija, estás comprando una capacidad de procesamiento de consultas específica, que se mide en ranuras de BigQuery. El coste de todos los bytes procesados se incluye en la tarifa fija mensual. Si tus consultas superan la capacidad de la tarifa fija, se ejecutarán proporcionalmente más despacio hasta que pasen a estar disponibles más recursos de la tarifa fija.

Tarifa fija:

  • Se aplica a los costes de las consultas, incluidas las declaraciones de DML y DDL.
  • No se aplica a los costes de almacenamiento. Consulta la sección Precio del almacenamiento para conocer estos costes.
  • Se compra como un recurso regional, por lo que la capacidad de la tarifa fija que se compre en una región no se puede 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.

Detalles de la tarifa fija

Cuando te das de alta en la tarifa fija:

  • No puedes cancelar ni cambiar a un plan inferior los compromisos mensuales en los siguientes 30 días naturales desde la fecha de confirmación de la compra.

    Después de ese plazo, puedes cancelarlos o cambiarlos a un plan inferior cuando quieras. Si lo haces, tus cargos se prorratean por segundo con la tarifa mensual.

    Por ejemplo:

    • No puedes cancelar el día 29.
    • Si cancelas durante el primer segundo del día 31, se te cobran 30 días y 1 segundo.
    • Si cancelas a mitad del tercer mes, se te cobra el 50 % de la tarifa mensual por ese mes.
  • Los compromisos anuales no se pueden cancelar ni cambiar a un plan inferior durante un año natural.

    Antes del primer año desde la fecha del compromiso, puedes elegir renovarlo otro año o cambiar a un plan de tarifa fija mensual que empezará después de que acabe dicho año. Si cambias a la tarifa mensual, se te cobra por segundo con la tarifa mensual y puedes cancelar en cualquier momento.

    Por ejemplo:

    • Si renuevas otro año después de la fecha de compromiso anual, te estarás inscribiendo en un nuevo compromiso anual y se te seguirá cobrando la tarifa del compromiso anual.
    • Si no renuevas otro año después de la fecha del compromiso anual, tus cargos se prorratean por segundo con la tarifa mensual, y puedes cancelar cuando quieras.
  • Para comprar más ranuras de BigQuery, debes adquirir un nuevo compromiso de permanencia.

  • La tarifa fija se compra para una ubicación concreta de BigQuery.
    Cuando compras un plan de tarifa fija, especificas la asignación de ranuras por ubicación. Para usar ranuras en varias ubicaciones, debes comprarlas en cada una de ellas.
  • La tarifa fija y los precios bajo demanda se pueden combinar.
    Puedes elegir usar la tarifa fija o los precios bajo demanda en cada proyecto. Si tienes varios proyectos en una ubicación determinada, puedes usar la tarifa fija en unos y los precios bajo demanda en otros.
  • Para interrumpir un plan de precios de tarifa fija, debes cancelar o cambiar a un plan inferior tu compromiso.

Tarifa fija mensual

Cuando te das de alta en la tarifa fija, la capacidad que compras se mide en ranuras de BigQuery. En la siguiente tabla se muestra el número de ranuras que se te asignan según tu compra de la tarifa fija mensual.

Tarifa fija anual

Cuando te das de alta en la tarifa fija, la capacidad que compras se mide en ranuras de BigQuery. En la siguiente tabla se muestra el número de ranuras que se te asignan según tu compra de la tarifa fija anual. Cuando te das de alta en el plan de la tarifa fija anual, se te factura mensualmente.

La compra de ranuras a través de compromisos de permanencia mensuales y anuales se encuentra en fase alfa. Para participar en ella, rellena este formulario.

Los clientes que prefieran seguir con su plan de tarifa fija no notarán ningún cambio. Si quieres seguir usando el tuyo, ponte en contacto con tu representante de ventas.

Precio del 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 $ (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 $.

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.
Utilizar el lenguaje de manipulación de datos (DML) Uso de una declaración DML para modificar datos de tablas.
Utilizar el lenguaje de definición de datos (DDL) Uso de una declaración 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 pero que no se te hayan 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, incluso 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 particionadas.

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 conoce como 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 * 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 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 de todas las columnas a las que se hace referencia desde las tablas que analiza la consulta
y la suma de bytes de todas las columnas de la tabla actualizada en el momento en que comienza UPDATE.
DELETE La suma de bytes de todas las columnas a las que se hace referencia desde las tablas que analiza la consulta
y la suma de bytes de todas las columnas de la tabla modificada 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 los 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.
Además, también se te cobrará 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 tablas con particiones, el número de bytes procesados se calcula de la siguiente forma:

Declaración DML Bytes procesados
INSERT La suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones que analiza 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 que analiza 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 que analiza 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 cobra 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 cobra 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.
Además, también se te cobrará la suma de bytes de todas las columnas en las particiones analizadas, eliminadas o actualizadas 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 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 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.

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 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 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.
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

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