Perf por sí solo no basta

La cultura de la obsesión por el rendimiento en las bases de datos

• La industria de las bases de datos está enfocada en mejorar el rendimiento, pero la experiencia real del usuario suele verse afectada por otros factores.
• Al procesar datos, lo que realmente importa para el usuario puede ser más la forma de los datos o la capacidad de formular preguntas en SQL que la optimización de consultas.
• El rendimiento de la base de datos es importante, pero puede ser mejor elegir una base de datos con base en otros factores como la facilidad de uso, el ecosistema, la velocidad de actualización y la integración con el flujo de trabajo.

El fin de la guerra de benchmarks

• En 2019, GigaOm publicó un benchmark comparando data warehouses en la nube, pero los resultados reales del mercado mostraron un panorama distinto.
• Cuando los resultados de un benchmark no coinciden con la experiencia del usuario, eso sugiere que el benchmark estaba mal, que probó lo incorrecto o que el rendimiento quizá no era tan importante.

Qué significa ser rápido

• En el ámbito de las bases de datos en la nube, existe la tendencia de enfocarse en el tiempo entre que el usuario hace clic en el botón de "ejecutar" y el momento en que el resultado está listo.
• Lo que realmente afecta al usuario es el tiempo que tarda en completar el trabajo, y eso no es lo mismo que el tiempo del servidor de base de datos.

El rendimiento es subjetivo

• El rendimiento debe medirse desde la perspectiva del usuario y, como problema de UX, no puede explicarse con un solo número.
• La subjetividad del rendimiento implica que cuál sistema es más rápido depende de cómo se use la base de datos.

La velocidad del cambio

• DuckDB está mejorando a gran velocidad, y eso vuelve irrelevantes los benchmarks actuales.
• Al elegir una base de datos, no solo importa el rendimiento actual, sino también cómo cambiarán en el futuro el rendimiento y las funcionalidades.

No hay frijol mágico

• Si todas las bases de datos se mantienen activamente, el rendimiento terminará convergiendo con el tiempo.
• Es poco probable que diferencias importantes de rendimiento se mantengan de forma duradera con el paso del tiempo.

El problema está entre la silla y el teclado, y entre el teclado y la base de datos

• La métrica de rendimiento que importa al usuario es cuánto tarda en pasar de una pregunta a una respuesta.
• La capacidad importante no es cuánto tarda la base de datos en ejecutar una consulta, sino la velocidad para pasar de una idea a una respuesta.

Sobre las uvas agrias

• DuckDB actualmente está entre los primeros lugares en los benchmarks de ClickBench y h20.ai, y también muestra un rendimiento nada malo en TPC-H y TPC-DS.
• Antes de asumir que una base de datos es rápida, es importante probarla con la carga de trabajo real.

Conclusión

• Las empresas de bases de datos más exitosas no triunfaron por tener un rendimiento más rápido que sus competidores.
• Las bases de datos que usaron el rendimiento como principal argumento de venta no tuvieron éxito en el mercado.
• Se aconseja decidir una base de datos con base en otros factores además de la velocidad bruta.

Opinión de GN⁺

• Este artículo subraya que no basta con enfocarse solo en el rendimiento de la base de datos, sino que también es importante optimizar la experiencia del usuario y el flujo de trabajo. Esto deja una lección importante incluso para ingenieros de software junior: al elegir una base de datos, conviene considerar un enfoque centrado en el usuario más allá de métricas simples de rendimiento.
• El rendimiento de las bases de datos tiende a converger con el tiempo, porque los avances tecnológicos terminan difundiéndose entre todas las plataformas. Esto sugiere que, al elegir tecnología, conviene considerar más el soporte a largo plazo y el potencial de mejora que el rendimiento de corto plazo.
• Proyectos open source como DuckDB pueden evolucionar rápidamente gracias a su ritmo de mejora y al apoyo de la comunidad. Esto implica que, al adoptar una nueva tecnología, también conviene evaluar qué tan activa es su comunidad y qué tan rápido avanza el proyecto.
• Al elegir una base de datos, es importante no depender solo de los resultados de benchmarks de rendimiento, sino probar su desempeño con cargas de trabajo reales. Eso puede ayudar a seleccionar una base de datos más adecuada para los casos de uso concretos.
• Se enfatiza que la elección de una tecnología de base de datos debe considerar no solo aspectos técnicos, sino también requisitos de negocio, facilidad de mantenimiento y eficiencia en el procesamiento de datos, entre muchos otros factores.

