De las tarjetas perforadas a la nube: la historia de almacenar información

Para entender el presente, necesitas conocer el pasado. Cada tecnología que usamos hoy existe porque alguien tuvo un problema que las herramientas de su época no podían resolver. Nadie inventó la base de datos por diversión — la inventaron porque buscar información en tarjetas perforadas era un infierno. Nadie inventó el almacenamiento en la nube por capricho — lo inventaron porque los discos duros se quedaban pequeños y se rompían. Esta lección es un viaje por la historia viva de cómo llegamos hasta aquí.

Piensa en esta analogía: imagina que tu abuela guardaba sus recetas en un cuaderno manuscrito. Funcionaba bien cuando tenía 50 recetas. Pero imagina que hereda 5.000 recetas de tres generaciones — ahora necesita un sistema para encontrar "aquella de tarta de manzana que hacía la bisabuela". Pasa del cuaderno a fichas en una caja organizada por tipo de plato. Cuando la familia crece y todos quieren acceder a las recetas, pasa a un documento digital compartido. Cuando hay 100.000 recetas de toda la familia extendida en 12 países, necesita una aplicación web con buscador. Cada salto resuelve el problema del paso anterior.

### Era 1: Las tarjetas perforadas (1890-1960)

La historia empieza en 1890, con el censo de Estados Unidos. El censo anterior (1880) había tardado 8 años en procesarse. Al ritmo de crecimiento poblacional, el censo de 1890 tardaría más de 10 años — terminando después del siguiente censo. Herman Hollerith inventó una máquina que leía tarjetas de cartulina con agujeros: cada posición del agujero representaba una respuesta (edad, estado civil, ocupación). Las máquinas contaban los agujeros automáticamente. El censo de 1890 se procesó en 2 años.

Las tarjetas perforadas dominaron durante 70 años. Cada tarjeta almacenaba unos 80 caracteres — una línea de texto. Un programa era un mazo de cientos o miles de tarjetas. Si se te caían al suelo y se desordenaban... empezabas de nuevo (a no ser que hubieras numerado cada tarjeta — el primer "control de versiones" de la historia). Era físico, lento y frágil. Pero estableció un principio fundamental: los datos se pueden representar como patrones (agujeros/no agujeros, ceros/unos) y una máquina puede procesarlos más rápido que un humano.

### Era 2: Las cintas magnéticas y los mainframes (1950-1975)

Con la llegada de los ordenadores electrónicos en los años 50, se necesitaba algo mejor que cartulina. Las cintas magnéticas permitían almacenar millones de caracteres en un carrete. El problema: eran secuenciales. Para llegar al dato número 500.000, tenías que rebobinar y avanzar por los 499.999 anteriores — como un casete de música donde no puedes saltar directamente a la canción 7. Eran perfectas para procesar grandes volúmenes de principio a fin (nóminas, facturas), pero terribles para buscar un dato concreto.

Los mainframes — ordenadores gigantescos del tamaño de una habitación — procesaban los datos de grandes empresas y gobiernos. IBM dominaba. Un mainframe costaba millones de dólares. Los "programadores" vestían bata blanca y reservaban tiempo de máquina como quien reserva un quirófano. Los datos se organizaban en archivos planos: un archivo por tabla, con registros de longitud fija. No había forma de relacionar datos entre archivos de manera eficiente.

### Era 3: Los discos duros y el acceso directo (1960-1980)

El disco duro cambió las reglas. A diferencia de la cinta, un disco puede saltar directamente a cualquier posición — como un vinilo donde puedes poner la aguja en cualquier surco. De repente, buscar el registro número 500.000 era instantáneo, no había que recorrer los anteriores. Esto abrió la puerta a una idea revolucionaria: ¿y si pudiéramos organizar los datos de forma que las búsquedas fueran rápidas? ¿Y si pudiéramos crear índices, como el índice de un libro, que te dicen directamente en qué página está lo que buscas?

### Era 4: El modelo relacional (1970-presente)

En 1970, un matemático de IBM llamado Edgar F. Codd publicó un paper que cambió la historia: "A Relational Model of Data for Large Shared Data Banks". La idea era elegante: organizar los datos en tablas (relaciones matemáticas) con filas (registros) y columnas (campos). Las tablas se podían relacionar entre sí mediante claves compartidas. Y lo mejor: propuso que el usuario no tuviera que decir CÓMO buscar los datos (recorre este archivo, ve a la posición X), sino solo QUÉ quiere ("dame los clientes de Madrid con más de 3 pedidos") y el sistema se encargaría de buscarlo eficientemente.

Esa idea se materializó en SQL (Structured Query Language), un lenguaje que aprenderás en profundidad en la próxima Skill. SQL fue tan bueno que 55 años después seguimos usándolo a diario. Las bases de datos relacionales (Oracle, MySQL, PostgreSQL) dominaron las décadas siguientes. Toda empresa mediana o grande tenía al menos una. Y ese principio de "dime qué quieres, no cómo buscarlo" sigue siendo la base del análisis de datos moderno.

