Precios de BigQuery

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

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

Para ver los precios del Servicio de transferencia de datos de BigQuery, consulta esta página.

Descripción general

BigQuery ofrece opciones de precios escalables y flexibles para satisfacer tus necesidades técnicas y tu presupuesto.

Los costos de almacenamiento se basan en la cantidad de datos almacenados en BigQuery. Los cargos de almacenamiento se dividen en dos categorías:

  • Activo: cargo mensual por los datos almacenados en tablas o particiones que se hayan modificado en los últimos 90 días.
  • A largo plazo: cargo mensual menor por los datos almacenados en tablas o particiones que no se hayan modificado en los últimos 90 días.

Para los costos de las consultas, puedes elegir entre dos modelos de precios:

  • Según demanda: esta es la opción más flexible. Los precios según demanda se basan en la cantidad de datos que procesa cada consulta que ejecutas.
  • Tasa fija: esta opción de precios es la mejor para los clientes que deseen previsibilidad de los costos. Los clientes de tasa fija compran recursos exclusivos para el procesamiento de consultas, y no se les cobran las consultas individuales.

Para obtener más información sobre los precios de las consultas y el almacenamiento, consulta Google Cloud Platform SKUs. Ten en cuenta que los precios de las consultas a pedido figuran como precios de análisis en la página de SKU.

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.

Cómo se facturan los cargos

Cada proyecto que creas tiene una cuenta de facturación adjunta. Todos los cargos en los que incurras por los trabajos de BigQuery que se ejecutan en el proyecto se facturan en la cuenta de facturación adjunta. Los cobros de almacenamiento de BigQuery también se incluyen en la cuenta de facturación adjunta.

Cómo analizar los datos de facturación

Puedes ver los costos y las tendencias de BigQuery en la página de informes de Facturación de Cloud en Cloud Console. Para obtener información sobre el análisis de datos de facturación mediante informes, accede a Consulta los informes de facturación y las tendencias de costos.

Para obtener información sobre el análisis de datos de facturación en BigQuery, consulta Exporta datos de Facturación de Cloud a BigQuery en la documentación de Facturación de Cloud.

Operaciones gratuitas

En la siguiente tabla, se muestran las operaciones de BigQuery que pueden realizarse sin costo en cualquier ubicación. Las cuotas y los límites de BigQuery se aplican a estas operaciones.

Operación Detalles
Cargar datos

No se te cobrará por cargar datos en BigQuery desde Cloud Storage ni desde archivos locales. Sin embargo, se te cobrará por almacenar datos en Cloud Storage. Consulta Almacenamiento de datos en la página de precios de Cloud Storage para ver los detalles. Una vez que se cargan los datos en BigQuery, estos quedan sujetos a los precios de almacenamiento de la herramienta.

Si el conjunto de datos de destino se ubica en la multirregión US, no se te cobra por tráfico de salida de red cuando cargas datos desde un depósito de Cloud Storage en cualquier otra región. Para obtener más información, consulta Consideraciones sobre la ubicación.

Copiar datos No se cobra por copiar una tabla, pero se generan cargos por el almacenamiento de la tabla nueva y la tabla original. Para obtener más información, consulta Cómo copiar una tabla existente.
Exportar datos Cuando exportas datos de BigQuery a Cloud Storage, no se cobra la operación en sí, pero se generan cargos por el almacenamiento de datos en Cloud Storage. Consulta Almacenamiento de datos en la página de precios de Cloud Storage para ver los detalles. Para obtener más información, consulta Cómo exportar datos de BigQuery.
Borrar conjuntos de datos No se cobra por borrar un conjunto de datos.
Borrar tablas, vistas, particiones y funciones No se cobra por borrar tablas, vistas, particiones de tablas individuales ni funciones definidas por el usuario.
Operaciones con metadatos No se cobra por las llamadas a list, get, patch, update ni delete. Algunos ejemplos de las operaciones que no se cobran son 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 funciones definidas por el usuario en un conjunto de datos.
Leer seudocolumnas No se cobra por consultar el contenido de las siguientes seudocolumnas:

