Por qué las bases de datos y su complejidad ya son innecesarias

Los problemas de las bases de datos y por qué su complejidad es innecesaria

• Las bases de datos son un estado global mutable, lo que hace que el código sea más complejo y difícil de entender.
• Los modelos de datos son limitados y no pueden cubrir todos los casos de uso, por lo que se requiere usar varias bases de datos.
• El dilema entre normalización y desnormalización crea una tensión entre consistencia de datos y rendimiento.
• Los esquemas limitados generan complejidad al tener que adaptar la representación del dominio a la base de datos.
• Los despliegues complejos aumentan el costo y la complejidad por la combinación e integración de distintas herramientas.

Un modelo coherente para construir backends de aplicaciones

• La función básica de un backend es recibir datos nuevos y responder preguntas sobre esos datos.
• Un diseño ideal de backend debe acercarse lo más posible al ideal mientras cumple con las restricciones del mundo real.

Rama

• Rama es una plataforma de desarrollo de backends que reimplementó Mastodon para ofrecer un servicio a escala de Twitter.
• Rama implementa de forma general todos los elementos de un backend, como datos, índices, ETL y consultas.
• Rama simplifica los despliegues complejos e integra el monitoreo, reduciendo de forma drástica los costos de desarrollo y mantenimiento.

La opinión de GN⁺

• El problema del estado global mutable en las bases de datos aumenta la complejidad del código y la posibilidad de errores, algo con lo que los desarrolladores se enfrentan con frecuencia.
• Rama presenta un nuevo enfoque para superar las limitaciones de las bases de datos tradicionales y reducir la complejidad del desarrollo de backends.
• Este artículo ofrece información interesante y útil para desarrolladores que buscan reducir la complejidad de las bases de datos y de los sistemas backend.

[GN⁺]

Opiniones en Hacker News

• Deberías usar un subsistema que represente la única fuente de verdad y otro subsistema que implemente varios almacenes de índices derivados de esa fuente. Esto es una combinación de event sourcing y materialized views.

  • Event sourcing y materialized views: La solución es gestionar por separado el sistema que representa la fuente de verdad y los almacenes de índices basados en ella.

• Separamos el modelo de lectura y el modelo de escritura: el modelo de escritura (la "fuente de verdad") consiste en un modelo de dominio relacional tradicional, y casi todos los comandos generan eventos que se publican en una cola compartida de eventos de dominio. El modelo de lectura está compuesto por workers que consumen eventos y construyen vistas.

  • Separación entre modelos de lectura y escritura: El modelo de escritura está compuesto por un modelo de dominio relacional, y los comandos generan eventos que se publican en una cola de eventos de dominio. El modelo de lectura consume esos eventos para construir vistas.

• Cuando los datos cambian, materializarlos puede ser beneficioso cuando el producto necesita hacer una sola tarea muy rápido. Pero aparecen problemas cuando se intenta agregar nuevas funciones que requieren transacciones complejas o datos organizados de otra manera.

  • Límites de la materialización de datos: Es útil cuando se optimiza para una sola tarea, pero puede causar problemas al agregar funciones que requieren transacciones complejas o nuevas estructuras de datos.

• Afirmar que esto fue demostrado con un "cliente de Mastodon a escala de Twitter" es imposible, a menos que realmente operes un sitio web con 40 millones de usuarios diarios.

  • La importancia de la escala: Es imposible simular de verdad un entorno con usuarios a gran escala, por lo que es difícil sostener esa afirmación.

• Un mejor enfoque es la combinación de event sourcing y materialized views.

  • Combinación de event sourcing y materialized views: Se presenta como un mejor enfoque, aunque implica más complejidad.

• Un solo modelo de datos no puede cubrir todos los casos de uso.

  • Diversidad de modelos de datos: Es imposible cubrir todos los casos de uso con un único modelo de datos.

• No tengo ninguna queja sobre las bases de datos.

  • Validez de las bases de datos: No hay quejas sobre las bases de datos; siguen siendo una herramienta válida.

• ¿Se omitieron conceptos como concurrencia, aislamiento y restricciones? ¿De verdad la "topología de consultas" es superior para la experiencia del desarrollador?

  • Dudas sobre la topología de consultas: Se cuestiona que falten conceptos importantes como concurrencia, aislamiento y restricciones, así como la afirmación de que la topología de consultas sea superior para la experiencia del desarrollador.

• Necesito un ELI5 sobre Rama. La documentación es confusa, y por favor no usen palabras de moda como "cambio de paradigma" o "plataforma".

  • Solicitud de una explicación simple sobre Rama: Se pide una explicación sencilla y clara de Rama, evitando palabras de moda.

• Event sourcing (+ materialized views e índices) no significa abandonar el RDBMS. Se pueden usar juntos.

  • Convivencia entre event sourcing y RDBMS: Event sourcing y materialized views pueden usarse junto con un RDBMS; no son mutuamente excluyentes.

Conocimientos de contexto:

• Event Sourcing: Patrón de diseño que registra los cambios de estado de un sistema como eventos, permitiendo reconstruir su estado al reproducirlos.
• Materialized Views: Técnica que almacena físicamente los resultados de consultas de una base de datos para mejorar el rendimiento de lectura.
• RDBMS (Relational Database Management System): Sistema para administrar bases de datos relacionales.