Análisis de petabytes en tiempo real sin ralentizar su base de datos de producción
Separe las transacciones del análisis
El resultado: una consulta de panel que debería tardar 200 ms tarda 40 segundos mientras el análisis escanea 500 millones de filas, colapsando la CPU y la E/S. Los usuarios esperan demasiado 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 pueda solucionar con ajustes; en su lugar, requiere un cambio en la arquitectura: debe dejar de ejecutar consultas pesadas en su base de datos de producción.
Mantenga PostgreSQL centrado en las lecturas y escrituras transaccionales, mientras que OVHcloud Managed ClickHouse gestiona las consultas analíticas. Para el análisis de datos de petabytes en tiempo real, el almacenamiento de objetos compatible con S3 proporciona una capa de capacidad escalable más allá del almacenamiento principal de alta velocidad, lo que permite que su entorno analítico crezca sin ampliar la base de datos de producción.
Rendimiento y control a escala
![[object Object]](https://assets.ovhcloud.com/1fipjkCd6Fynpkj2pu4pL37bz_sYmY1YjFkODJlY2IyOGI5/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_79aa0c4f.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiX5E4qzpXh67Ljo5AmdpyC4_sOTg4ZGYwMzQ5ZmJhOTY0/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_2d4e9ac8.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fipChngFS3mvuo2AkLC4LAjh_sZGYyMTFhOGIzZGFjOWVm/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_1f60228d.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fid6rzboLjodqmFX8pbmmpr8_sZDc4MTgzZjQ2OTg2NTIw/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_0703c5fb.svg){kind=small}
Por qué la escalabilidad de bases de datos de producción no satisface la demanda analítica
Presión sobre la base de datos transaccional
Las bases de datos transaccionales destacan en búsquedas, inserciones y actualizaciones breves. El análisis de datos de petabytes en tiempo real crea una demanda diferente: escaneos amplios, uniones complejas y agregaciones repetidas que compiten con el tráfico de producción por la CPU, la memoria y la velocidad de almacenamiento. Una instancia de base de datos de Public Cloud de producción está diseñada para transacciones, no para análisis. Cuando los equipos de business empiezan a pedir paneles de control en tiempo real, detección de fraudes o consultas de segmentación de clientes sobre terabytes de datos históricos... en este caso, el rendimiento se desploma.
Limitaciones de las réplicas de lectura
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. Estas descargan el tráfico de lectura del nodo principal, pero no solucionan la incompatibilidad arquitectónica. 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 todas las filas. Estas consultas analíticas compiten con las transacciones de producción por la CPU, la memoria y la 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 supervisión de anomalías, se vuelven imposibles.
Separación duradera de cargas de trabajo
Un enfoque duradero separa las cargas de trabajo. Apache Kafka transmite eventos confirmados a una plataforma dedicada creada para analíticas a escala de petabytes. Las bases de datos de producción siguen sirviendo transacciones, mientras que el entorno analítico se escala de forma independiente para datos a gran escala, análisis en tiempo real, inteligencia artificial e inteligencia empresarial.
Asigne cada carga de trabajo al motor adecuado
Almacenan los datos fila a fila, optimizados para buscar el registro de un solo cliente 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 conjuntos complejos. Utilizan almacenamiento en columnas, donde cada columna se almacena de forma independiente. Esto significa que cuando consulta SUM(revenue) WHERE date > '2025-01-01', la base de datos lee solo las columnas de ingresos y fecha, omitiendo todo lo demás. Por tanto, 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 aumentos de la carga de hardware hará que una base de datos orientada a filas sea eficiente en escaneos de columnas. Las arquitecturas son fundamentalmente diferentes.
Elija un patrón de carga para cada fuente de datos
Streaming
Entregue eventos de forma continua cuando los paneles de control operativos y las alertas dependan de información de baja latencia.
Procesamiento por lotes
Utilice el ETL por lotes con Airflow para programar cargas de datos históricos, exportaciones periódicas y cargas masivas de fuentes.
Captura de datos modificados
Propague los cambios confirmados en la base de datos limitando al mismo tiempo el trabajo adicional en la fuente transaccional.
Ingesta directa
Permita que las aplicaciones escriban eventos analíticos directamente cuando sus equipos posean y gobiernen el contrato de eventos.
Separación de OLTP de OLAP
Cuando consulta SUM(revenue) a través de 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 del vector 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 en columnas 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.
![[object Object]](https://assets.ovhcloud.com/1fiz3Ewd3ACopFnjLbkLvoSdp_sYjBlNTU5YjQyYWVjNjdl/76542f62-8c49-48e5-92ec-910825c8d69c_ima_e302634e.png)
Diseño para la frescura, la velocidad, la resiliencia y la gobernanza
ETL por lotes
El ETL por lotes es el punto de partida más sencillo.
Extraiga datos de su base de datos de producción según un horario (cada hora o diariamente), transfórmelos con dbt y cárguelos en ClickHouse. Airflow orquesta el pipeline, o los trabajos cron gestionan scripts sencillos.
Esto funciona cuando no necesita frescura minuto a minuto. Los paneles de control horarios son adecuados para muchos casos de negocio, y el procesamiento por lotes es más fácil de depurar y supervisar.
La contrapartida es la latencia que crea. Los datos quedan obsoletos entre lotes, por lo que la detección de fraudes en tiempo real o la personalización en directo no son posibles. El ETL por lotes es adecuado cuando empieza con ClickHouse, carece de experiencia en streaming o tolera datos de hace una hora.
CDC en tiempo real
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 su 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, monitorización de anomalías que alerta en segundos, personalización que reacciona instantáneamente para respaldar el comportamiento del usuario.
Almacenamiento por niveles para mantener los costes lineales a escala de petabytes
Almacenar petabytes en SSD tiene un costo prohibitivo. El almacenamiento por niveles mueve los datos más 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 procesamiento de flujo 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 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 escala: cada terabyte adicional cuesta lo mismo a 10 TB o a 100 TB.
Preagregación en el momento de la ingesta
Incluso con almacenamiento de datos en columnas, escanear datos sin procesar cada vez resulta costoso.
Las vistas materializadas precalculan datos agregados en el momento de la ingesta.
En ClickHouse, una vista materializada es un pipeline activo, no una instantánea pasiva (snapshot). Cuando inserta datos, ClickHouse evalúa automáticamente la consulta de la vista y escribe los resultados en una tabla separada.
Si está ingiriendo 100 000 eventos por segundo con una vista que agrega por minuto y segmento, ClickHouse calcula esos datos agregados en tiempo real.
Por qué ClickHouse es el motor adecuado para el análisis en tiempo real
ClickHouse logra una latencia en menos de un segundo en consultas que escanean miles de millones de filas gracias al almacenamiento en columnas, 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 ofrece precios estables basados en recursos con alta concurrencia y escalabilidad eficiente, ideal para análisis interactivos en tiempo real. Redshift es mejor para el almacenamiento de datos orientado a lotes con cargas de trabajo predecibles e infraestructura de AWS existente. BigQuery destaca en análisis sin servidor con consultas esporádicas y equipos que desean cero sobrecarga operativa.
ClickHouse utiliza un dialecto SQL que es 90% compatible 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.
Explore OVHcloud Managed ClickHouse, o trabaje con nuestros especialistas para dimensionar una arquitectura en torno a su volumen de datos, frescura, retención y concurrencia de consultas.