_TABLE_SUFFIX: se usa para consultar tablas comodín o conseguir la semántica de decoradores de tablas en SQL estándar.
_PARTITIONDATE: se usa para consultar las tablas particionadas por fecha de transferencia.
_PARTITIONTIME: se usa para consultar las tablas particionadas por hora de transferencia.
_FILE_NAME: se usa para consultar las tablas basadas en fuentes de datos externas.
Leer metatablas No se cobra por consultar el contenido de las siguientes metatablas:

__PARTITIONS_SUMMARY__: se usa para obtener metadatos sobre las particiones de una tabla particionada o una tabla particionada por tiempo de transferencia.
__TABLES_SUMMARY__: se usa para obtener metadatos sobre las tablas y vistas de un conjunto de datos.
Crear, reemplazar o llamar a UDF En la actualidad, no se cobra por crear, reemplazar ni invocar funciones definidas por el usuario (UDF) persistentes. Por el momento, las UDF persistentes están en fase beta. Los precios están sujetos a cambios.

Límites de uso de Siempre gratuito

Como parte del Nivel gratuito de Google Cloud, BigQuery ofrece algunos recursos de forma gratuita hasta alcanzar un límite específico. Estos límites de uso gratuito están disponibles durante el período de prueba gratuito y después de este. Si excedes los límites de uso una vez finalizado el período de prueba gratuita, se aplicarán cargos conforme a los precios que se indican en esta página.

Recurso Límites mensuales de uso gratuito Detalles
Almacenamiento Los primeros 10 GB por mes son gratis. El nivel de almacenamiento gratuito incluye los modelos de BigQuery ML y los datos de entrenamiento almacenados en BigQuery.
Consultas (análisis) El primer TB de datos de consultas que se procesan por mes es gratis. El nivel de análisis gratuito incluye las consultas que usan las funciones de predicción, inspección y evaluación de BigQuery ML. No se incluyen las consultas de BigQuery ML que contienen instrucciones CREATE MODEL.
También ofrecemos precios de tasa fija de BigQuery para los clientes que tienen un gran volumen de consultas y prefieren pagar un costo mensual estable.
Consultas CREATE MODEL de BigQuery ML Los primeros 10 GB de datos procesados mediante consultas que incluyen instrucciones CREATE MODEL por mes son gratis. 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 (es decir, los modelos que se entrenan en BigQuery).

Precios de consulta

Los precios de consulta se refieren al costo de ejecutar comandos de SQL y funciones definidas por el usuario, así como instrucciones de lenguaje de manipulación de datos (DML) y lenguaje de definición de datos (DDL) que reúnan los requisitos.

BigQuery te permite elegir entre dos modelos de precios:

  • Precios según demanda es un modelo flexible y eficiente. Solo pagas por las consultas que ejecutas.
  • El modelo de precios de tasa fija ofrece costos predecibles y coherentes todos los meses.

De forma predeterminada, se te cobra de acuerdo con el modelo de precios según demanda. Puedes cambiar el modelo de facturación a una facturación de tasa fija o puedes mezclar y combinar los dos modelos para cada proyecto y ubicación.

Precios según demanda

En el caso de los precios según demanda, BigQuery usa una métrica para el cobro de las consultas: la cantidad de bytes procesados (también denominados “bytes leídos”). Se te cobra por la cantidad de bytes procesados, sin importar si los datos se almacenan en BigQuery o en una fuente de datos externa, como Cloud Storage, Drive o Cloud Bigtable. Los precios según demanda dependen exclusivamente del uso.

Este modelo de precios funciona de la siguiente manera:

