Análisis de petabytes en tiempo real sin impacto en la base de datos
¿Cómo analizar petabytes de datos en tiempo real sin ralentizar vuestra base de datos de producción?
Todas las aplicaciones en crecimiento llegan al mismo punto de inflexión, donde una empresa desea consultar una base de datos PostgreSQL o MySQL con petabytes de datos, de una forma para la que nunca fue diseñada.
El resultado: una consulta de panel que debería tardar 200ms tarda 40 segundos mientras el análisis escanea 500M de filas, colapsando la CPU y la E/S. Los usuarios esperan demasiado tiempo para obtener los resultados de las consultas y, al final, todo el acuerdo de nivel de servicio (SLA) pende de un hilo.
No es un problema que podáis solucionar con ajustes, sino que requiere un cambio en la arquitectura: debéis dejar de ejecutar consultas pesadas en vuestra base de datos de producción.
En este artículo aprenderéis el patrón de arquitectura para separar OLTP de OLAP, cómo transmitir datos de forma segura a ClickHouse y por qué el servicio gestionado de OVHcloud es la opción adecuada para equipos de SaaS, FinTech, AdTech y comercio electrónico que escalan a miles de millones de filas.
Por qué vuestra base de datos de producción es el lugar equivocado para ejecutar análisis
Una instancia de base de datos de producción Public Cloud está creada para transacciones, no para análisis. Cuando los equipos de negocio empiezan a solicitar paneles en tiempo real, detección de fraudes o consultas de segmentación de clientes sobre terabytes de datos históricos... bueno, el rendimiento se desploma.
Eso no ocurre tanto porque la infraestructura sea débil, sino porque la aplicación está utilizando la herramienta equivocada para el trabajo.
OLTP frente a OLAP
OLTP (procesamiento de transacciones en línea) y OLAP (procesamiento analítico en línea) se sitúan en extremos opuestos del espectro de la arquitectura de datos.
Los sistemas OLTP priorizan la corrección y la precisión a nivel de transacción, gestionando miles de escrituras y lecturas pequeñas y rápidas por segundo. Almacenan los datos fila a fila, optimizados para buscar un registro de cliente individual o actualizar el estado de un pedido en milisegundos.
Los sistemas OLAP , por el contrario, están diseñados para escanear billones de filas para agregaciones complejas. Utilizan almacenamiento en columnas, donde cada columna se almacena de forma independiente. Esto significa que cuando consultáis SUM(revenue) WHERE date > '2025-01-01', la base de datos lee solo las columnas de ingresos y fecha, omitiendo todo lo demás. Así pues, por ejemplo en ClickHouse, las operaciones se ejecutan mediante ejecución vectorizada. ClickHouse procesa matrices enteras de valores a la vez en lugar de filas individuales, lo que reduce drásticamente la sobrecarga de la CPU y maximiza la utilización de la caché.
Ninguna cantidad de indexación de datos, optimización de consultas o actualizaciones de hardware hará que una base de datos orientada a filas sea eficiente en escaneos de columnas. Las arquitecturas son fundamentalmente diferentes.
Por qué las réplicas de lectura no resolverán el problema
Las réplicas de lectura en Public Cloud Databases son la primera respuesta más común a la presión analítica sobre las bases de datos de producción. Descargan el tráfico de lectura del nodo principal, pero no solucionan el desajuste arquitectónico.
Una réplica de lectura podría reducir la contención en su base de datos principal, pero cuando ejecuta SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' en 500M de filas, la réplica sigue leyendo y descartando casi cada fila.
Estas consultas analíticas compiten con las transacciones de producción por CPU, memoria y E/S. La latencia de la aplicación aumenta, los SLA están en riesgo y los casos de uso en tiempo real como la detección de fraudes o la monitorización de anomalías se vuelven imposibles.
La consulta de 40 segundos que debería tardar 200 ms
Este es el escenario típico para una empresa de plataforma SaaS en expansión o FinTech que alcanza el punto de inflexión de los datos. Se ejecuta una consulta, destinada a agregar los ingresos diarios por segmento de cliente durante 18 meses (500M de filas),
El tiempo esperado de ejecución bajo el modelo de dominio OLAP es de 200 ms, pero el tiempo real bajo la plataforma OLTP termina siendo de 40 segundos. ¿Por qué? Pues esto es lo que ocurre en segundo plano:
Escaneo completo de tabla: La plataforma PostgreSQL/MySQL debe leer las 500M de filas porque el índice no ayuda con las agregaciones amplias.
Procesamiento fila a fila: Cada fila se descomprime, analiza y evalúa individualmente.
Cuello de botella de E/S: Las lecturas de disco predominan: la mayor parte de los datos leídos se descartan.
Desperdicio de CPU: Ciclos de CPU dedicados al análisis de filas en lugar de a la calidad de la agregación.
Presión de memoria: Las ordenaciones grandes y las uniones hash se vuelcan a disco.
El impacto empresarial es inmediato y acumulativo, porque lo que debería ser un panel de datos por horas puede, en la práctica, generarse solo una vez al día, retrasando las decisiones empresariales.
Las decisiones empresariales se retrasan porque la analítica minuto a minuto se vuelve demasiado costosa y las funciones en tiempo real se vuelven imposibles a gran escala. Y eso importa: la capacidad de respuesta en tiempo real es esencial para casos de uso como la detección de fraudes, la personalización y la supervisión de anomalías. Estos casos de uso no son viables con una latencia de consulta de 40 segundos.
El patrón de arquitectura: separar OLTP de OLAP
La solución es la separación arquitectónica: ejecutad las transacciones en una instancia de base de datos OLTP y transmitid los datos a una instancia OLAP separada, diseñada para escanear miles de millones de filas en menos de un segundo. Cada sistema hace aquello para lo que fue diseñado, sin comprometer al otro.
Explicación del almacenamiento columnar y la ejecución vectorizada
PostgreSQL y MySQL almacenan los datos fila por fila, lo cual tiene sentido para las transacciones de ingeniería que recuperan registros individuales, pero es terrible para la analítica que agrega una columna a través de miles de millones de filas. ClickHouse almacena los datos por columnas en su lugar.
Cuando consultáis SUM(revenue) en 5 mil millones de filas, solo lee la columna de ingresos, omitiendo todo lo demás. Esto reduce la E/S en un 90% o más y permite una compresión agresiva, ya que los valores de una columna son similares.
La ejecución vectorizada es el segundo multiplicador. Las bases de datos tradicionales procesan una fila a la vez. ClickHouse procesa matrices enteras de valores a la vez, cargando un fragmento de la columna de ingresos en la caché de la CPU y aplicando operaciones en todo el volumen vectorial en una sola instrucción. Esto reduce drásticamente la sobrecarga de la CPU.
La combinación permite consultas de menos de un segundo en miles de millones de filas. El almacenamiento columnar minimiza las lecturas de disco; la ejecución vectorizada minimiza el trabajo de la CPU. ClickHouse puede agregar 10 mil millones de filas en menos de un segundo, mientras que una instancia de PostgreSQL tarda minutos.
Vistas materializadas: preagregación en el momento de la ingesta
Incluso con el almacenamiento de datos en columnas, escanear datos sin procesar cada vez resulta costoso. Las vistas materializadas precalculan agregados en el momento de la ingesta.
En ClickHouse, una vista materializada es una canalización activa, no una instantánea pasiva. Cuando insertáis datos, ClickHouse evalúa automáticamente la consulta de la vista y escribe los resultados en una tabla separada.
Si estáis ingiriendo 100.000 eventos por segundo con una vista que agrega por minuto y segmento, ClickHouse calcula esos agregados en tiempo real.
Vuestro panel consulta la tabla preagregada en lugar de escanear eventos sin procesar. Esto traslada el coste del tiempo de consulta al tiempo de ingesta, aceptando una pequeña sobrecarga de escritura para una respuesta de consulta instantánea. Para paneles minuto a minuto y detección de fraudes, las vistas materializadas eliminan la latencia entre la llegada de los datos y su capacidad de consulta.
También permiten análisis multirresolución: conservad los datos sin procesar para análisis forenses mientras mantenéis agregados horarios/diarios para los paneles. A medida que los datos envejecen, consultad agregados más generales, manteniendo un rendimiento constante a medida que escaláis de terabytes a petabytes.
Almacenamiento por niveles para mantener los costes lineales a escala de petabytes
Almacenar petabytes en SSD resulta prohibitivamente caro. El almacenamiento por niveles mueve los datos antiguos a un almacenamiento de objetos más barato mientras mantiene los datos recientes en discos locales rápidos.
Por ejemplo, OVHcloud Managed ClickHouse implementa esto de forma nativa en herramientas con el procesamiento de flujos de OVHcloud Object Storage (compatible con S3)*. Los datos recientes (30–90 días) permanecen en flujo en SSD NVMe.
Los datos más antiguos se migran automáticamente a un bucket de OVHcloud Object Storage a una fracción del coste, permitiendo aún consultas rápidas ya que ClickHouse solo lee las columnas necesarias. Los costes para los ingenieros se mantienen lineales a medida que escaláis: cada terabyte adicional cuesta lo mismo a 10 TB o 100 TB.
ClickHouse consulta los datos de OVHcloud Object Storage sin Athena, Presto o Spark. Datos activos en SSD, datos fríos en S3, todo a través de la misma interfaz SQL. Esto elimina el mantenimiento de sistemas separados para datos basados en activos y fríos.
El almacenamiento por niveles también simplifica la retención de datos a largo plazo: conservad los datos sin procesar indefinidamente por motivos de cumplimiento normativo sin arruinaros. ¿Consultáis datos de hace 18 meses para investigaciones? ClickHouse los lee desde OVHcloud Object Storage S3*, que es más lento pero lo suficientemente rápido para análisis ad-hoc.
Cómo alimentar de datos vuestra capa analítica
Una vez que hayáis separado la instancia OLTP de las herramientas OLAP, necesitáis mover los datos de vuestra base de datos de producción a ClickHouse. Existen tres patrones principales, cada uno con diferentes compromisos en latencia, complejidad y sobrecarga operativa.
ETL por lotes con Airflow, dbt o trabajos cron
El ETL por lotes es el punto de partida más sencillo. Extraed datos de vuestra base de datos de producción según un horario (cada hora o diariamente), transformadlos con dbt y cargadlos en ClickHouse. Airflow orquesta la canalización, o los trabajos cron gestionan scripts sencillos.
Esto funciona cuando no necesitáis frescura minuto a minuto. Los paneles horarios están bien para muchos casos de negocio, y el procesamiento por lotes es más fácil de depurar y supervisar. Los trabajos fallidos se reintentan en la siguiente programación, y el rellenado de datos históricos es sencillo.
El compromiso es la latencia que creáis. Los datos quedan obsoletos entre lotes, por lo que la detección de fraudes en tiempo real o la personalización en vivo no son posibles. También ejecutáis consultas de extracción pesadas en producción durante la ventana de procesamiento por lotes, lo que puede causar contención si no se programan durante periodos de poco tráfico. El ETL por lotes es adecuado cuando empezáis con ClickHouse, carecéis de experiencia en streaming o toleráis datos con una hora de antigüedad.
CDC en tiempo real con Apache Kafka y Debezium
La captura de datos modificados (CDC) transmite cada inserción, actualización y eliminación desde la producción a ClickHouse casi en tiempo real. Debezium lee el registro de transacciones de vuestra base de datos (WAL para PostgreSQL, binlog para MySQL) y publica los cambios en Apache Kafka. ClickHouse consume desde Kafka e inserta inmediatamente.
Las herramientas de CDC logran una latencia de menos de un segundo a unos pocos segundos, lo que permite un análisis de datos en tiempo real real: detección de fraudes que detecta y bloquea transacciones a medida que ocurren, monitoreo de anomalías que alerta en segundos, personalización que reacciona instantáneamente para respaldar el comportamiento del usuario.
Aunque la complejidad de la configuración es mayor, CDC es el estándar para el análisis en tiempo real a escala. La sobrecarga está justificada cuando las decisiones comerciales dependen de la frescura de los datos. Muchos equipos utilizan Kafka gestionado para reducir la carga, o comienzan con lotes y migran a CDC una vez que se valida el valor en tiempo real.
Escrituras directas de la aplicación de forma eficiente para cargas de trabajo puramente orientadas a eventos
Tu aplicación escribe directamente en las herramientas de ClickHouse junto a tu base de datos OLTP crítica. Esto funciona mejor para cargas de trabajo orientadas a eventos donde cada acción del usuario es un evento que vale la pena analizar: visitas a páginas, clics, llamadas a API, datos de sensores. La aplicación envía el evento a ambos sistemas en paralelo, o utiliza ClickHouse como principal y se sincroniza con PostgreSQL para las transacciones.
Esto elimina la capa ETL por completo. Sin Kafka, sin Debezium, sin trabajos por lotes. La aplicación escribe una vez, los datos se pueden consultar inmediatamente y la latencia es mínima.
Por qué ClickHouse es el motor OLAP adecuado para el análisis en tiempo real
ClickHouse se creó desde cero para el análisis en tiempo real de conjuntos de datos masivos. A diferencia de los almacenes de datos de propósito general que optimizan para cargas de trabajo por lotes o si vosotros u otros optimizáis para BI interactivo, ClickHouse prioriza una latencia de consulta inferior al segundo incluso al escanear miles de millones de filas.
Esto lo convierte en la opción correcta para empresas de SaaS, FinTech, AdTech y comercio electrónico que necesitan análisis que sigan el ritmo de sus sistemas de producción.
Rendimiento de consulta inferior al segundo :
ClickHouse logra una latencia inferior al segundo en consultas que escanean miles de millones de filas gracias al almacenamiento columnar, la ejecución vectorizada y la compresión agresiva. Puede agregar 10 mil millones de filas en menos de un segundo, mientras que PostgreSQL tarda minutos y otros almacenes tardan de segundos a decenas de segundos.
ClickHouse frente a Redshift frente a BigQuery :
ClickHouse ofrece precios estables basados en recursos con alta concurrencia y escalado eficiente, ideal para análisis interactivos en tiempo real. Redshift es la mejor opción para el almacenamiento de datos orientado a lotes con cargas de trabajo predecibles y una infraestructura de AWS existente. BigQuery destaca en el análisis sin servidor con consultas esporádicas y equipos que desean cero gastos operativos.
ClickHouse SQL :
ClickHouse utiliza un dialecto SQL que es compatible en un 90% con la experiencia de desarrollo SQL estándar, pero existen diferencias clave. Las funciones de agregación utilizan tablas MergeTree con una sintaxis de motor específica. La mayoría de las consultas SELECT se traducen directamente, pero los JOIN y subconsultas complejos pueden necesitar optimización.
Los consejos de migración a gestionar incluyen probar primero las consultas en un conjunto de datos host representativo, utilizar EXPLAIN de ClickHouse para optimizar los planes de ejecución de la sesión y aprovechar las vistas materializadas para precalcular agregaciones complejas de la pila de herramientas.
¿Por qué elegir OVHcloud Managed ClickHouse?
OVHcloud Managed ClickHouse es el único ClickHouse gestionado nativo ofrecido por un proveedor de nube europeo, junto con nuestras consolidadas Managed Databases for PostgreSQL . Esto significa que no hay enrutamiento de datos de terceros, ni dependencia de ClickHouse Cloud, ni flujos de datos entre proveedores.
ClickHouse gestionado de un proveedor de la UE: OVHcloud es el único proveedor de nube de la región europea que ofrece un motor ClickHouse gestionado nativo. A diferencia de la competencia, donde tendríais que enrutar a través de servicios de terceros, OVHcloud ejecuta ClickHouse directamente en su infraestructura.
Automático a OVHcloud Object Storage: Los datos fríos migran automáticamente a OVHcloud Object Storage compatible con S3*, manteniendo los costes lineales a escala de petabytes. Los datos recientes (30–90 días) permanecen en SSD NVMe para obtener la máxima velocidad, mientras que los datos más antiguos se mueven a OVHcloud Object Storage a una fracción del coste. Fundamentalmente, no hay costes de salida.
Despliegues en 3 zonas de disponibilidad en París y Milán : Los clústeres de producción se ejecutan en tres zonas de disponibilidad en París o Milán con un SLA del 99,99% en 3 A-Z, soporte técnico 24/7 incluido y replicación multinodo para una alta disponibilidad. El servicio Gen3 (desde agosto de 2025) ofrece 5× de almacenamiento, 4× de ancho de banda, 2× de TPS y un inicio 1,5× más rápido en comparación con la generación anterior; todo lo cual es mejor para escalar.
RGPD desde el diseño, sin exposición al Cloud Act: OVHcloud es una empresa francesa sujeta únicamente a la legislación francesa/europea. Todos los datos analíticos permanecen en centros de datos europeos, sin exposición al Cloud Act que afecte a los proveedores estadounidenses. Esto es especialmente relevante para los datos de comportamiento, las transacciones financieras y los datos sujetos al RGPD.
Además, los servicios de OVHcloud cuentan con las certificaciones ISO/IEC 27001/27017/27018/27701 y cumplen con HDS, con SecNumCloud en proceso. Eso incluye nuestro Managed Apache Kafka para pipelines de CDC y nuestro OVHcloud Object Storage (compatible con S3)*.
Para las empresas europeas de SaaS, FinTech, AdTech y comercio electrónico que manejan datos de clientes de la UE, esta garantía de soberanía elimina el riesgo legal de que las autoridades estadounidenses accedan a los datos almacenados con proveedores de nube estadounidenses.
Empieza: despliega ClickHouse y conéctalo a tu base de datos de producción
¿Estás listo para liberar tu base de datos de producción de consultas analíticas pesadas? Desplegar OVHcloud Managed ClickHouse solo lleva unos minutos a través del panel de control o la API.
Garantizamos que tus datos permanezcan en centros de datos europeos para asegurar la privacidad y una observabilidad total, sin costes de salida, y el almacenamiento por niveles en OVHcloud Object Storage compatible con S3* asegura que los costes sigan siendo predecibles a medida que escalas de terabytes a petabytes.
Inicia tu clúster de software ClickHouse hoy mismo y descubre por qué más de 2.000 empresas, incluidas Tesla, Bloomberg y Anthropic, confían en ClickHouse para el análisis en tiempo real.
* S3 es una marca registrada de Amazon Technologies, Inc. Los servicios de OVHcloud no están patrocinados, aprobados ni afiliados a Amazon Technologies, Inc.