CQRS: Separar comandos y consultas para un mejor rendimiento
CQRS: Separar comandos y consultas para un mejor rendimiento
¿Qué es la segregación de responsabilidad de comandos y consultas (CQRS)?
La segregación de responsabilidad de comandos y consultas (CQRS) es un patrón de diseño que separa las acciones que cambian datos (comandos) de aquellas que recuperan datos (consultas). En lugar de usar el mismo modelo para ambos, CQRS los divide en dos rutas distintas. Al separar comandos y consultas, los sistemas pueden gestionar cada tarea de forma más eficiente, lo que conduce a un mejor rendimiento, un código más claro y un escalado más sencillo a medida que tu aplicación crece.
Conceptos clave de CQRS
Comando
Un comando es una acción que cambia datos en el sistema, como una operación de escritura en la base de datos. Representa una solicitud para realizar una tarea específica, como crear, actualizar o eliminar algo. Los comandos no devuelven datos; le dicen al sistema que "haga algo."
Ejemplo: Cuando los usuarios actualizan la información de su perfil, se envía un comando como “UpdateUserProfile” para cambiar su nombre, correo electrónico u otros detalles del sistema.
Consulta
Una consulta es una solicitud para recuperar datos sin cambiarlos, es decir, la operación de lectura en la base de datos. Las consultas se usan para obtener información, como buscar o mostrar datos. A diferencia de los comandos, las consultas solo devuelven datos y no alteran nada.
Ejemplo: Cuando un usuario quiere ver los detalles de su perfil, una consulta como “GetUserProfile” obtiene la información relevante del sistema.
¿Cómo funciona CQRS?
Una analogía del mundo real para entender el funcionamiento de CQRS es pensar en ello como tener carriles separados para coches y camiones en una autopista. Los camiones transportan cargas pesadas (comandos), mientras que los coches se mueven rápida y fluidamente (consultas). Al mantenerlos en sus propios carriles, el tráfico fluye mejor y ambas tareas se realizan de manera más eficiente.
CQRS funciona separando claramente la gestión de comandos (modificaciones de datos) y consultas (recuperación de datos). Cuando se emite un comando, como insertar o actualizar datos, fluye a través de una ruta dedicada diseñada para procesar cambios. El sistema procesa estos comandos con precisión, a menudo activando lógica de negocio o eventos relacionados. Las consultas, por otro lado, se canalizan a través de una ruta diferente optimizada para lecturas de datos rápidas y eficientes.
Es importante señalar que en CQRS, separar comandos y consultas no significa necesariamente que necesites usar bases de datos diferentes para cada uno. El enfoque está en separar los comportamientos y las responsabilidades, lo cual puede hacerse dentro de la misma base de datos o en múltiples bases de datos si es necesario.
Figure- CQRS High-Level Architecture.png
Figura: Arquitectura de alto nivel de CQRS
Ejemplo: Un sistema de registro de usuarios
Cuando un usuario se registra, se activa un comando llamado RegisterUserCommand. Este comando crea el nuevo usuario, valida sus datos y lo añade a la base de datos. Entre bastidores, se almacena un evento como `UserRegisteredEvent` que registra este cambio.
Más tarde, cuando otra parte del sistema (o el usuario) necesita ver los detalles del usuario, se usa una consulta llamada GetUserProfileQuery. La consulta recupera los datos del perfil del usuario de la base de datos sin realizar ninguna modificación.
CQRS y Event Sourcing
Event Sourcing es una técnica que se usa a menudo con CQRS. En los sistemas tradicionales, cuando los datos cambian (como cuando un usuario actualiza su perfil), solo guardamos el estado final de los datos. Por ejemplo, si un usuario cambia su dirección de correo electrónico, solo almacenamos el nuevo correo electrónico en la base de datos, y el antiguo se pierde.
Con Event Sourcing, en lugar de guardar solo el estado final, almacenamos cada cambio como un evento separado. Así, en el caso de una actualización del perfil de usuario, almacenamos eventos como "Usuario creado," "Correo electrónico actualizado," o "Foto de perfil cambiada." Cada evento registra qué ocurrió y cuándo. Estos eventos se guardan en una secuencia, casi como un registro histórico de todo lo que ocurre en el sistema.
Estos eventos se convierten en la fuente de verdad del sistema. Cuando se ejecuta un comando (por ejemplo, actualizar el perfil del usuario), se crea un nuevo evento y se agrega a esta lista de eventos. Con el tiempo, todos estos eventos se acumulan para representar todo el historial de cambios.
Cuando necesitas consultar o ver el estado actual del sistema (como obtener el perfil del usuario), el sistema puede reproducir estos eventos en el orden correcto para reconstruir el estado actual. Por ejemplo, podría reproducir los eventos "Usuario creado" y "Correo electrónico actualizado" para mostrar el correo electrónico actual y los detalles del perfil.
Diferencia entre CQRS y CQS
Aunque CQRS (Segregación de Responsabilidad de Comandos y Consultas) y CQS (Separación de Comandos y Consultas) son principios de diseño que enfatizan la distinción entre comandos y consultas, son ligeramente diferentes en algunos aspectos.
| Aspecto | CQS (Separación de Comandos y Consultas) | CQRS (Segregación de Responsabilidad de Comandos y Consultas) |
|---|---|---|
| Definición | Los métodos son comandos (modifican datos) o consultas (recuperan datos). | El sistema separa comandos y consultas en modelos o rutas distintos. |
| Complejidad | Principio simple aplicado dentro de los métodos. | Más complejo, e implica modelos o capas separadas para comandos y consultas. |
| Caso de uso | Adecuado para sistemas más simples donde los comandos y las consultas se manejan dentro de la misma estructura. | Ideal para sistemas grandes y complejos donde las lecturas y escrituras pueden optimizarse por separado. |
| Manejo de datos | Se utiliza el mismo modelo de datos tanto para comandos como para consultas. | Los comandos y las consultas pueden usar diferentes modelos de datos o incluso bases de datos. |
| Enfoque | Enfocado principalmente en el hecho de que los métodos tienen una única responsabilidad. | Se centra en la escalabilidad, el rendimiento y la separación de responsabilidades en todo el sistema. |
| Escalabilidad | Menor impacto en la escalabilidad del sistema, ya que ambos se manejan en un solo modelo. | Alta escalabilidad, ya que los comandos y las consultas se manejan de forma independiente. |
| Flexibilidad | Flexibilidad limitada, ya que ambas operaciones están vinculadas en una sola estructura. | Mayor flexibilidad; puedes usar diferentes bases de datos o mecanismos de almacenamiento para comandos y consultas. |
| Event Sourcing | No se utiliza normalmente. | A menudo se usa con event sourcing para rastrear todos los cambios a lo largo del tiempo. |
Tabla: Diferencia entre CQS y CQRS
Casos de uso de CQRS
Estos son algunos escenarios comunes en los que CQRS es útil:
Altas cargas de lectura/escritura
En escenarios donde hay un desequilibrio significativo entre el número de operaciones de lectura y escritura, CQRS es ideal. Por ejemplo, una plataforma de comercio electrónico puede tener una gran cantidad de usuarios consultando información de productos (lecturas), pero menos usuarios actualizando sus carritos o realizando compras (escrituras). CQRS permite que el sistema escale el lado de consultas de forma independiente para manejar el alto volumen de solicitudes de lectura sin afectar las operaciones de escritura.
Lógica de negocio compleja
Al gestionar reglas de negocio complejas que se aplican solo a las modificaciones de datos (comandos), CQRS ayuda al aislar esta complejidad. Por ejemplo, el lado de comandos puede aplicar reglas estrictas de validación y procesamiento en un sistema financiero donde las transacciones están fuertemente reguladas. En cambio, el lado de consultas sigue siendo simple y se centra en recuperar saldos de cuentas o historiales de transacciones.
Event Sourcing y registros de auditoría
En sistemas donde es necesario mantener un registro de auditoría completo de cada cambio, CQRS combina bien con event sourcing. Por ejemplo, en una aplicación de atención médica, cada cambio en el historial médico de un paciente puede almacenarse como un evento, lo que permite al sistema rastrear fácilmente quién realizó cambios y cuándo, mientras que las consultas pueden acceder rápidamente al estado actual del registro.
Analítica en tiempo real
Para aplicaciones que requieren analítica en tiempo real, como las plataformas de redes sociales, CQRS puede gestionar actualizaciones constantes de los datos de usuario (por ejemplo, me gusta, compartidos) mientras procesa consultas para obtener información en tiempo real (por ejemplo, temas en tendencia). El lado de consultas puede optimizarse para la velocidad sin verse afectado por las actualizaciones continuas en el lado de comandos.
Arquitecturas de microservicios
En sistemas basados en microservicios, CQRS proporciona diferentes servicios para gestionar comandos y consultas de forma independiente. Por ejemplo, en una empresa de logística, un servicio puede gestionar el procesamiento de pedidos (comandos), mientras que otro se encarga del seguimiento y la generación de informes (consultas), lo que mejora la flexibilidad y la mantenibilidad del sistema.
Herramientas y frameworks que admiten CQRS
Varias herramientas y frameworks facilitan la implementación de CQRS. Aquí tienes una breve descripción general de algunas opciones populares:
Axon Framework (Java) es un framework completo que admite CQRS y event sourcing. Proporciona componentes integrados para gestionar comandos, consultas y eventos, lo que lo convierte en una opción popular para aplicaciones Java complejas.
MediatR es otra biblioteca ligera para aplicaciones .NET que simplifica la separación de comandos y consultas. Ayuda a enrutar solicitudes de una forma limpia y organizada, lo cual es perfecto para CQRS en sistemas pequeños y medianos.
Laravel Command Bus forma parte del framework Laravel. Los desarrolladores usan esta herramienta para definir comandos y consultas por separado. Es una gran opción para aplicaciones basadas en PHP que buscan implementar CQRS.
EventStore es una base de datos especializada diseñada para event sourcing, que a menudo se combina con CQRS. Almacena eventos en lugar de solo datos, lo que permite reproducir fácilmente eventos pasados para reconstruir el estado del sistema.
NServiceBus es un framework de mensajería que funciona bien con CQRS al gestionar comandos, eventos y mensajes en sistemas distribuidos. Es ideal para arquitecturas de microservicios que usan CQRS.
Ventajas de CQRS
Escalabilidad y rendimiento mejorados
Al separar comandos y consultas, CQRS puede escalar cada parte de forma independiente. Por ejemplo, si tu aplicación gestiona muchas más operaciones de lectura (consultas) que operaciones de escritura (comandos), puedes escalar el lado de consultas sin afectar al lado de comandos, mejorando el rendimiento general.
Organización del código más clara
CQRS promueve una separación clara de responsabilidades. Los comandos se ocupan de realizar cambios, y las consultas gestionan la recuperación de datos. Esto hace que el código sea más fácil de entender y mantener, ya que cada parte del sistema tiene una responsabilidad clara.
Mejor gestión de reglas de negocio complejas
Con CQRS, las reglas de negocio complejas relacionadas con la actualización de datos pueden gestionarse en el lado de comandos, mientras que se pueden usar consultas más simples y eficientes para leer datos. Esta división ayuda a gestionar lógica intrincada sin sobrecargar el sistema ni hacer que el código sea demasiado complicado.
Flexibilidad en la elección de bases de datos para lectura frente a escritura de datos
CQRS te da una opción abierta para usar diferentes bases de datos para comandos y consultas. Por ejemplo, podrías usar una base de datos NoSQL altamente optimizada para lecturas rápidas (consultas) y una base de datos relacional durante las escrituras (comandos). Esta flexibilidad te permite elegir las mejores herramientas para cada tarea.
Desafíos y consideraciones de CQRS
Mayor complejidad
Con CQRS, debes gestionar dos modelos separados: uno para manejar comandos (escrituras) y otro para manejar consultas (lecturas). Esto añade complejidad a la base de código, ya que debes mantener y actualizar ambos modelos, aumentando el esfuerzo necesario para desarrollar y mantener el sistema.
Desafíos de sincronización
Mantener sincronizados los lados de comandos y consultas puede ser complicado. Cuando los datos se escriben mediante un comando, puede pasar tiempo hasta que los cambios se reflejen en el lado de consultas, lo que genera posibles retrasos. Gestionar esta sincronización es importante para garantizar datos precisos en todo el sistema.
Decidir cuándo CQRS es excesivo
CQRS no es necesario para aplicaciones CRUD (Crear, Leer, Actualizar, Eliminar) simples. En sistemas con requisitos de datos sencillos, la complejidad añadida de CQRS puede no valer la pena. CQRS es más adecuado para sistemas complejos con un alto volumen de lecturas y escrituras o lógica de negocio intrincada.
Coste
Implementar CQRS a menudo requiere infraestructura adicional, como mantener bases de datos separadas para comandos y consultas. Esto puede aumentar los costes de hardware y servicios en la nube, especialmente al escalar ambos lados. La necesidad de múltiples tecnologías para manejar estas tareas puede incrementar los gastos.
Cómo CQRS desempeña un papel en las bases de datos vectoriales y Big Data
En bases de datos vectoriales como Milvus, CQRS ofrece una forma estructurada de manejar diferentes tipos de operaciones:
Comandos: Estos implican tareas como insertar o actualizar grandes volúmenes de vectores (por ejemplo, incrustaciones vectoriales generadas por modelos de aprendizaje automático). En Milvus, los comandos actualizarían el estado de la base de datos.
Consultas: Estas operaciones recuperan vectores, como encontrar elementos similares en un gran conjunto de datos mediante búsqueda por similitud. Las consultas de Milvus pueden devolver vectores de alta dimensión que coinciden con criterios específicos, y a menudo se utilizan en analítica en tiempo real o aplicaciones de IA como sistemas de recomendación y generación aumentada por recuperación (RAG).
Ejemplo: Manejo de consultas de analítica en tiempo real frente a la inserción/actualización de vectores
Supongamos que estás ejecutando un sistema de recomendación impulsado por IA en Zilliz Cloud (la versión gestionada de Milvus). Cuando se generan nuevos datos de usuario o vectores de producto, el sistema emite comandos para actualizar la base de datos vectorial con incrustaciones nuevas. Estos comandos garantizan que los vectores más recientes se inserten o actualicen en Milvus.
Al mismo tiempo, la analítica en tiempo real se realiza mediante consultas para recuperar los vectores más similares para las recomendaciones. El lado de consultas está optimizado para encontrar rápidamente datos relevantes sin verse afectado por las inserciones constantes de vectores en el lado de comandos.
Conclusión
CQRS proporciona una forma potente de gestionar sistemas complejos separando comandos (cambios de datos) y consultas (recuperación de datos). Esta separación mejora la escalabilidad, el rendimiento y la claridad del código, especialmente en aplicaciones a gran escala con lógica de negocio compleja. Aunque CQRS añade cierta complejidad, ofrece beneficios significativos cuando se utiliza en los escenarios adecuados, como sistemas que manejan analítica en tiempo real, cargas de trabajo elevadas de lectura/escritura o event sourcing. Sin embargo, para aplicaciones más simples, la complejidad adicional puede no ser necesaria. En conclusión, CQRS es una herramienta valiosa para mejorar la eficiencia y flexibilidad del sistema cuando se aplica adecuadamente.
Preguntas frecuentes de CQRS
- ¿Cuál es el principal beneficio de usar CQRS?
CQRS separa las responsabilidades de actualizar datos (comandos) y recuperar datos (consultas), lo que mejora la escalabilidad, el rendimiento y la claridad del código del sistema. Cada lado puede optimizarse de forma independiente, lo que lo hace útil para sistemas de alto volumen o complejos.
- ¿Cuándo debería evitar usar CQRS?
CQRS puede añadir complejidad innecesaria para aplicaciones CRUD simples donde no hay necesidad de un manejo distinto de lecturas y escrituras. Si tu aplicación no tiene requisitos de rendimiento significativos ni lógica de negocio compleja, CQRS puede ser excesivo.
- ¿Necesito usar bases de datos separadas para comandos y consultas en CQRS?
No, no es obligatorio usar bases de datos separadas para comandos y consultas. Aunque puedes usar diferentes bases de datos para CQRS, la clave es separar el comportamiento y la responsabilidad en el código. Aún puedes usar una sola base de datos si se adapta a las necesidades de tu aplicación.
- ¿Cómo funciona CQRS con event sourcing?
En event sourcing, cada cambio en el sistema se almacena como un evento. CQRS complementa esto manejando comandos que generan eventos y usando consultas para reconstruir el estado del sistema reproduciendo esos eventos. Así, se mantiene un historial completo de cambios, lo que facilita la auditoría o la depuración.
- ¿Puede CQRS mejorar el rendimiento de las aplicaciones de análisis en tiempo real?
Sí, CQRS es útil para el análisis en tiempo real. Permite que el sistema maneje actualizaciones continuas (comandos) por separado de las consultas de datos en tiempo real, optimizando cada una para su propósito y evitando que una ralentice a la otra.
- ¿Cuáles son los desafíos de implementar CQRS?
Los principales desafíos incluyen una mayor complejidad, gestionar la sincronización entre los modelos de comandos y consultas, manejar problemas de consistencia eventual y costos de infraestructura potencialmente más altos debido al mantenimiento de rutas o bases de datos separadas.
Recursos relacionados
- ¿Qué es la segregación de responsabilidad de comandos y consultas (CQRS)?
- Conceptos clave de CQRS
- ¿Cómo funciona CQRS?
- CQRS y Event Sourcing
- Diferencia entre CQRS y CQS
- Casos de uso de CQRS
- Herramientas y frameworks que admiten CQRS
- Ventajas de CQRS
- Desafíos y consideraciones de CQRS
- Cómo CQRS desempeña un papel en las bases de datos vectoriales y Big Data
- Conclusión
- Preguntas frecuentes de CQRS
- Recursos relacionados
Contenido
Comienza Gratis, Escala Fácilmente
Prueba la base de datos vectorial completamente gestionada construida para tus aplicaciones GenAI.
Prueba Zilliz Cloud Gratis