El rendimiento por sí solo no basta
(motherduck.com)- Al elegir una base de datos, si solo se miran la velocidad bruta de las consultas y los benchmarks generales, es fácil perder de vista el tiempo total que le toma al usuario pasar de una pregunta a una respuesta
- El benchmark de GigaOm de 2019 puso por delante a Azure Data Warehouse y Redshift, pero en el mercado real Snowflake y BigQuery se vendieron mejor, mostrando el peso de factores más allá del rendimiento
- Aunque se reduzca el tiempo de ejecución del servidor, rutas periféricas como el driver JDBC, la descarga de resultados, el parsing de CSV o la dificultad de escribir SQL pueden convertirse en cuellos de botella aún mayores
- ClickBench, TPC-H y TPC-DS son útiles, pero las conclusiones cambian según haya o no JOIN, se escanee una sola tabla, se ajuste el esquema o se exijan condiciones de exactitud y garantías ACID
- El rendimiento del motor de base de datos tiende a converger con el tiempo, por lo que el criterio de elección a largo plazo debería ser, más que el ranking actual, la velocidad para pasar de la idea a la respuesta y la integración con el flujo de trabajo
La latencia real que los benchmarks no capturan
- En un trayecto de 4.5 horas desde una casa en Seattle hasta una oficina en San Francisco, incluso si la velocidad de crucero del avión aumentara 10 veces, el tiempo total podría reducirse solo alrededor de un 20% por el traslado al aeropuerto, seguridad, abordaje, espera en pista, equipaje y traslado al destino
- Con las bases de datos pasa algo parecido
- Aunque el motor sea más rápido, el usuario también lidia con archivos CSV extraños, problemas difíciles de expresar en SQL y fallas al conectar herramientas
- Un producto que gana la guerra de benchmarks es fácil de promocionar, pero eso no significa que reduzca de inmediato el tiempo que tarda un usuario en resolver su problema
- Al elegir una base de datos, la facilidad de uso, el ecosistema, la velocidad de actualización y la integración con el flujo de trabajo pueden ser mejores criterios
- El rendimiento solo muestra el tiempo de ciertas tareas en un momento específico, y puede hacer que uno optimice con mucho esfuerzo un cuello de botella mal identificado
Los resultados de GigaOm en 2019 y su desfase con el mercado
- En 2019, GigaOm ejecutó benchmarks de TPC-H y TPC-DS sobre data warehouses en la nube
- Los participantes eran los 3 grandes proveedores de nube y Snowflake
- Los resultados mostraron a Azure Data Warehouse como el más rápido, seguido por Redshift, mientras Snowflake y BigQuery quedaban bastante atrás
- En ese momento, en las evaluaciones de usuarios de BigQuery, era común que clientes que lo comparaban directamente con Azure terminaran eligiendo BigQuery
- El resultado del mercado fue casi el opuesto al ranking del benchmark
- Snowflake y BigQuery se vendieron más que Redshift
- Redshift se vendió mejor que Azure
- TPC-H y TPC-DS eran pruebas estándar de la industria y también se usaban para evaluar rendimiento interno, pero si los clientes compraron más sistemas que salían mal parados en buenos benchmarks de rendimiento, entonces puede concluirse que había factores más importantes que el rendimiento
Lo que el usuario percibe como rapidez no es el tiempo del servidor
- Quienes construyen bases de datos tienden a centrarse en el tiempo de ejecución del servidor entre que el usuario presiona el botón “run” y los resultados quedan listos
- El tiempo importante para el usuario es el total que tarda en terminar su tarea, y eso no es lo mismo que el tiempo que el servidor de base de datos tarda en ejecutar la consulta
- El caso del driver JDBC de BigQuery muestra bien esta diferencia
- El driver JDBC era una interfaz genérica usada por programadores y herramientas de BI para conectarse a la base de datos
- Las consultas de BigQuery se ejecutaban en 1 a 2 segundos, pero por la forma en que el driver hacía polling de finalización y descargaba resultados, para el usuario parecían tardar varios segundos o incluso minutos más
- Cuando había muchos resultados, el driver traía por páginas incluso datos que el usuario no necesitaba, lo que aumentaba la latencia y a veces provocaba fallas por falta de memoria
- Los ingenieros dedicaban mucho tiempo a recortar fracciones de segundo del tiempo de consulta, pero el conector que los usuarios realmente usaban añadía una latencia mayor
- Los benchmarks internos corrían todos los días, pero no mostraban el rendimiento end-to-end ni el tiempo que percibía el usuario
El rendimiento no queda fijado en un solo número
- El rendimiento debe medirse desde la perspectiva del usuario, no desde la de la base de datos, y como la UX, es difícil describirlo por completo con un solo número
- Qué base de datos es más rápida depende de la carga de trabajo real
- Aunque un Lamborghini sea más rápido que un Prius, en un embotellamiento puede que el tiempo para llegar al trabajo no cambie
- La diferencia de rendimiento entre ClickHouse y Redshift también depende de cómo se usen
- El ClickBench de ClickHouse mostró resultados donde ClickHouse era más rápido que varias otras bases de datos
- El benchmark funcionaba sobre una sola tabla y sin JOIN, y dependía mucho de conteos distinct
- Puede ser un buen indicador sustituto para análisis de logs o para calcular usuarios únicos de un sitio web
- Puede llevar a conclusiones engañosas para cargas de trabajo de esquema estrella típicas de un data warehouse tradicional
- Los benchmarks de proveedores normalmente se enfocan en lo que ese proveedor hace bien
- BigQuery puede verse flojo en benchmarks, pero como casi no tiene knobs y en general se autoajusta, en la experiencia real del usuario puede sentirse muy bien
- Una instancia de SingleStore altamente tuneada puede superar ampliamente a BigQuery en muchas tareas, pero requiere tiempo de ajuste del esquema y capacidad de respuesta al agregar nuevas cargas de trabajo
- También es posible ganar rendimiento reduciendo protecciones o exactitud
- eliminar overflow check
- omitir write flush
- ofrecer resultados aproximados en algunas operaciones
- no proporcionar garantías ACID
- Fuera de entornos controlados, estos atajos pueden ser opciones que uno no querría usar
Más importante que el ranking actual es la velocidad de mejora
- Al crear una empresa basada en DuckDB, hubo quienes señalaron que DuckDB quedaba muy rezagado en el benchmark de h2o.ai
- Hubo dos razones para no preocuparse
- el rendimiento era un factor secundario
- DuckDB estaba mejorando a una velocidad muy alta
- En la rápida mejora de DuckDB influyeron algunas decisiones de arquitectura, una base de código relativamente nueva y limpia, y excelentes ingenieros
- En los resultados públicos de una versión más reciente de DuckDB en ese mismo benchmark, DuckDB pasó de la mitad de la tabla al grupo líder con amplia diferencia
- Elegir una base de datos es una decisión que dura varios años, así que no solo importan el rendimiento y las funciones actuales, sino también lo que será capaz de hacer dentro de un año
- Si dos bases de datos mejoran a ritmos distintos, probablemente convenga elegir la que se mueve más rápido
La brecha de rendimiento se reduce con el tiempo
- Si varias bases de datos con mantenimiento activo se mejoran de forma iterativa durante algunos años, el rendimiento tiende a converger
- Una técnica de rendimiento de un producto puede terminar implementándose también en otros con el tiempo
- Si ClickHouse usa una técnica ventajosa para velocidad de escaneo, Snowflake podría tener una función parecida en 1 o 2 años
- Si Snowflake agrega materialized view incremental, BigQuery podría seguirlo poco después
- Cada base de datos usa técnicas distintas para lograr rendimiento
- compilar consultas a código máquina
- cachear datos en SSD local
- procesar shuffle con hardware de red especializado
- Las técnicas efectivas, con tiempo suficiente, pueden ser implementadas por cualquiera, y si funcionan bien, es probable que se propaguen entre varios sistemas
- En la comparación de rendimiento de data warehouses del CEO de Fivetran, George Fraser, en 2020 el tiempo más rápido era de 8 segundos y el más lento de 18 segundos, pero en 2022 tres proveedores estaban cerca de 7 segundos y el más lento en 9 segundos
- Aun así, las diferencias de arquitectura son difíciles de superar
- una base de datos shared nothing puede estar en desventaja frente a una shared disk
- a Redshift le tomó varios años pasar principalmente a una arquitectura shared disk
- un lakehouse que guarda metadatos en object storage puede tener dificultades con actualizaciones rápidas
- Estas diferencias suelen aparecer sobre todo en condiciones límite, y a largo plazo no hay una razón esencial para que Redshift deba ser intrínsecamente más rápido o más lento que Snowflake
Funciones que reducen el tiempo entre la pregunta y la respuesta
- El rendimiento que importa al usuario es el tiempo desde que surge una pregunta hasta que obtiene una respuesta
- Reducir ese tiempo no depende solo de mejorar el plan de ejecución de consultas
- se puede hacer más fácil expresar la pregunta
- se pueden hacer más fáciles de entender los resultados de la consulta
- se puede dar retroalimentación cuando se formula una pregunta incorrecta
- se puede ayudar a entender problemas en los datos
- se puede preparar la información necesaria en el lugar y formato correctos
- Snowflake tenía una fortaleza clara en hacer que cuando el usuario escribía SQL, “simplemente funcionara”
- al calcular diferencias de fechas, se podía usar tanto DATEDIFF como TIMEDIFF
- si los tipos eran razonables, ambos funcionaban
- se podía especificar o omitir la granularity
- se podían usar o no comillas en la granularity
- DuckDB también agregó funciones de Friendlier SQL para facilitar la escritura y el mantenimiento de consultas
GROUP BY ALLreduce omisiones de campos en la cláusula GROUP BY en consultas agregadas- basta cambiar la lista de SELECT, así que al evolucionar una consulta disminuye la necesidad de modificar varias partes
- como esta función resultó útil, varios proveedores de bases de datos agregaron capacidades similares
- Los archivos CSV son un formato que contiene gran parte de los datos del mundo, pero muchos están mal construidos y parsearlos es realmente difícil
- el splitter CSV inicial de BigQuery no podía hacer inference y se confundía si el esquema variaba un poco entre archivos
- el parsing de CSV es un problema más complicado de lo que parece
- Si dos ingenieros deben leer datos CSV y calcular el mismo resultado, quien pueda hacer ingest del CSV de forma más fácil y correcta puede obtener la respuesta primero, sin importar la velocidad del motor de consultas
- La forma de manejar los resultados también afecta mucho la experiencia del usuario
- si
SELECT *devuelve, como MySQL, la primera página y un cursor, los resultados pueden verse de inmediato - si, como BigQuery, hay que crear una copia de la tabla en el servidor, en tablas grandes puede tomar horas
- si el cliente intenta descargar todos los datos, puede quedarse sin memoria
- las conexiones largas son vulnerables a problemas de red, y el polling puede hacer que una consulta parezca más lenta si termina entre intervalos de sondeo
- si
Qué tener en cuenta al mirar benchmarks de DuckDB
- DuckDB es rápido, y en algunos tamaños de máquina de ClickBench está entre los mejores
- como ejemplo, se menciona el resultado en c6a.4xlarge
- DuckDB también muestra buen rendimiento en la mayoría de los benchmarks de h2o.ai, y no le va mal en TPC-H y TPC-DS
- Antes de asumir que una base de datos es rápida, hay que probarla directamente con la propia carga de trabajo
Resolver problemas rápido importa más que consultas rápidas
- Las empresas de bases de datos más exitosas no triunfaron solo por ser más rápidas que la competencia
- Redshift fue fuerte durante un tiempo, pero Snowflake pudo entrar no por su rendimiento en benchmarks sino por su facilidad de mantenimiento
- Las bases de datos que usaron el rendimiento como principal argumento de venta no obtuvieron buenos resultados en el mercado, y resistieron mejor las que facilitaron terminar el trabajo
- Los ejes que deben evaluarse al elegir una base de datos son más amplios
- no existen técnicas mágicas secretas y, salvo diferencias de arquitectura, el rendimiento converge con el tiempo
- la velocidad de mejora del motor de base de datos varía mucho, y quien se mueve rápido tiene ventaja a largo plazo
- el proveedor de base de datos más obsesionado con el rendimiento puede volverse más lento a largo plazo
- no existe una métrica única de rendimiento, y una base de datos rápida puede rendir mal en ciertas cargas de trabajo
- la función importante no es qué tan rápido se pasa de la consulta al resultado, sino qué tan rápido se pasa de la idea a la respuesta
- Una consulta rápida es mejor que una consulta lenta, pero la elección de una base de datos debe basarse en factores además de la velocidad bruta
1 comentarios
Opiniones de Hacker News
Es frustrante la parte donde, pese a años de quejas de clientes, “no tenían ni idea” de que el problema del driver JDBC estaba arruinando el rendimiento.
Dentro de Google ni siquiera usaban su propio producto como clientes reales, y como el tiempo de consulta que veían los usuarios no era visible internamente, lo trataban como problema ajeno.
El problema no fue haber dedicado demasiado esfuerzo a optimizar, sino no partir del dolor del cliente y rastrear la causa raíz. Al final, la causa real también era un problema de rendimiento.
Me encantó la historia de JDBC. Google creó una base de datos que funcionaba bien internamente, y mandó hacer por terceros una capa adaptadora para el mundo externo, pero como no funcionaba bien, los usuarios externos terminaron usando una base de datos pésima.
Fue como ponerle un envoltorio roto a un núcleo sofisticado que usa Google, haciendo que todo el producto quedara innecesariamente mal; internamente nadie se dio cuenta y a los usuarios externos también les costaba identificar la causa. Parece un ejemplo muy preciso de la estrategia open source de Google.
El problema es que, si arruinas lo suficiente las áreas no centrales, por muy sobresaliente que sea tu competencia central, deja de servir. La tercerización no es un almuerzo gratis.
El artículo dice que “el rendimiento es subjetivo” y que no basta con medirlo de forma simple, pero los ejemplos en realidad son casos donde el rendimiento sí importaba y era objetivo. Solo que estaban midiendo el objetivo equivocado.
Esto suena a un problema organizacional de la empresa. Si el objetivo final es que la gente use la nube y entregar valor, no entiendo por qué tienen métricas que no coinciden con lo que les importa a los clientes.
Dentro de Google debería haber alguien que hable directamente con los clientes para entender cuál es el problema, y que se lo transmita a los ingenieros para que sepan qué mejorar. La organización debería estar diseñada para que los ingenieros reciban las métricas que necesitan, o para que crear esas métricas sea parte del trabajo.
Me da más curiosidad saber qué métricas estaban mirando el producto y el liderazgo de la organización para haber pasado por alto ese feedback de clientes.
Al leer lo de “4,5 horas puerta a puerta desde una casa en Seattle hasta la oficina de San Francisco”, parece que los fundadores de hoy ya no se mueven a 179 millas por hora. Supongo que esto pasa cuando la Fed sube las tasas.
Hay puntos claramente buenos, pero la conclusión se siente un poco desviada. El rendimiento no es tanto secundario como se plantea aquí, sino más bien una cuestión de si es suficiente o no.
Primero tienes que pasar la prueba de ser suficientemente rápido, y recién después puedes evaluar otros factores. Antes de eso ni siquiera te sientas a la mesa de la competencia. El autor también dice que “DuckDB es rápido”; si no lo fuera, tendría que competir por rendimiento al menos hasta marcar esa casilla.
Además, la idea de que “el motor de base de datos que se mueve más rápido al final gana” puede ser cierta hasta cierto punto, pero no es muy práctica. Cuando eres un jugador nuevo, el progreso es rápido, pero cuando llegas a una posición como la de Snowflake, la velocidad inevitablemente se reduce. Desde la perspectiva de elegir un sistema hoy, no puedes extrapolar la aceleración actual indefinidamente hacia el futuro.
Aun así, la perspectiva de no medir solo de “consulta a resultado”, sino de idea a respuesta, parece algo que vale la pena explorar en profundidad por separado.
El rendimiento no es tanto “subjetivo” como relativo. Su significado está ligado a la tarea en cuestión.
Eso sí, si hablamos de interfaces de usuario que hacen que el usuario perciba algo como más rápido, como una barra de progreso que avanza ágilmente, eso es otra cosa. Es un problema de interfaz, no de base de datos.
Para decir “relativo”, tendría que no haber forma de asignarle un número al rendimiento salvo comparando entre sistemas, y eso no es cierto.
La primera web app que se volvió popular guardaba todo el estado en un dict de Python y lo volcaba al disco cada pocos minutos. Fue la API más rápida que vi en mi vida.
Después de migrar a Mongo, el rendimiento nunca se recuperó. Aun así, cuando hoy hago un sitio web, no tomo “pickledb” como primera opción.
fopen, SQLite es un punto intermedio.Encaja peor con interacciones de usuario de solicitud/respuesta, pero para datos estáticos grandes o datos de streaming reproducibles procesados de forma incremental o por lotes, creo que debería ser más común de lo que es hoy.
Estoy buscando buen material sobre el tema de que “las bases de datos shared nothing están en desventaja frente a shared disk; a Redshift le tomó años pasar principalmente a una arquitectura shared disk; y los Lakehouse que guardan metadatos en object storage tienen dificultades con actualizaciones rápidas”.
Buen artículo. Creo que esta también es una de las razones por las que pandas fue tan fuerte durante la última década.
El rendimiento en una sola máquina era suficientemente bueno, y podía leer el 99% de los CSV conocidos por la humanidad.