Ten en cuenta las siguientes consideraciones en relación con los cargos por consultas:

  • BigQuery usa una estructura de datos de columnas. Se cobra según el total de datos procesados en las columnas que selecciones, y el total de datos por columna se calcula según los tipos de datos de cada columna. Para obtener más información sobre cómo se calcula el tamaño de tus datos, consulta el Cálculo del tamaño de los datos.
  • No se cobrará por las consultas que muestren un error ni por las que recuperan resultados de la caché.
  • Los cargos se redondean al MB más cercano, con un mínimo de 10 MB de datos procesados por la tabla a la que haga referencia la consulta y un mínimo de 10 MB de datos procesados por consulta.
  • Cancelar un trabajo de consulta en ejecución puede generar cargos de hasta el costo completo de la consulta si dejas que esta se ejecute por completo.
  • Cuando ejecutas una consulta, se te cobra en función de los datos procesados en las columnas que selecciones, incluso si configuras un LIMIT explícito en los resultados.
  • Particionar las tablas y agruparlas en clústeres puede ayudar a reducir la cantidad de datos que se procesan en las consultas. Como práctica recomendada, usa particiones y clústeres siempre que sea posible.
  • Los precios de las consultas a pedido figuran como precios de análisis en la página de Google Cloud Platform SKUs.

Controles de costos de las consultas a pedido

BigQuery ofrece mecanismos de control de costos que te permiten limitar los costos de las consultas. Tienes las siguientes opciones:

Consulta datos de Cloud Storage

Cuando consultas una fuente de datos externa de BigQuery, se te cobra por la cantidad de bytes leídos por la consulta. Para obtener más información, consulta Precios de consulta. También se te cobra por almacenar los datos en Cloud Storage. Para obtener más información, consulta los Precios de Cloud Storage.

Consulta formatos de columna en Cloud Storage

Si tus datos externos se almacenan en ORC o Parquet, la cantidad de bytes que se cobran está limitada por las columnas que BigQuery lee. Debido a que la consulta convierte los tipos de datos de una fuente externa en tipos de datos de BigQuery, la cantidad de bytes leídos se calcula según el 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 tasa fija

BigQuery ofrece precios de tasa fija a los clientes que prefieren un costo estable para las consultas en lugar de pagar el precio según demanda por TB de datos procesados.

Puedes optar por los precios de tasa fija mediante BigQuery Reservations.

Cuando te inscribes en un plan de precios de tasa fija, compras compromisos de ranuras, que son capacidad de procesamiento específica para consultas que se mide en ranuras de BigQuery. Tus consultas consumen esta capacidad, y no se facturan los bytes procesados. Si tu demanda de capacidad supera la capacidad comprometida, BigQuery pondrá en cola las ranuras y no se cobrarán cargos adicionales. Consulta Ranuras a fin de obtener más información sobre cómo BigQuery aprovecha las ranuras para el procesamiento de consultas.

Precios de tasa fija:

  • Se aplican a los costos de las consultas, incluidas las declaraciones DDL, las DML y las de BigQuery ML.
  • No se aplican a los costos de almacenamiento, transmisión o BI Engine.
  • Se adquieren como recursos regionales. Los compromisos de ranura que se compran en una o en múltiples regiones no se pueden usar en otra ni se pueden mover.
  • Los clientes pueden aumentar las cuotas de simultaneidad por proyecto si se comunican con la Asistencia de Google Cloud.
  • Los compromisos pueden ser por segundo, mensuales o anuales.
  • Se puede compartir con toda la organización. No es necesario comprar compromisos de ranura para cada proyecto.
  • Existe un mínimo de 100 ranuras y se compran en incrementos de 100.
  • Se factura por segundo por el tiempo que dure el compromiso.

Compromisos mensuales de tasa fija

En la siguiente tabla, se muestra el costo de tus compromisos de ranura mensuales.

Compromisos anuales de tasa fija

En la siguiente tabla se muestra el costo de tus compromisos anuales de ranura.

Ranuras flexibles: compromisos a corto plazo

Las ranuras flexibles son un tipo de compromiso especial:

  • El compromiso dura solo 60 segundos.
  • De ahí en adelante, puedes cancelar las ranuras flexibles en cualquier momento.
  • Se te cobra solo por los segundos en los que se implementó el compromiso.

En la siguiente tabla se muestra el costo de tu compromiso de ranura flexible.

Ranuras de prueba (promoción)

