El caso
Ventas que nadie logra sumar. El informe del mes congela la tienda.
Isaac quiere saber cuánto vendió la tienda por región en los últimos tres años. La pregunta parece simple, pero el pedido va contra la base de datos que atiende a los clientes. Cuando alguien ejecuta la consulta, la compra se vuelve lenta y el contador recibe una hoja de cálculo que nadie revisa.
Mientras tanto, el equipo de marketing quiere saber en qué páginas del sitio las personas están antes de comprar. Esos clics no se guardan en ningún lugar.
Este post parte de Bases de datos en la nube y de Almacenamiento en la nube: bloque, archivo y objeto. Allí la pregunta era dónde guardar el dato. Aquí cambia: qué hacer con el dato una vez guardado.
El problema
Dos tipos de trabajo en la misma base de datos
Atender la tienda y analizar la tienda son trabajos distintos:
- Atender es escribir y leer pocas filas, muchas veces por segundo, sin error. Un pedido no puede quedar a medias.
- Analizar es leer millones de filas para responder una pregunta, una o algunas veces al día.
La solución
Tres formatos de dato
Antes de elegir el servicio, hay que conocer la forma del dato:
Estructurado
Filas y columnas con un formato fijo: pedidos, artículos, existencias.
En la tienda: cada pedido siempre tiene fecha, cliente, valor y estado.
Semiestructurado
Clave y valor, o documentos (como JSON), en los que cada registro puede tener campos distintos.
En la tienda: el carrito de cada cliente, con artículos y opciones que cambian de un producto a otro.
No estructurado
Archivos sin una tabla por dentro: imágenes, PDF, audios.
En la tienda: las fotos de los productos y las facturas en PDF.
El formato orienta la elección: el dato estructurado va a una base relacional, el semiestructurado a una base de documentos y el no estructurado a Cloud Storage.
No confundas
Transaccional × analítico
Transaccional (OLTP)
“¿Cómo entra el pedido en la tienda?”
- Ejemplo
- Un cliente finaliza el carrito: la compra, las existencias y el pago se registran en milisegundos.
- Foco
- Muchas operaciones pequeñas, al mismo tiempo, sin perder ninguna. Servicios: Cloud SQL y Spanner.
Analítico (OLAP)
“¿Cuánto vendimos por región en los últimos tres años?”
- Ejemplo
- Una consulta lee millones de filas, pero solo tres columnas: región, fecha y valor.
- Foco
- Pocas consultas, pero enormes, sobre muchos datos. Servicio: BigQuery.
La diferencia aparece en la forma de guardar. La base transaccional guarda cada fila junta, lo que ayuda a escribir y leer un pedido completo de una vez. La analítica guarda cada columna junta, lo que permite leer solo la columna de la pregunta y comprimir bien los datos repetidos, como los nombres de las regiones.
Por debajo
Del clic al informe
Los clics del sitio no van directo al informe. Pasan por un camino:
- Captura: el sitio publica cada clic en Pub/Sub. Quien publica no espera a que alguien lo procese: si el procesamiento está lento, el sitio sigue en línea y los mensajes esperan en la cola.
- Transformación: Dataflow lee los mensajes, descarta lo que no interesa (un robot de búsqueda, por ejemplo) y agrega por minuto.
- Almacenamiento para análisis: el resultado va a BigQuery, donde se hacen las preguntas de marketing.
Ese camino es de streaming: el dato se procesa a medida que llega. La exportación nocturna de los pedidos, en cambio, es por lotes (batch): un bloque de datos se procesa de una vez, y el mismo Dataflow sirve para los dos casos.
Para series de tiempo con un volumen muy grande, leídas por clave, Bigtable es otra opción. Para preguntas que cambian cada día, BigQuery es la elección.
La solución completa
El lago y la gobernanza
No todo dato necesita organizarse antes de guardarse. Un data lake es un repositorio de datos brutos, en formatos variados, guardado en Cloud Storage porque es barato y duradero. Los datos entran tal como son y se tratan después, cuando alguien los necesita.
El riesgo es convertir el lago en un depósito sin dueño. La gobernanza responde preguntas simples: quién es responsable de cada conjunto de datos, quién puede leerlo y si el dato es correcto. En Google Cloud, Dataplex Universal Catalog organiza el lago y el warehouse en un solo panel, aplicando las mismas reglas de acceso y un catálogo para encontrar los datos.
En la práctica
Dónde queda cada dato de la tienda
| Dato | Dónde queda | Por qué |
|---|---|---|
| Pedidos de la tienda | Cloud SQL | Transacciones con consistencia, en milisegundos |
| Carrito de cada cliente | Firestore | Los campos cambian de un producto a otro |
| Fotos y facturas en PDF | Cloud Storage | Archivos grandes, baratos y duraderos |
| Clics en el sitio | Pub/Sub, Dataflow y BigQuery | Eventos casi en tiempo real, filtrados y agregados |
| Ventas por región | BigQuery | Consultas sobre muchos datos, sin tocar la tienda |
Términos clave
Cinco términos para fijar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
Un informe necesita sumar las ventas de cinco años, por región, leyendo millones de filas. ¿Qué servicio conviene más?
02
¿Dónde guardar las fotos de los productos y las facturas en PDF?
03
Los clics del sitio deben llegar al informe casi en tiempo real, sin que el sitio espere el procesamiento. ¿Qué combinación logra eso?
Cada pregunta pide un lugar distinto. El pedido necesita una transacción rápida, el informe necesita lectura masiva y el clic necesita un camino propio hasta el panel. Separar esas tres cosas es lo que impide que el informe congele la tienda.