### Era 5: La explosión de Internet y los datos masivos (2000-2010)

Internet lo cambió todo. De repente, millones de personas generaban datos simultáneamente: buscaban en Google, compraban en Amazon, publicaban en redes sociales. Los volúmenes pasaron de gigabytes a terabytes y petabytes. Las bases de datos relacionales, diseñadas para un servidor potente, empezaron a quedarse sin aliento. Google fue la primera empresa en enfrentar el problema a una escala sin precedentes: indexar miles de millones de páginas web en un solo sistema no era viable. Su solución: usar miles de ordenadores baratos trabajando en paralelo en lugar de un solo ordenador carísimo.

Google publicó sus ideas en papers académicos, y la comunidad open-source las implementó. Así nació una nueva generación de herramientas de procesamiento masivo que aprenderás más adelante en este curso. Lo que importa ahora es el concepto: cuando los datos no caben en un ordenador, los repartes entre muchos. Es como una mudanza: si tienes 500 cajas y un solo amigo, tardas todo el fin de semana. Si llamas a 20 amigos, terminas en 2 horas.

### Era 6: La nube y el almacenamiento infinito (2010-presente)

Hasta 2010, si querías almacenar datos, comprabas discos duros y servidores. Si te quedabas sin espacio, comprabas más. Si se rompía un disco, perdías datos (a menos que tuvieras copias). Si tenías un pico de demanda (Black Friday), o comprabas capacidad extra que el resto del año estaba ociosa, o tu sistema se caía. Era como ser dueño de una fábrica: aunque solo produces 8 horas al día, pagas la hipoteca las 24 horas.

La nube ofrece un modelo diferente: alquilas capacidad en lugar de comprarla. Necesitas almacenar 1 TB hoy y 10 TB mañana? Simplemente lo haces — no compras discos, no contratas técnicos, no te preocupas por copias de seguridad. Pagas por lo que usas, como la luz o el agua. Y si un disco se rompe en la nube, hay copias automáticas en otros centros de datos a kilómetros de distancia. Es como pasar de tener tu propio generador eléctrico a simplemente enchufarte a la red.

### El presente: datos por todas partes

Hoy vivimos en un mundo donde almacenar datos es barato, procesarlos es rápido y las herramientas son accesibles. El problema ya no es técnico (podemos almacenar y procesar casi cualquier cosa) sino organizativo: ¿cómo gestionamos esta avalancha? ¿Cómo encontramos lo que necesitamos entre petabytes de datos? ¿Cómo nos aseguramos de que los datos son correctos? ¿Quién tiene acceso a qué? Esas son las preguntas que resuelve un ingeniero de datos hoy.

Y aquí es donde entras tú. No necesitas haber vivido cada era para trabajar hoy — pero entender el camino te da perspectiva. Cuando alguien te diga "guardemos esto en formato columnar", entenderás que es la evolución natural del modelo relacional de Codd adaptado a volúmenes modernos. Cuando alguien hable de "procesamiento distribuido", sabrás que es la idea de usar muchos ordenadores baratos en paralelo. Todo conecta.

### Los números que importan: escala de los datos

• ▹1 Byte = 1 carácter de texto. La letra "A".
• ▹1 Kilobyte (KB) = 1.000 bytes. Un email corto.
• ▹1 Megabyte (MB) = 1.000 KB. Una foto de alta calidad.
• ▹1 Gigabyte (GB) = 1.000 MB. Una película en HD.
• ▹1 Terabyte (TB) = 1.000 GB. Todos los libros de una biblioteca grande.
• ▹1 Petabyte (PB) = 1.000 TB. Lo que genera Netflix en un día.
• ▹1 Exabyte (EB) = 1.000 PB. Todo el tráfico de internet en unas horas.

Cuando hablamos de "Big Data", estamos en el rango de terabytes a petabytes. Una empresa mediana puede tener entre 1 y 100 TB. Una grande (banco, telco, red social) puede manejar petabytes. Pero incluso con "solo" 10 GB de datos, si están mal organizados, ya tienes un problema real. El tamaño importa, pero la organización importa más.

Hasta ahora todo es historia. Aquí va la primera cuenta que vas a hacer cien veces en tu carrera: estimar cuánto pesan los datos. La regla es una escalera donde cada peldaño multiplica por 1024:

1# Un carácter ocupa 1 byte, y cada escalón multiplica por 1024
2bytes_totales = 1000000 * 200          # un millón de registros de 200 caracteres
3
4print(bytes_totales / 1024)            # 195312.5 KB
5print(bytes_totales / (1024 * 1024))   # 190.7 MB
6
7# División entera: se queda con la parte de abajo, sin decimales
8print(7 / 2)      # 3.5   división normal
9print(7 // 2)     # 3     división entera — útil para repartir en partes iguales