El 20 de mayo de 2020, BigQuery presentó una promoción limitada para clientes de BigQuery nuevos o que vuelven a usar la herramienta. Los clientes aptos pueden comprar ranuras de prueba, lo que corresponde a un compromiso de 6 meses con 500 ranuras a una tarifa con un gran descuento.

Las ranuras de prueba tienen el siguiente comportamiento:

  • Debes aceptar un compromiso de 6 meses.
  • No podrás cancelar hasta que hayan transcurrido 182 días desde el momento de la compra.
  • Solo puedes comprar 500 ranuras.
  • Puedes comprar otros tipos de compromisos y combinarlos con las ranuras de prueba.
  • Las ranuras de prueba solo están disponibles en las multirregiones de EE.UU. y la UE.
  • Las ranuras de prueba tienen disponibilidad limitada y se ofrecen por orden de llegada.
  • No existen diferencias de rendimiento ni disponibilidad entre las ranuras de prueba y los otros tipos de compromisos de ranuras.

Las ranuras de prueba están sujetas a criterios de calificación y están disponibles para los siguientes clientes:

  • Clientes nuevos de Google Cloud que se registren en BigQuery
  • Clientes existentes de Google Cloud que se registren en BigQuery
  • Clientes existentes de BigQuery que hayan invertido menos de $500 por mes en los últimos 3 meses
  • Clientes que se registren con la dirección de correo electrónico de su empresa
  • Oferta disponible solo para compras directas en Google, no mediante revendedores ni distribuidores

Para obtener más información sobre el funcionamiento de las ranuras de prueba, consulta la sección Ranuras de prueba.

Para participar en esta promoción, completa el Formulario de la promoción de ranuras de prueba de BigQuery y nos comunicaremos contigo en un máximo de cinco días hábiles.

Precios de almacenamiento

Una vez cargados los datos en BigQuery, se cobra el almacenamiento. Los precios del almacenamiento dependen de la cantidad de datos en tus tablas sin comprimir.

El tamaño de los datos se calcula según los tipos de datos de cada columna. Para obtener una explicación detallada de cómo se calcula el tamaño de los datos, consulta la sección Cálculo del tamaño de los datos.

Almacenamiento activo

Los cargos del almacenamiento activo se calculan de la siguiente manera:

Los precios de almacenamiento se prorratean por MB, por segundo. Por ejemplo:

  • Si almacenas 100 MB por quincena, pagas $0.001 (un décimo de centavo).
  • Si almacenas 500 GB por quincena, pagas $5.
  • Si almacenas 1 TB por un mes completo, pagas $20.

Almacenamiento a largo plazo

Si una tabla no se edita durante 90 días consecutivos, el precio de almacenamiento disminuye de forma automática en un 50%. No disminuye el rendimiento, la durabilidad, la disponibilidad ni otras funciones cuando una tabla se considera como almacenamiento a largo plazo.

Cada partición de una tabla particionada se considera por separado para los precios de almacenamiento a largo plazo. Si una partición no se modificó en los últimos 90 días, los datos de esa partición se consideran como almacenamiento a largo plazo y se cobran según los precios con descuento.

Los precios del almacenamiento a largo plazo se calculan de la siguiente manera:

Si la tabla se edita, el precio vuelve a ser el de almacenamiento común, y el contador de 90 días vuelve a comenzar desde cero. Cualquier operación que modifique los datos de una tabla restablece el contador. Estos son algunos ejemplos:

Acción Detalles
Cargar datos en una tabla Cualquier trabajo de carga o consulta que agregue datos a una tabla de destino o la reemplace.
Copiar datos en una tabla Cualquier trabajo de copia que agregue datos a una tabla de destino o la reemplace.
Escribir los resultados de una consulta en una tabla Cualquier trabajo de consulta que agregue datos a una tabla de destino o la reemplace.
Usar el lenguaje de manipulación de datos (DML) Usar una declaración DML para modificar los datos de una tabla.
Usar el lenguaje de definición de datos (DDL) Usar una declaración DDL CREATE OR REPLACE TABLE para reemplazar una tabla.
Transmitir datos a la tabla Transferir datos mediante la llamada a la API tabledata.insertAll

