Las bases de datos columnares son increíblemente rápidas. Esta es la razón.

EspañolالعربيةDeutschEnglishFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
BBetter Stack
Computing/Software

Transcript

00:00:00si bien me encanta postgres no es la mejor opción para todo existe un tipo diferente de
00:00:04base de datos llamada base de datos columnar que puede ejecutar ciertas consultas hasta 40 veces más rápido estas
00:00:10bases de datos funcionan almacenando las columnas juntas en lugar de las filas lo que significa que obtienes beneficios masivos
00:00:15para ciertos casos de uso como plataformas de análisis ahora, por supuesto, todo viene con un coste de compensación
00:00:20pero hoy veremos exactamente qué son las bases de datos columnares y compararemos algunas consultas frente a
00:00:25postgres para ver los beneficios y los inconvenientes compararemos postgres con clickhouse y duckdb
00:00:31así que quédate y al final tendrás una comprensión sólida de las bases de datos basadas en columnas
00:00:36y de cuándo recurrir a la tecnología adecuada
00:00:43así que al principio dije que puedes ejecutar ciertas consultas 40 veces más rápido y eso es verdad si tomamos una
00:00:49tabla de base de datos, aquí he cargado cien millones de filas y ejecutaré una consulta group by con
00:00:55postgres esto tarda aproximadamente 9,7 segundos en ejecutarse porque estamos agregando los ingresos de cada
00:01:00fila individual si ejecutamos la misma consulta en el mismo conjunto de datos usando una base de datos columnar y eso es
00:01:06ejecutando literalmente el mismo sql exacto, tanto clickhouse como duckdb tienen una sintaxis sql similar a postgres, así que
00:01:13te resultará familiar clickhouse tarda 0,28 segundos y duckdb 0,24 segundos eso es más de 40 veces más rápido
00:01:22cómo es esto posible parece increíble, verdad los mismos 100 millones de filas en apenas 0,24 segundos
00:01:30las bases de datos columnares simplemente hacen órdenes de magnitud menos trabajo para darnos los mismos resultados
00:01:36veamos otra consulta en acción y un rápido aviso, chicos, publicamos contenido sobre inteligencia artificial y tecnología constantemente
00:01:42así que si esto es algo que disfrutas, ¿por qué no te suscribes a better stack esta vez estamos contando el número
00:01:47de eventos entre dos marcas de tiempo donde el código de país es gb en nuestro caso, estamos viendo los datos en
00:01:53marzo los resultados: postgres 5,9 segundos, clickhouse 0,06 segundos y duckdb 0,03 segundos marzo contiene
00:02:02alrededor del 13 por ciento del total de eventos aquí, por lo que postgres todavía necesita mirar millones de filas, podríamos
00:02:09añadir una indexación agresiva aquí para ayudar, pero eso no nos acercará a clickhouse y duckdb, entonces, ¿por qué
00:02:15los almacenes de columnas son mucho más rápidos aquí bueno, clickhouse no indexa las filas individuales en absoluto, cuando creas
00:02:20una tabla le das una clave de ordenamiento y como está ordenada por marca de tiempo, luego divide los datos ordenados en bloques de
00:02:32y simplemente guarda nota de la primera marca de tiempo en cada uno para 100 millones de filas, eso son unos 12 000 registros
00:02:39y eso es lo suficientemente pequeño como para caber en memoria, así que cuando pedimos marzo hace una búsqueda rápida a través de esas
00:02:44notas, encuentra los bloques que podrían contener marzo y lee solo esos en nuestro caso, son 1633 bloques de
00:02:52un total de 12 208 y todo lo demás en el disco se omite duckdb hace algo similar porque mantiene un mínimo
00:03:00y un máximo para cada fragmento de una columna, por lo que podemos mirar un fragmento, ver que las marcas de tiempo van de enero a
00:03:06febrero y omitir todo el asunto sin leerlo, añade a eso el truco anterior donde solo
00:03:10abre las columnas que necesita y obtienes 0,03 segundos pero las cosas dan un giro completo cuando quieres
00:03:17seleccionar una sola fila por id esta sencilla consulta revela mucho postgres tarda dos milisegundos, clickhouse 168
00:03:26milisegundos y duckdb, curiosamente, sigue en dos milisegundos postgres tiene un índice de árbol binario en el
00:03:32id, por lo que recorre el árbol, aterriza en la única página que contiene la fila y termina en solo dos
00:03:37milisegundos pero con clickhouse tenemos un problema su único índice es esa clave de ordenamiento y esta tabla está
00:03:43ordenada primero por marca de tiempo y segundo por id, así que cuando pedimos un solo id no tiene ni idea de en qué bloque vive
00:03:51ese id y termina comprobando cada uno de los 12 208 bloques y una vez que encuentra la fila todavía
00:03:57tiene que abrir los ocho archivos de columna y volver a armar esa fila, lo cual es mucho trabajo para una
00:04:03consulta tan simple entonces, ¿cómo se sale con la suya duckdb tuvo suerte con nuestros datos, los id se insertaron en
00:04:09orden, por lo que el mínimo y máximo de cada fragmento coinciden perfectamente con el id y duckdb puede saltar directamente al
00:04:16correcto si los id estuvieran desordenados, escanearía toda la columna al igual que clickhouse veamos ahora
00:04:21la actualización de una fila tenemos una consulta para postgres y duckdb y una versión ligeramente diferente para
00:04:26clickhouse postgres tardó cinco milisegundos, clickhouse 5,8 segundos y duckdb nuevamente solo decenas
00:04:34de milisegundos postgres simplemente reescribe una fila y actualiza una entrada de índice en clickhouse los archivos de datos
00:04:40son inmutables, nunca se modifican en el lugar, por lo que para cambiar un valor de ingresos tiene que reescribir
00:04:46todo el archivo de la columna de ingresos para ese fragmento de la tabla clickhouse incluso te hace escribir esto como un
00:04:51alter table porque lo trata como una mutación de toda la tabla hay una actualización más ligera en
00:04:56fase beta, pero solo está pensada para un pequeño número de filas, alrededor del 10 por ciento de la tabla como máximo duckdb se encuentra entre
00:05:03ambas porque su archivo se puede modificar en el lugar, por lo que la actualización de una sola fila toma unas pocas decenas de
00:05:08milisegundos y finalmente contemos el número de usuarios distintos en nuestra tabla, de nuevo una ligera
00:05:14variación de la consulta para clickhouse y los resultados son: postgres 38,4 segundos, clickhouse 0,78 segundos
00:05:22y duckdb menos de un segundo de nuevo, postgres sufre al agregar sobre una tabla entera tan grande, lo que
00:05:28requiere una cantidad enorme de trabajo ahora, a menudo querrás usar bases de datos columnares para cosas como análisis
00:05:34donde agregar datos a través de varias columnas es una tarea común aquí analizamos dos opciones: clickhouse
00:05:41es un servidor alojado, de código abierto y disponible en la mayoría de las plataformas principales para ejecutar esto localmente necesitas ejecutar
00:05:47un servidor clickhouse en tu máquina, mucho más parecido a cómo funciona postgres, sin embargo, duckdb se parece más a sqlite
00:05:54es una biblioteca que se ejecuta dentro de su propio proceso y toda la base de datos vive en un solo archivo en el disco, por lo que
00:06:00ese archivo se puede bloquear mientras una actualización está en curso, lo que arruina la concurrencia ambas son bases de datos columnares
00:06:06pero adoptan enfoques muy diferentes, por lo que la base de datos que termines usando depende de mucho más
00:06:12de lo que puedo suponer aquí, no se trata solo de la velocidad bruta de consulta al ejecutar demostraciones en tu máquina local
00:06:17se trata de escalabilidad, redundancia y extensibilidad, por supuesto, postgres tiene un rico ecosistema de complementos para
00:06:24ampliar su conjunto de características de muchas maneras, lo cual puedes ver en este próximo video

