Migrar al physical storage de BigQuery puede ahorrarte dinero, pero conviene tener presentes los costos del time travel y del fail-safe storage. En este artículo te mostramos cómo estas funciones pueden inflar tu factura y qué opciones tienes para evitarlo: por ejemplo, reducir la ventana de time travel o cambiar al logical storage antes de eliminar datos.
Pasar del logical storage al physical storage en BigQuery puede reducir drásticamente tus costos de almacenamiento, como ya ha ocurrido con muchos de los clientes con los que hemos trabajado.
Pero si sumas los costos del time travel y del fail-safe de BigQuery, podrías terminar pagando bastante más que con el logical storage, o asumir costos de almacenamiento más altos de los que esperabas.
En este artículo veremos:
- Los riesgos del time travel y del fail-safe storage de BigQuery que disparan tus costos
- Las opciones que tienes para sortearlos
Los riesgos del time travel y el fail-safe de BigQuery
La función de time travel de BigQuery te permite acceder a datos que se modificaron o eliminaron en cualquier momento dentro de una ventana específica. Por defecto, esa ventana es de siete días, aunque se puede acortar hasta dos días.
La función de fail-safe de BigQuery conserva los datos eliminados durante siete días adicionales después de la ventana de time travel, para casos de recuperación de emergencia (hasta hace poco eran 14 días). Y a diferencia del time travel, no puedes modificar este periodo de retención. Para restaurar datos del fail-safe, además, debes abrir un ticket con Google Support.
Pagas tanto por el time travel como por el fail-safe storage cuando estás en physical storage, a los precios del physical storage activo; en logical storage no pagas por ninguno de los dos.
El siguiente gráfico simula esta situación:
- El total de physical storage de largo plazo es de 200 GiB y luego se eliminan 50 GiB,
- La ventana de time travel es de siete días, seguida de
- Un periodo de fail-safe de siete días.
Mira el caso que compartimos a continuación, tomado de un Q&A en vivo de BigQuery que organizamos hace poco:
Un cliente eliminó una tabla grande que estaba en physical storage de largo plazo, y el time travel guardó la tabla eliminada por si necesitaba restaurarla. Una vez eliminada, los datos de la tabla pasaron a almacenamiento activo dentro del time travel y del fail-safe storage. Durante un total de 21 días (siete en time travel y 14 en fail-safe, cuando aún era de 14 días), el cliente pagó sin saberlo el precio del almacenamiento activo, lo que se tradujo en una factura de almacenamiento mucho más alta de lo previsto.
Opción 1: ajusta la configuración del time travel de BigQuery
Por defecto, el time travel de BigQuery está configurado en siete días y se puede reducir hasta un mínimo de dos. Si crees que puedes asumir una menor resiliencia de los datos, bajar este valor te permitirá reducir el costo de los datos almacenados en time travel.
Por ejemplo, si tienes un proceso de respaldo robusto desde BQ hacia otras fuentes como GCS, recortar el periodo de time travel a dos días no debería ser un problema. Algunos de nuestros clientes configuran políticas o pipelines de auto-archivado para respaldar sus datos de forma periódica, y en escenarios así también tiene sentido acortar el time travel, porque esos datos ya están respaldados fuera de BigQuery.
Por experiencia, la mayoría de los clientes no necesita realmente los siete días completos de time travel: aunque lo reduzcan a dos, igual cuentan con los siete días adicionales de fail-safe. Así que, si reducir costos pesa más que contar con siete días completos de historial, acortar el time travel a dos días no debería afectarte demasiado.
Otra alternativa: si estás por eliminar un gran volumen de datos, puede valer la pena bajar el time travel a dos días antes de hacerlo, solo para reducir temporalmente tu huella de almacenamiento. ¡Eso sí, recuerda volver al valor anterior si lo necesitas!
Opción 2: convierte tu tabla a logical storage de BigQuery antes de eliminarla
La otra solución es cambiar el modelo de facturación de almacenamiento de tu dataset a logical storage antes de eliminar los datos, ya que con este modelo no se cobra ni el time travel ni el fail-safe storage.
Ten en cuenta que solo puedes hacer este cambio una vez cada 14 días, así que tendrías que esperar 14 días para volver atrás. Además, el cambio en el modelo de almacenamiento puede tardar hasta 24 horas en aplicarse.
Antes de hacer el cambio, asegúrate de ejecutar esta consulta para comparar tus costos con 14 días de logical storage frente a nueve días de physical storage activo (mínimo 2 días de time travel + 7 días de fail-safe storage).
A continuación tienes un ejemplo de la salida de esta consulta, donde "additional_costs_for_physical_storage" incluye tanto los costos de time travel como los de fail-safe storage:
dataset
logical_active_price
base_physical_price
logical_long_term_price
base_long_term_price
additional_costs_for_physical_storage
logical_storage_price
physical_storage_price
difference_in_price_if_physical_is_chosen
recommendation
warehouse
$ 0.57
$ 0.07
$ 0.00
$ 0.00
$ 62.27
$ 0.57
$ 62.34
$ -61.77
Keep dataset on logical storage
Opción 3: no te pases al physical storage de BigQuery
Si agregas y eliminas datos constantemente, lo más probable es que tus volúmenes en time travel y fail-safe sean bastante altos, por lo que quizás ni siquiera tenga sentido pasarte al physical storage.
Esto se debe a que el modelo de logical storage no cobra los datos en time travel ni en fail-safe, mientras que el modelo de physical storage sí lo hace.
Si tienes grandes volúmenes de datos en esas áreas, los costos pueden dispararse por encima de lo que cobraría el logical storage. Por eso es clave revisar esos volúmenes específicos antes de plantearte el cambio al physical storage.
La consulta que compartimos arriba recorre un proyecto (y una sola región) y revisa cada uno de los datasets para darte el desglose de costos y la recomendación.
Tiene sentido pasarse al physical storage de BigQuery en estos escenarios:
- Cuando la mayor parte de tus datos son texto/strings (por ejemplo, json, direcciones, logs, etc.), ya que tienen los mayores ratios de compresión.
- Cuando hay un plan sólido de ciclo de vida de los datos (por ejemplo, una tabla particionada por día, donde cada partición expira después de X días).
- Cuando los datos no se modifican constantemente en las tablas o particiones (como mencionamos antes, esto incrementa los datos almacenados en time travel y fail-safe).
Reflexiones finales
Aunque en muchos casos pasar del logical storage al physical storage de BigQuery sí reduce tus costos de almacenamiento, vale la pena conocer los riesgos que podrían borrar ese ahorro.