No se restablece el temporizador en el resto de las acciones, incluidas las siguientes:

  • Consultar una tabla
  • Crear una vista que consulte una tabla
  • Exportar datos de una tabla
  • Copiar una tabla (para pegar los datos en otra)
  • Aplicar parches a un recurso de tabla o actualizarlo

En el caso de las tablas que alcanzan el umbral de 90 días durante un ciclo de facturación, el precio se prorratea según corresponda.

Los precios del almacenamiento a largo plazo se aplican solo al almacenamiento de BigQuery, no a los datos almacenados en fuentes de datos externas, como Cloud Bigtable, Cloud Storage y Drive.

Precios de la API de BigQuery Storage

La API de BigQuery Storage tiene un modelo de precios según demanda. Se te cobra por los datos que lees. Los clientes que estén inscritos en el plan de precios de tasa fija pueden usar la API de BigQuery Storage para realizar operaciones de lectura de hasta 300 TB de datos al mes sin cargo. Las operaciones de lectura que excedan los 300 TB por mes se facturan con la tarifa según demanda.

Precios según demanda

Con los precios según demanda, los cargos de la API de BigQuery Storage se establecen en función de la cantidad de bytes leídos del almacenamiento de BigQuery mediante llamadas a ReadRows.

La cantidad de bytes leídos incluye los datos usados para aplicar filtros que no se mostraron como resultado de ReadRows. No se cobra por datos leídos desde las tablas temporales.

Los cargos de la API de BigQuery Storage según demanda se calculan de la siguiente manera:

Ten en cuenta las siguientes consideraciones en relación con los cargos por la API de BigQuery Storage:

  • Se cobra según la cantidad total de datos leídos. La cantidad 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 se calcula el tamaño de los datos, consulta la sección Cálculo del tamaño de los datos.
  • Se cobra por los datos leídos en una sesión de lectura incluso si falla la llamada a ReadRows.
  • Si cancelas una llamada a ReadRows antes de llegar al final de la transmisión, se cobran los datos leídos antes de la cancelación. Los cargos pueden incluir datos leídos que no se mostraron antes de cancelar la llamada a ReadRows.
  • Como práctica recomendada usa tablas particionadas y agrupadas en clústeres cuando sea posible. Puedes reducir la cantidad de datos leídos si usas una cláusula WHERE para reducir las particiones. Para obtener más información, ve a Consulta tablas particionadas.

Cálculo del tamaño de los datos

Cuando cargas datos a BigQuery o los consultas, se cobra según el tamaño de los datos. El tamaño de los datos se calcula en función del tamaño del tipo de datos de cada columna.

El tamaño de los datos almacenados y el tamaño de los datos que se procesen en tus consultas se calculan en gigabytes (GB). 1 GB equivale a 230 bytes. Esta unidad de medida también se conoce como gibibyte (GiB). De manera similar, 1 TB equivale a 240 bytes (1,024 GB).

El tamaño de los tipos de datos de BigQuery se calcula de la siguiente manera:

Tipo de datos Tamaño
INT64/INTEGER 8 bytes
FLOAT64/FLOAT 8 bytes
NUMERIC 16 bytes
BOOL/BOOLEAN 1 byte
STRING 2 bytes + el tamaño de la string con codificación UTF-8
BYTES 2 bytes + la cantidad de bytes en el valor
DATE 8 bytes
DATETIME 8 bytes
TIME 8 bytes
TIMESTAMP 8 bytes
STRUCT/RECORD 0 bytes + el tamaño de los campos incluidos
GEOGRAPHY 16 bytes + 24 bytes × la cantidad de vértices del tipo de geografía (puedes verificar este valor con la función ST_NumPoints)

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

Una columna repetida se almacena como arreglo, y el tamaño se calcula en función de la cantidad de valores. Por ejemplo, una columna con números enteros (INT64) que se repite (ARRAY<INT64>) y contiene 4 entradas equivale a 32 bytes (4 entradas × 8 bytes).

Precios de transmisión