[GN⁺]

Opiniones de Hacker News

• Después de varios años con muchas quejas de clientes, se dieron cuenta de que un bug en el driver JDBC estaba degradando el rendimiento. Se invirtió tiempo de muchos ingenieros en acelerar la velocidad de las consultas, pero el conector que usaba la mayoría de los usuarios añadía mucha más latencia de la que se había ahorrado. Peor aún, ni siquiera eran conscientes de ello. Como dentro de Google nadie usaba el driver JDBC, no podían ver los tiempos de consulta que experimentaban los usuarios y lo consideraban un problema de otros.

  • Este comentario expresa decepción porque Google estaba "completamente ciego" ante las quejas de los clientes y porque no usa sus propios productos. La parte sobre JDBC es especialmente impactante.
• Google construyó internamente una base de datos que funcionaba bien, pero mandó a hacer por fuera la capa adaptadora para el mundo externo, y como no funcionó bien, el mundo exterior terminó usando una base de datos defectuosa. El núcleo sofisticado que usa Google está rodeado de adaptadores incompletos, lo que da como resultado algo innecesariamente desordenado en conjunto. Internamente no se dan cuenta de esto, y para la gente de fuera es difícil identificarlo.
  • Este comentario considera que esto aplica muy bien a la estrategia de código abierto de Google.
• Me parece raro que el blog afirme que "el rendimiento es subjetivo". No basta con simplemente medir el rendimiento, pero en el único ejemplo dado el rendimiento sí importa y es objetivo. Lo único que pasó es que se midió lo incorrecto.
  • Este comentario cuestiona la afirmación del blog sobre la medición del rendimiento.
• Esto suena a un problema de organización dentro de la empresa. Si el objetivo final es lograr que los clientes usen la nube y entregarles valor, no deberían existir métricas distintas de lo que a los clientes realmente les importa. Dentro de Google debería haber personas que escuchen activamente los problemas de los clientes y se los transmitan a los ingenieros para indicarles qué deben mejorar.
  • Este comentario enfatiza la necesidad de una estructura organizacional que entienda los requisitos del cliente y los mejore.
• Desde mi casa en Seattle hasta la oficina de San Francisco, de puerta a puerta, toma unas 4.5 horas.
  • Este comentario señala en tono de broma que los fundadores ya no se mueven con rapidez, y sugiere que tal vez sea porque la Reserva Federal subió las tasas de interés.
• No creo que el rendimiento sea algo secundario como se plantea aquí. Primero hay que verificar que el rendimiento sea lo suficientemente bueno y después evaluar todo lo demás. El propio autor menciona que "DuckDB es rápido". Si no fuera así, tendría que entrar a competir en rendimiento.
  • Este comentario no está de acuerdo con la idea de que el rendimiento sea secundario, y sostiene que primero hay que confirmar que sea suficientemente bueno.
• El rendimiento no es "subjetivo", sino "relativo". Su significado depende del trabajo que se esté realizando.
  • Este comentario explica la relatividad del rendimiento y la distingue de la percepción de rendimiento relacionada con el diseño de interfaces de usuario.
• La primera web app popular almacenaba todo el estado en un dict de Python y lo volcaba al disco cada pocos minutos. Tenía una API muy rápida, pero cuando se migró a MongoDB el rendimiento nunca se recuperó. Aun así, hoy en día nadie elegiría pickledb para crear un sitio web.
  • Este comentario comparte una experiencia sobre el rendimiento de una web app temprana y la degradación tras cambiar de base de datos.
• Construí mi propio sistema de base de datos y quise compararlo en rendimiento con otras bases de datos populares (Postgres, Sqlite, MySQL, SQL Server).
  • Este comentario explica que no quedó satisfecho hasta que su base de datos fue más rápida en distintas consultas, midiendo incluso el tiempo desde que el usuario presionaba el botón de ejecutar hasta que el resultado aparecía en pantalla.
• "Por supuesto, esta regla tiene excepciones, y una de ellas es que las diferencias de arquitectura son difíciles de superar. Una base de datos shared nothing está en desventaja frente a una shared disk, y a Redshift le tomó muchos años pasarse principalmente a una arquitectura shared disk. Un lakehouse que persiste metadatos en object storage va a tener dificultades con actualizaciones rápidas; eso está incorporado en el modelo."
  • Este comentario señala problemas relacionados con las diferencias de arquitectura en bases de datos y menciona que está buscando buena bibliografía sobre el tema.