Esta es la palabra que más te van a decir en una reunión y la que menos gente sabe definir 🎤
Y no es culpa de nadie. Durante diez años se vendió como si fuera un producto, así que quedó significando "muchos datos", que es como definir "casa" diciendo "muchos ladrillos".
Antes de arrancar, contéstate una: ¿cuántas filas tiene la tabla más grande que has abierto en tu trabajo? Guarda ese número, que lo vamos a usar al final del capítulo para saber si lo tuyo es big data o no 📏
La definición, sin marketing
Big data es cuando los datos ya no caben ni se procesan en una sola máquina. Ya está. Esa es toda la idea.
No es un número de filas ni un tamaño en gigas. Es un momento: aquel en el que tienes que repartir el trabajo entre varias computadoras porque una sola no llega. Y todas las herramientas que oíste nombrar existen para resolver ese reparto, no para otra cosa.
Las famosas tres V son de 2001 y siguen sirviendo si se leen bien:
| La V | Qué pregunta de verdad | Cuándo te toca |
|---|---|---|
| Volumen | ¿Cabe en una máquina? | Cuando hablas de decenas de terabytes para arriba |
| Velocidad | ¿Llegan más rápido de lo que puedes guardarlos? | Sensores, transacciones de un banco, clics de una web enorme |
| Variedad | ¿Tienen forma de tabla? | Video, audio, texto libre, imágenes |
Y fíjate en algo: con que falle una sola ya tienes el problema. Una empresa con datos chiquitos pero que llegan a mil por segundo tiene un problema de big data. Y una con muchos gigas de tablas ordenadas que se consultan una vez al día, no.
Dónde está el listón, medido
Aquí es donde casi todos los artículos se ponen vagos y dicen "grandes volúmenes". Vamos a poner números.
Primero, lo que pesa la base con la que llevas trece capítulos:
SELECT (SELECT * FROM pragma_page_count()) * (SELECT * FROM pragma_page_size())
AS bytes;
bytes ------ 139264
139 KB. La base entera de este libro, con sus cinco tablas y sus casi cuatro mil filas, pesa menos que una foto del celular 📱
Ahora vamos a hacerla grande de verdad. Estas cuatro líneas fabrican doscientas mil filas:
CREATE TABLE grande AS
WITH RECURSIVE n(x) AS (
SELECT 1 UNION ALL SELECT x + 1 FROM n WHERE x < 200000
)
SELECT x AS id, (x % 6) AS ciudad, (x * 7919 % 200000) / 100.0 AS monto
FROM n;
SELECT COUNT(*) AS filas FROM grande;
filas ------ 200000
Doscientas mil filas, creadas en una décima de segundo. Y ahora el resumen entero sobre todas ellas:
SELECT ciudad, ROUND(SUM(monto), 0) AS soles FROM grande GROUP BY ciudad ORDER BY ciudad;
ciudad soles ------ ---------- 0 33324281.0 1 33334000.0 2 33341719.0 3 33331360.0 4 33333000.0 5 33334640.0
Seis centésimas de segundo. Y la base pasó a pesar 4,5 MB 🚀
Fuera de este libro lo llevé más lejos, en una laptop normal y con SQLite, que es la base más humilde que existe:
| Con 5.000.000 de filas | Cuánto |
|---|---|
| Lo que ocupa en disco | 142 MB |
| Lo que pesa cada fila | 28,5 bytes |
| Insertarlas todas | 9,3 segundos |
| Contarlas | 0,04 segundos |
| Un GROUP BY sobre las cinco millones | 3,07 segundos |
| La misma consulta filtrada, con índice | 0,03 segundos |
Cinco millones de filas ocupan lo que tres canciones. Y esto no es un servidor: es una laptop 💻
El número que te va a sorprender
Si cada fila pesa 28,5 bytes, para llenar un solo terabyte harían falta 35 mil millones de filas.
Ponlo en perspectiva con algo que conozcas. Si una empresa peruana mediana factura mil boletas al día, todos los días del año, sin parar, tarda casi cien mil años en llegar a ese terabyte.
Y un terabyte todavía no es big data. Un terabyte cabe en un disco de 90 soles 😅
Y Excel, ¿dónde se rinde?
En 1.048.576 filas. Ese es el máximo de una hoja y no es negociable: son 2 elevado a 20, y está así desde 2007.
O sea que el famoso "se me colgó el Excel" pasa casi cinco veces antes de que a SQLite se le empiece a notar el esfuerzo. Y ahí está el malentendido más caro de todos: mucha gente concluye "tenemos big data" cuando lo que tiene es un Excel donde no cabe algo que a una base de datos le sobra sitio 🙃
Las herramientas, y qué problema resuelve cada una
Te las nombro para que las reconozcas en una reunión, no para que las aprendas hoy:
- 🐘 Hadoop. El abuelo. Guarda archivos repartidos entre muchas máquinas y procesa por lotes. Casi nadie empieza uno nuevo hoy.
- ⚡ Spark. Lo mismo pero en memoria y mucho más rápido, y con una forma de escribir que se parece a pandas. Es el estándar cuando de verdad hace falta repartir.
- ☁️ BigQuery, Redshift, Snowflake. Bases columnares en la nube. Le mandas SQL normal y ellas reparten por debajo sin que te enteres. Es por lejos el camino más común hoy.
- 🌊 Kafka. No es para volumen, es para velocidad: datos que llegan sin parar y hay que ir atendiendo.
Fíjate en lo de BigQuery, que es la buena noticia del capítulo: le escribes SQL. El mismo SELECT, el mismo GROUP BY, los mismos JOIN de este libro. Si algún día te toca big data de verdad, lo que aprendiste acá sigue valiendo entero 💜
Qué hacer antes de llegar ahí
El 99% de las veces que alguien dice "necesitamos big data", lo que necesita es una de estas cuatro, y todas están en este libro:
- 🔍 Un índice. La consulta de cuarenta segundos que pasa a medio segundo, del capítulo 13.
- 🧱 Un diseño que no duplique. La mitad de las tablas enormes son enormes porque repiten, del capítulo 10.
- 📅 Traer solo el periodo que miras. Nadie necesita ocho años de historia para el reporte del mes.
- 🧮 Resumir una vez y guardar el resumen. Una tabla de totales por día pesa mil veces menos que el detalle y contesta lo mismo.
Y te lo digo con toda la honestidad: montar Spark para diez millones de filas es más caro, más lento y más frágil que ponerle un índice a una base normal. He visto proyectos hacerlo, y el resultado fue una consulta más lenta que antes y tres personas ocupadas manteniéndolo 😖
Ejercicios
Los ejercicios son la mitad del libro. Intenta antes de abrir.
1. Mide tu propia base
Averigua cuánto pesa la base del libro después de haberle metido las 200.000 filas.
SELECT ROUND((SELECT * FROM pragma_page_count()) *
(SELECT * FROM pragma_page_size()) / 1000000.0, 1) AS mb;
mb --- 4.5
4,5 MB. Y le acabas de meter cincuenta veces más filas de las que traía 📦
Todos los motores saben decirte lo que pesan, y es la primera pregunta antes de decidir nada sobre volumen 📏
Cuánto pesa mi base
| PostgreSQL | SELECT pg_size_pretty(pg_database_size('mi_base')); |
| MySQL | SELECT table_schema, SUM(data_length + index_length) FROM information_schema.tables GROUP BY table_schema; |
| SQL Server | EXEC sp_spaceused; |
| SQLite | SELECT (SELECT * FROM pragma_page_count()) * (SELECT * FROM pragma_page_size()); |
Cuatro formas de contestar la única pregunta que desarma una conversación sobre big data. Ninguna tarda más de un segundo, y casi nadie la hace antes de opinar.
2. La consulta del motor de al lado
Prueba la de PostgreSQL aquí, en SQLite, a ver qué pasa.
SELECT pg_size_pretty(pg_database_size('mi_base'));
OperationalError: no such function: pg_database_size
no such function 🙅 Y es exactamente lo que tenía que pasar: esa función existe en PostgreSQL y no en SQLite.
Te lo hago cometer a propósito porque es el error que más rabia da al empezar: copias algo de internet, no te corre, y crees que lo escribiste mal. Casi nunca lo escribiste mal. Estaba escrito para otro motor, que es de lo que va la tabla de dialectos de cada capítulo de este libro.
La costumbre que te ahorra tardes: cuando busques ayuda, escribe el nombre de tu motor en la búsqueda. "contar filas sql" y "contar filas postgresql" te devuelven cosas distintas 🔍
3. Cuántas filas caben en un Excel
La tabla grande tiene 200.000 filas. ¿Cuántas
veces cabe en una hoja de Excel?
SELECT 1048576 AS limite_excel,
(SELECT COUNT(*) FROM grande) AS mis_filas,
ROUND(1048576.0 / (SELECT COUNT(*) FROM grande), 1) AS veces;
limite_excel mis_filas veces ------------ --------- ----- 1048576 200000 5.2
Cabe cinco veces. Y a la base ni le hizo cosquillas 🙂
4. Resumir una vez y guardar el resumen
Crea una tabla de totales por ciudad y compara cuántas filas tiene contra el detalle.
CREATE TABLE resumen AS
SELECT ciudad, COUNT(*) AS operaciones, ROUND(SUM(monto), 0) AS soles
FROM grande GROUP BY ciudad;
SELECT (SELECT COUNT(*) FROM grande) AS detalle,
(SELECT COUNT(*) FROM resumen) AS resumen;
detalle resumen ------- ------- 200000 6
Doscientas mil filas contra seis 🤯
Esto es lo que hace un almacén de datos y es la respuesta a la mitad de los problemas de rendimiento: si la pregunta siempre es la misma, contéstala una vez al día y guarda la respuesta. El detalle sigue ahí para cuando alguien quiera bajar, pero el reporte no lo toca.
5. El índice, otra vez, pero con volumen
Pídele el plan a una consulta filtrada sobre las 200.000 filas, antes y después del índice.
EXPLAIN QUERY PLAN SELECT COUNT(*) FROM grande WHERE ciudad = 3;
id parent notused detail -- ------ ------- ----------- 3 0 0 SCAN grande
CREATE INDEX ix_grande ON grande(ciudad); EXPLAIN QUERY PLAN SELECT COUNT(*) FROM grande WHERE ciudad = 3;
id parent notused detail -- ------ ------- ------------------------------------------------------- 3 0 0 SEARCH grande USING COVERING INDEX ix_grande (ciudad=?)
De SCAN a SEARCH con una línea. Esa es la
herramienta que hay que agotar antes de pensar en repartir nada entre
máquinas ⚡
6. Cuántos años tardarías en tener un terabyte
Si cada fila pesa 28,5 bytes y emites mil boletas al día, ¿cuántos años para llegar a un terabyte?
SELECT ROUND(1000000000000.0 / 28.5, 0) AS filas_para_1_tb,
ROUND(1000000000000.0 / 28.5 / 1000 / 365, 0) AS anios;
filas_para_1_tb anios --------------- ------- 35087719298.0 96131.0
Noventa y seis mil años 😂
Obviamente una boleta real pesa más que 28 bytes, porque lleva líneas, nombres y direcciones. Pero aunque pesara cien veces más, seguirían siendo casi mil años. El orden de magnitud es el argumento, no el decimal.
7. El error de creer que contar es caro
Cuenta las 200.000 filas y después cuéntalas agrupadas. ¿Cuál crees que tarda?
SELECT COUNT(*) AS filas,
COUNT(DISTINCT ciudad) AS ciudades,
ROUND(AVG(monto), 2) AS ticket,
MIN(monto) AS minimo,
MAX(monto) AS maximo
FROM grande;
filas ciudades ticket minimo maximo ------ -------- ------ ------ ------- 200000 6 1000.0 0.0 1999.99
Las cinco cosas de golpe y ni te diste cuenta. Una base de datos está hecha exactamente para esto, y por eso es tan mal negocio bajarse los datos a un Excel para hacer lo mismo 📊
8. Y ahora tú: ¿lo tuyo es big data?
Coge el número que guardaste al empezar el capítulo, el de tu tabla más grande, y contesta estas tres.
-- 1. ¿Cabe en una máquina? Multiplica tus filas por 500 bytes, -- que es una fila gorda de verdad. Si da menos de 100 GB, cabe. -- 2. ¿Llegan más rápido de lo que los guardas? -- 3. ¿Tienen forma de tabla, o son videos, audios y texto libre? SELECT 'si contestaste que si, que no y que si, no es big data' AS veredicto;
veredicto ------------------------------------------------------ si contestaste que si, que no y que si, no es big data
Y si no es big data, es una noticia buenísima 🎉 Significa que todo tu problema se arregla con lo que ya sabes: un índice, un diseño que no duplique y una consulta escrita con cabeza.
La tabla enorme que pesaba menos que una foto
Antes de cerrar, la trampa. Y esta no es de código: es de la conversación que vas a tener en una reunión 🎤
La trampa
En la reunión alguien dice que la empresa ya tiene big data, porque el Excel de ventas se cuelga y son casi dos millones de registros. Nadie lo discute, y se abre un proyecto.
-- lo que se dijo -- "son 1.800.000 registros, esto ya es big data" -- lo que pesan, a 28,5 bytes por fila -- 1.800.000 x 28,5 = 51,3 MB -- lo que aguanta SQLite en una laptop -- 5.000.000 de filas = 142 MB, GROUP BY en 3,07 s
Qué está mal
Cincuenta y un megas 📎 Eso cabe en un correo. Y esa reunión acaba de abrir un proyecto de infraestructura para un archivo que pesa menos que la presentación donde se propuso.
Lo que pasó es que se confundieron dos cosas distintas: que a Excel se le acabe la hoja no dice nada del tamaño de tus datos. Excel se planta en 1.048.576 filas por diseño, no por volumen, y a una base normal esas mismas filas le sobran cinco veces.
El daño no es solo el dinero del proyecto. Es que el problema real, que casi siempre es un índice que falta o una tabla que duplica, se queda sin arreglar mientras todo el mundo mira hacia otro lado durante seis meses.
La pregunta que desarma esta conversación en diez segundos, y la hago siempre: ¿cuánto pesa la tabla? No cuántas filas tiene, cuánto pesa. Si nadie en la sala sabe contestarla, todavía no hay nada que decidir.
Comprueba que lo tienes
Una tienda guarda 40 millones de líneas de venta al año, ordenadas en tablas, y consulta el reporte una vez al día. ¿Es big data?
- No. Cabe de sobra en una base normal y se consulta una vez al día
- Sí, cuarenta millones de filas ya es big data
- Sí, porque son datos de varios años acumulados
- Depende de si usan Hadoop o Spark
Lo que te llevas
- 📦 Big data es cuando los datos no caben ni se procesan en una máquina. No es un número de filas.
- 🔢 Con que falle una de las tres V ya tienes el problema. Y muchas veces la que falla es la velocidad, no el volumen.
- 💻 Cinco millones de filas son 142 MB y un GROUP BY de tres segundos, en una laptop y con la base más humilde que existe.
- 📄 Excel se rinde en 1.048.576 filas, casi cinco veces antes que eso.
- 🗓️ Para llenar un terabyte a 28,5 bytes por fila harían falta 35 mil millones de filas.
- ☁️ A BigQuery le escribes SQL normal. Lo de este libro sigue valiendo si algún día llegas ahí.
- 🔧 Antes de repartir entre máquinas: un índice, un diseño que no duplique, traer solo el periodo, y guardar el resumen.
Y si de todo el capítulo te llevas una sola frase, que sea esta:
Casi nadie tiene un problema de volumen. Casi todos tienen una consulta sin arreglar.
Y si lo que te interesa no es guardar muchos datos sino predecir con ellos, ese es otro camino y empieza en la guía de machine learning, que además usa el mismo archivo de práctica 🤖
En el capítulo 15 volvemos a lo que vive dentro de la base: vistas, disparadores y lo que SQLite decidió no tener.
Que tengas un hermoso día! 🌟