La mayoría de los equipos de datos cree que agregar LIMIT 100 a una query exploratoria hace que la base de datos deje de leer al encontrar 100 filas. En BigQuery, eso es una ilusión cara. Vimos equipos quemando miles de reales por mes en queries que deberían costar centavos, y el culpable es un patrón de SQL que parece inofensivo.
El modelo de costo que nadie lee
BigQuery cobra por bytes leídos, no por filas retornadas. Esa es la regla fundamental que lo cambia todo. En una base de datos relacional tradicional, LIMIT 100 es eficiente porque la engine lee fila a fila y para. En una base de datos columnar como BigQuery, la lectura opera en bloques de columnas enteras.
Cuando usted ejecuta SELECT * FROM tabla LIMIT 100, la engine necesita recuperar las columnas solicitadas de los bloques de almacenamiento antes de aplicar el corte. En tablas particionadas sin filtro de partición, eso frecuentemente significa escanear particiones enteras, aunque el particionamiento y el clustering pueden mitigar parcialmente el costo al limitar el alcance del scan. Usted paga por el banquete y consume solo la aceituna.
En Tech86, cuando auditamos cuentas de BigQuery de clientes, el patrón SELECT * ... LIMIT en tablas grandes aparece consistentemente entre las principales fuentes de desperdicio. No es un error de lógica, es un error de modelo mental. El desarrollador diseña la query pensando en una base de datos relacional, pero la engine ejecuta en arquitectura columnar.
TABLESAMPLE SYSTEM: la física cambia
El comando TABLESAMPLE SYSTEM (1 PERCENT) cambia la física de la operación. En lugar de escanear la tabla entera y después cortar, instruye a la engine a leer bloques de datos aleatorios del disco hasta alcanzar el porcentaje de muestreo definido. La engine nunca lee más de lo especificado.
Según pruebas internas en Tech86, una query exploratoria que procesaba 3,45 GB con LIMIT 100 pasó a procesar 172 MB con TABLESAMPLE SYSTEM (1 PERCENT). Una reducción de 95% en el volumen de datos procesados, y en el costo de la query.
La diferencia no es marginal. En una operación que corre decenas de queries exploratorias por día, el ahorro mensual puede llegar a miles de reales. Y el cambio de código es mínimo: una cláusula SQL reemplazando a otra.
El problema no es exclusivo de BigQuery
El concepto se aplica a cualquier base de datos con lectura en bloques. En PostgreSQL, la sintaxis cambia a TABLESAMPLE BERNOULLI (1) o TABLESAMPLE SYSTEM (1), disponible desde la versión 9.5. La diferencia entre los dos métodos:
- BERNOULLI: muestreo fila a fila. Más preciso estadísticamente, pero más lento porque la engine necesita visitar cada fila para decidir si la incluye.
- SYSTEM: muestreo por página de disco. Más rápido porque la engine decide por bloque entero, pero con mayor varianza porque las filas dentro del mismo bloque tienden a estar correlacionadas.
Para exploración rápida, SYSTEM es suficiente. Para análisis que exigen representatividad muestral rigurosa, BERNOULLI es más seguro. En ambos casos, el I/O se reduce drásticamente en comparación con un SELECT * ... LIMIT que escanea la tabla entera.
La lección de FinOps detrás de la sintaxis
FinOps no es andar apagando servidores el fin de semana. FinOps es entender la arquitectura interna de la herramienta que usted opera. Cuando un equipo de datos hace exploración con LIMIT en tablas de petabytes, no está solo probando código, está drenando el OPEX de la empresa por desconocer el modelo de costo de la plataforma.
Conocer la sintaxis es común. Entender el costo computacional de la sintaxis es lo que separa a los profesionales de los aficionados. La misma query, escrita de formas diferentes, puede costar R$ 0,03 o R$ 30. La diferencia no está en el resultado, está en la física de la ejecución.
En Tech86 incluimos auditoría de patrones de query como parte estándar de nuestros proyectos de FinOps. Identificar SELECT * ... LIMIT en tablas grandes es uno de los primeros checks. La corrección es simple, el ahorro es inmediato, y el impacto se acumula mes a mes.
Conclusión
El LIMIT 100 en BigQuery es el equivalente a llenar el tanque del auto para dar la vuelta a la manzana. Funciona, pero cuesta mucho más de lo que debería. TABLESAMPLE SYSTEM es la herramienta correcta para el trabajo correcto: exploración de datos con costo proporcional a lo que usted consume.
Si su equipo de datos hace queries exploratorias en tablas grandes sin TABLESAMPLE, está pagando por bytes que nunca usa. Podemos ayudar a identificar y corregir esos patrones.