Key Takeaway

Las bases de datos columnares como ClickHouse y DuckDB ejecutan consultas analíticas hasta 40 veces más rápido que Postgres al almacenar datos por columnas y omitir bloques irrelevantes, aunque sacrifican velocidad en operaciones de una sola fila y actualizaciones.

Highlights

  • Las bases de datos columnares ejecutan ciertas consultas analíticas hasta 40 veces más rápido que Postgres en conjuntos de datos de 100 millones de filas.

  • ClickHouse procesa una consulta group by en 0,28 segundos y DuckDB en 0,24 segundos, frente a los 9,7 segundos que requiere Postgres.

  • ClickHouse no indexa filas individuales, sino que utiliza una clave de ordenamiento y divide los datos en bloques para omitir la lectura de datos irrelevantes.

  • Postgres supera a ClickHouse en la búsqueda de una sola fila por ID, resolviéndolo en 2 milisegundos gracias a su índice de árbol binario.

  • Las bases de datos columnares almacenan las columnas juntas en lugar de las filas, lo que reduce masivamente el trabajo en operaciones de agregación.

Timeline

Comparativa de rendimiento en consultas analíticas

  • Las bases de datos columnares almacenan columnas juntas para optimizar casos de uso analíticos.
  • Una consulta group by sobre 100 millones de filas toma 9,7 segundos en Postgres.
  • La misma consulta se ejecuta en 0,28 segundos en ClickHouse y 0,24 segundos en DuckDB.