Cargar datos en BigQuery es gratuito, excepto por un pequeño costo por los datos transmitidos.

Los precios de las inserciones de transmisión se calculan de la siguiente manera:

Precios del lenguaje de manipulación de datos

BigQuery cobra por las consultas DML en función de la cantidad de bytes que procese cada consulta.

Precios de DML para tablas no particionadas

En las tablas no particionadas, la cantidad de bytes procesados se calcula de la siguiente manera:

Declaración DML Bytes procesados
INSERT La suma de bytes procesados de todas las columnas a las que se hace referencia en las tablas que se analizaron en la consulta.
UPDATE La suma de bytes de todas las columnas a las que se hace referencia en las tablas que se analizaron en la consulta
más la suma de bytes de todas las columnas de la tabla actualizada en el momento en que comienza el evento UPDATE.
DELETE La suma de bytes de todas las columnas a las que se hace referencia en las tablas que se analizaron en la consulta
más la suma de bytes de todas las columnas de la tabla modificada en el momento en que comienza el evento DELETE.
MERGE Si la declaración MERGE solo contiene cláusulas INSERT, se cobra la suma de bytes procesados de todas las columnas a las que se hace referencia en todas las tablas que se analizaron en la consulta.
Si la declaración MERGE contiene cláusulas UPDATE o DELETE, se cobra la suma de bytes procesados de todas las columnas a las que se hace referencia en las tablas fuente que se analizaron en la consulta
más la suma de bytes de todas las columnas en la tabla de destino (en el momento en que comienza el evento MERGE).

Precios de DML para tablas particionadas

En el caso de las tablas particionadas, la cantidad de bytes procesados se calcula de la siguiente manera:

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 se analizaron en 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 se analizaron en la consulta
más la suma de los bytes de todas las columnas en las particiones que se actualizaron o analizaron en la tabla en proceso de actualización (en el momento en que comienza el evento 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 se analizaron en la consulta
más la suma de bytes de todas las columnas de las particiones que se modificaron o analizaron en la tabla en proceso de modificación (en el momento en que comienza el evento DELETE).
MERGE Si la declaración MERGE solo contiene cláusulas INSERT, se cobra la suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones que se analizaron en la consulta.
Si la declaración MERGE contiene cláusulas UPDATE o DELETE, se cobra la suma de bytes procesados de todas las columnas a las que se hace referencia en todas las particiones de las tablas fuente que se analizaron en la consulta
más la suma de bytes de todas las columnas en las particiones que se actualizaron, borraron o analizaron en la tabla de destino (en el momento en que comienza el evento MERGE).

Precios del lenguaje de definición de datos

BigQuery cobra por las consultas DDL en función de la cantidad de bytes que procesa cada una de ellas. En las instrucciones de DDL, la cantidad de bytes procesados se calcula de la siguiente manera:

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 en las tablas que se analizaron en la consulta.
CREATE VIEW Ninguno.
DROP TABLE Ninguno.
DROP VIEW Ninguno.

Precios de las tablas agrupadas en clústeres

Cuando creas y usas tablas agrupadas en clústeres en BigQuery, el cobro se basa en la cantidad de datos almacenados en las tablas y en las consultas que ejecutas en ellos. Las tablas agrupadas reducen los datos para que las consultas no los procesen, lo que te permite disminuir este tipo de gastos. Este proceso se conoce como reducción de bloques.

Reducción de bloques

BigQuery ordena los datos en una tabla agrupada según los valores de las columnas de agrupamiento y, luego, los organiza en bloques.

Cuando envías una consulta con un filtro en una columna agrupada, BigQuery usa la información del agrupamiento en clústeres para determinar de manera eficaz si el bloque contiene datos pertinentes a la consulta. Esto permite que BigQuery solo analice los bloques relevantes en un proceso conocido como reducción de bloques.

El precio de las consultas se basa en la cantidad de bytes procesados. Cuando ejecutas una consulta en una tabla agrupada, y la consulta tiene un filtro en las columnas agrupadas, BigQuery usa la expresión de filtro y los metadatos del bloque a fin de reducir la cantidad de bloques que analiza la consulta.

Cuando se reduce un bloque, no se lo analiza. Para calcular los bytes de datos que procesó la consulta, solo se usan los bloques analizados. La cantidad de bytes que procesó una consulta en una tabla agrupada equivale a la suma de los bytes leídos en cada columna a la que hizo referencia la consulta en los bloques analizados.

Si se hace referencia varias veces a una tabla agrupada en clústeres en una consulta que usa muchos filtros, BigQuery cobra por el análisis de las columnas en los bloques apropiados de cada filtro respectivo.

Precios de las secuencias de comandos

Durante la fase beta de las secuencias de comandos de BigQuery, el equipo de BigQuery recomienda el uso de proyectos con reservas de tasa fija para evitar costos de consultas no deseados, ya que se suele desconocer la cantidad de bytes que analiza una secuencia de comandos antes de ejecutarla. De manera alternativa, puedes usar la zona de pruebas de BigQuery para aprovechar la ejecución de secuencias de comandos gratuitas limitadas. Con el tiempo, el equipo de BigQuery ofrecerá un control más explícito sobre el total de bytes que analizan las secuencias de comandos y las instrucciones individuales en ellas. Esta es una versión beta. Para conocer los precios actualizados, consulta las notas de la versión de BigQuery.

Si una secuencia de comandos falla, se aplican los costos de cualquier instrucción hasta el momento en que ocurre la falla. La declaración que falló no genera ningún costo.

En el caso de los tipos de declaraciones con versiones públicas, como SELECT, INSERT y UPDATE, los costos de su ejecución son los que se describen en la documentación pública de precios. Para los tipos de declaraciones específicas de las secuencias de comandos, se aplican los siguientes precios:

  • DECLARE: la suma de bytes que se analizaron en cualquier tabla a la que se hizo referencia en la expresión DEFAULT. Las declaraciones DECLARE sin referencias de tablas no generan ningún costo
  • SET: suma de bytes que se analizaron en cualquier tabla a la que se hizo referencia en la expresión. Las declaraciones SET sin referencias de tablas no generan ningún costo
  • IF: suma de bytes que se analizaron en cualquier tabla a la que se hizo referencia en la expresión de condición. Las expresiones de condición IF sin referencia de tabla no generan ningún costo. Cualquier declaración en el bloque IF que no se ejecute no generará ningún costo
  • WHILE: suma de bytes que se analizaron en cualquier tabla a la que se hizo referencia en la expresión de condición. Las declaraciones WHILE sin referencias de tablas en la expresión de condición no generan ningún costo. Cualquier declaración en el bloque WHILE que no se ejecute no generará ningún costo
  • CONTINUE o ITERATE: sin costos asociados
  • BREAK o LEAVE: sin costos asociados
  • BEGIN o END: sin costos asociados

Las tablas temporales no generan cargos por almacenamiento mientras se ejecuta la secuencia de comandos. Sin embargo, se aplican precios regulares a cualquier declaración que las cree, modifique o consulte.

Ejemplos de precios en BigQuery

Estima los costos de las consultas

Para ver algunos ejemplos de precios de consultas, visita esta página.

Estima los costos del almacenamiento

Para ver algunos ejemplos de precios de almacenamiento, consulta esta página.

Ejemplos de precios de DML para tablas no particionadas

Los ejemplos que se detallan a continuación demuestran cómo se calculan los bytes leídos para generar las declaraciones DML que modifican tablas no particionadas en BigQuery.

Ejemplo 1: Actualización de tabla no particionada (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:

  • la suma de la cantidad de bytes en col1 +
  • la suma de la cantidad de bytes en col2

Ejemplo 2: Actualización de tabla no particionada (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:

  • la suma de la cantidad de bytes en table1.col1 antes de UPDATE +
  • la suma de la cantidad de bytes en table1.col2 antes de UPDATE +
  • la suma de la cantidad de bytes en table2.field1

Ejemplos de precios de DML para tablas particionadas

Los ejemplos que se detallan a continuación demuestran cómo se calculan los bytes leídos para generar las declaraciones DML que modifican tablas particionadas en BigQuery. Para ver las representaciones esquemáticas JSON de las tablas usadas en los ejemplos, consulta las tablas usadas en los ejemplos en la página en la que se explica cómo actualizar los datos de tablas particionadas mediante declaraciones DML.

Ejemplo 1: Inserción de tablas particionadas por tiempo de transferencia (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:

  • la suma de la cantidad de bytes en mytable2.ts +
  • la suma de la cantidad de bytes en mytable2.id

El tamaño de la tabla en la que se insertan las filas (mytable) no influye en el costo de la consulta.

Ejemplo 2: Inserción de tabla particionada (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:

  • la suma de la cantidad de bytes en mytable2.ts +
  • la suma de la cantidad de bytes en mytable2.id

El tamaño de la tabla en la que se insertan las filas (mycolumntable) no influye en el costo de la consulta.

Ejemplo 3: Actualización de tablas particionadas por tiempo de transferencia (UPDATE)

Declaración DML 1: Cómo 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:

  • la suma de la cantidad de bytes en mytable2.id +
  • la suma de la cantidad de bytes en mytable.field1 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mytable.field2 de la partición “2017-05-01”

Declaración DML 2: Cómo actualizar una partición a partir de otra en una 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:

  • la suma de la cantidad de bytes en mytable.field1 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mytable.field2 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mytable.field1 de la partición “2017-06-01" +
  • la suma de la cantidad de bytes en mytable.field2 de la partición “2017-06-01”

En este caso, el costo de la declaración UPDATE es igual a la suma del tamaño de todos los campos en las particiones correspondientes a “2017-05-01” y “2017-06-01”.

Ejemplo 4: Actualización de tabla particionada (UPDATE)

Declaración DML 1: Cómo 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:

  • la suma de la cantidad de bytes en mytable2.id +
  • la suma de la cantidad de bytes en mycolumntable.field1 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.field2 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.field3 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.ts de la partición “2017-05-01”

Declaración DML 2: Cómo actualizar una partición a partir de otra en una 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:

  • la suma de la cantidad de bytes en mycolumntable.field1 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.field2 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.field3 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.ts de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.field1 de la partición “2017-06-01” +
  • la suma de la cantidad de bytes en mycolumntable.field2 de la partición “2017-06-01” +
  • la suma de la cantidad de bytes en mycolumntable.field3 de la partición “2017-06-01” +
  • la suma de la cantidad de bytes en mycolumntable.ts de la partición “2017-06-01”

En este caso, el costo de la declaración UPDATE es igual a la suma del tamaño de todos los campos en las particiones correspondientes a “2017-05-01” y “2017-06-01”.

Ejemplo 5: Eliminación de tablas particionadas por tiempo de transferencia (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:

  • la suma de la cantidad de bytes en mytable2.id +
  • la suma de la cantidad de bytes en mytable.field1 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mytable.field2 de la partición “2017-05-01”

Ejemplo 6: Eliminación de tabla particionada (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:

  • la suma de la cantidad de bytes en mytable2.id +
  • la suma de la cantidad de bytes en mycolumntable.field1 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.field2 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.field3 de la partición “2017-05-01” +
  • la suma de la cantidad de bytes en mycolumntable.ts de la partición “2017-05-01”

Ejemplo de precio de una tabla agrupada en clústeres

Supón que tienes una tabla agrupada en clústeres con el nombre ClusteredSalesData. La tabla está particionada en la columna timestamp y se agrupa en clústeres según la columna customer_id. Los datos se organizan en el conjunto de bloques que se indica a continuación:

Identificador de la partición ID del 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

Ejecutas la siguiente consulta en la tabla. La consulta contiene 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"

La consulta realiza las siguientes acciones:

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

Ejemplo de precios de las secuencias de comandos

La siguiente secuencia de comandos de ejemplo contiene comentarios arriba de cada instrucción con los que se explica el costo (si lo hay) que genera la siguiente instrucción.

-- 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;