Las bases de datos columnares ofrecen un rendimiento drásticamente superior en consultas de agregación masiva frente a bases de datos relacionales tradicionales como Postgres. Al procesar únicamente los datos necesarios para una columna específica, realizan una fracción del trabajo total.

Mecanismo de indexación y optimización de lectura

  • ClickHouse utiliza una clave de ordenamiento por marca de tiempo para dividir los datos en bloques manejables en memoria.
  • DuckDB utiliza valores mínimos y máximo por fragmento de columna para omitir bloques enteros sin leerlos del disco.
  • Estas técnicas permiten filtrar y procesar consultas de rangos de fecha en una fracción del tiempo de Postgres.

La velocidad de almacenamiento columnar proviene de omitir grandes porciones de datos en el disco. Al mantener metadatos sobre rangos de valores en la memoria, el motor determina instantáneamente qué bloques de datos contienen la información solicitada y descarta el resto.

Inconvenientes en consultas de una sola fila y actualizaciones

  • Postgres resuelve la búsqueda de una sola fila por ID en 2 milisegundos mediante un índice de árbol binario.
  • ClickHouse tarda 168 milisegundos en la misma búsqueda porque debe revisar múltiples bloques y rearmar la fila.
  • Los archivos de datos en ClickHouse son inmutables, lo que requiere reescribir todo el archivo de columna al actualizar un valor.

El diseño columnar penaliza las operaciones de transacciones individuales y modificaciones de registros. Debido a que las filas están fragmentadas en múltiples archivos de columna, buscar un registro único o actualizar un valor requiere operaciones de E/S costosas.

Diferencias arquitectónicas entre ClickHouse y DuckDB

  • ClickHouse opera como un servidor dedicado que requiere ejecución independiente.
  • DuckDB funciona como una biblioteca integrada similar a SQLite donde la base de datos reside en un solo archivo.
  • La elección de la base de datos depende de la escalabilidad, la concurrencia y la infraestructura necesaria.

Existen diferencias fundamentales en la implementación de los sistemas columnares analizados. Mientras ClickHouse se orienta a arquitecturas de servidor distribuidas o centralizadas, DuckDB prioriza el análisis local basado en archivos, afectando la concurrencia durante las actualizaciones.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video