CQRS: Separe comandos e consultas para melhor desempenho
CQRS: Separe comandos e consultas para melhor desempenho
O que é Command Query Responsibility Segregation (CQRS)?
Command Query Responsibility Segregation (CQRS) é um padrão de design que separa as ações que alteram dados (comandos) daquelas que recuperam dados (consultas). Em vez de usar o mesmo modelo para ambos, o CQRS os divide em dois caminhos distintos. Ao separar comandos e consultas, os sistemas podem lidar com cada tarefa de forma mais eficiente, levando a melhor desempenho, código mais claro e escalabilidade mais fácil à medida que sua aplicação cresce.
Conceitos-chave do CQRS
Comando
Um comando é uma ação que altera dados no sistema, como uma operação de escrita no banco de dados. Ele representa uma solicitação para realizar uma tarefa específica, como criar, atualizar ou excluir algo. Comandos não retornam dados; eles dizem ao sistema para "fazer algo."
Exemplo: Quando os usuários atualizam suas informações de perfil, um comando como “UpdateUserProfile” é enviado para alterar seu nome, e-mail ou outros detalhes do sistema.
Consulta
Uma consulta é uma solicitação para recuperar dados sem alterá-los, ou seja, a operação de leitura no banco de dados. Consultas são usadas para obter informações, como pesquisar ou exibir dados. Ao contrário dos comandos, consultas apenas retornam dados e não alteram nada.
Exemplo: Quando um usuário deseja visualizar os detalhes do seu perfil, uma consulta como “GetUserProfile” busca as informações relevantes no sistema.
Como o CQRS funciona?
Uma analogia do mundo real para entender o funcionamento do CQRS é pensar nele como tendo faixas separadas para carros e caminhões em uma rodovia. Caminhões lidam com cargas pesadas (comandos), enquanto carros se movem rápida e suavemente (consultas). Ao mantê-los em suas próprias faixas, o tráfego flui melhor, e ambas as tarefas são realizadas com mais eficiência.
O CQRS opera separando claramente o tratamento de comandos (modificações de dados) e consultas (recuperação de dados). Quando um comando é emitido, como inserir ou atualizar dados, ele flui por um caminho dedicado projetado para processar alterações. O sistema processa esses comandos com precisão, muitas vezes acionando lógica de negócio ou eventos relacionados. As consultas, por outro lado, são encaminhadas por um caminho diferente, otimizado para leituras de dados rápidas e eficientes.
É importante observar que, no CQRS, separar comandos e consultas não significa necessariamente que você precise usar bancos de dados diferentes para cada um. O foco está em separar os comportamentos e responsabilidades, o que pode ser feito dentro do mesmo banco de dados ou em vários bancos de dados, se necessário.
Figura- Arquitetura de Alto Nível do CQRS.png
Figura: Arquitetura de Alto Nível do CQRS
Exemplo: Um sistema de registro de usuários
Quando um usuário se registra, um comando chamado RegisterUserCommand é acionado. Esse comando cria o novo usuário, valida seus detalhes e os adiciona ao banco de dados. Nos bastidores, um evento como `UserRegisteredEvent` é armazenado, registrando essa alteração.
Mais tarde, quando outra parte do sistema (ou o usuário) precisa visualizar os detalhes do usuário, uma consulta chamada GetUserProfileQuery é usada. A consulta recupera os dados do perfil do usuário do banco de dados sem fazer nenhuma modificação.
CQRS e Event Sourcing
Event Sourcing é uma técnica frequentemente usada com CQRS. Em sistemas tradicionais, quando os dados mudam (como um usuário atualizando seu perfil), salvamos apenas o estado final dos dados. Por exemplo, se um usuário altera seu endereço de e-mail, armazenamos apenas o novo e-mail no banco de dados, e o e-mail antigo é perdido.
Com Event Sourcing, em vez de salvar apenas o estado final, armazenamos cada alteração como um evento separado. Então, no caso de uma atualização de perfil de usuário, armazenamos eventos como "Usuário criado," "E-mail atualizado," ou "Foto de perfil alterada." Cada evento registra o que aconteceu e quando. Esses eventos são salvos em uma sequência, quase como um registro histórico de tudo no sistema.
Esses eventos tornam-se a fonte da verdade do sistema. Quando um comando é executado (por exemplo, atualizando o perfil do usuário), um novo evento é criado e adicionado a esta lista de eventos. Com o tempo, todos esses eventos se acumulam para representar todo o histórico de alterações.
Quando você precisa consultar ou visualizar o estado atual do sistema (como buscar o perfil do usuário), o sistema pode reproduzir esses eventos na ordem correta para reconstruir o estado atual. Por exemplo, ele pode reproduzir os eventos "User created" e "Email updated" para mostrar o e-mail atual e os detalhes do perfil.
Diferença entre CQRS e CQS
Embora CQRS (Command Query Responsibility Segregation) e CQS (Command Query Separation) sejam ambos princípios de design que enfatizam a distinção entre comandos e consultas, eles são ligeiramente diferentes em alguns aspectos.
| Aspecto | CQS (Command Query Separation) | CQRS (Command Query Responsibility Segregation) |
|---|---|---|
| Definição | Métodos são comandos (modificam dados) ou consultas (recuperam dados). | O sistema separa comandos e consultas em modelos ou caminhos distintos. |
| Complexidade | Princípio simples aplicado dentro de métodos. | Mais complexo, e envolve modelos ou camadas separadas para comandos e consultas. |
| Caso de uso | Adequado para sistemas mais simples onde comandos e consultas são tratados dentro da mesma estrutura. | Ideal para sistemas grandes e complexos onde leituras e escritas podem ser otimizadas separadamente. |
| Tratamento de dados | O mesmo modelo de dados é usado tanto para comandos quanto para consultas. | Comandos e consultas podem usar modelos de dados diferentes ou até bancos de dados. |
| Foco | Principalmente focado no fato de que métodos têm uma única responsabilidade. | Foca em escalabilidade, desempenho e separação de responsabilidades em todo o sistema. |
| Escalabilidade | Menor impacto na escalabilidade do sistema, pois ambos são tratados em um único modelo. | Alta escalabilidade, pois comandos e consultas são tratados independentemente. |
| Flexibilidade | Flexibilidade limitada, pois ambas as operações estão vinculadas em uma única estrutura. | Maior flexibilidade; você pode usar diferentes bancos de dados ou mecanismos de armazenamento para comandos e consultas. |
| Event Sourcing | Não é normalmente usado. | Frequentemente usado com event sourcing para rastrear todas as alterações ao longo do tempo. |
Tabela: Diferença entre CQS e CQRS
Casos de uso para CQRS
Aqui estão alguns cenários comuns em que CQRS é útil:
Altas cargas de leitura/escrita
Em cenários onde há um desequilíbrio significativo entre o número de operações de leitura e escrita, CQRS é ideal. Por exemplo, uma plataforma de e-commerce pode ter um grande número de usuários consultando informações de produtos (leituras), mas menos usuários atualizando seus carrinhos ou fazendo compras (escritas). CQRS permite que o sistema escale o lado de consulta independentemente para lidar com o alto volume de solicitações de leitura sem afetar as operações de escrita.
Lógica de negócios complexa
Ao lidar com regras de negócios complexas que se aplicam apenas a modificações de dados (comandos), o CQRS ajuda ao isolar essa complexidade. Por exemplo, o lado de comandos pode impor regras rigorosas de validação e processamento em um sistema financeiro onde as transações são altamente regulamentadas. Em contraste, o lado de consultas permanece simples e focado em recuperar saldos de contas ou históricos de transações.
Event Sourcing e Trilhas de Auditoria
Em sistemas onde é necessário manter uma trilha de auditoria completa de cada alteração, o CQRS combina bem com event sourcing. Por exemplo, em uma aplicação de saúde, cada alteração no prontuário médico de um paciente pode ser armazenada como um evento, permitindo que o sistema rastreie facilmente quem fez as alterações e quando, enquanto as consultas podem acessar rapidamente o estado atual do prontuário.
Análises em Tempo Real
Para aplicações que exigem análises em tempo real, como plataformas de redes sociais, o CQRS pode lidar com atualizações constantes nos dados dos usuários (por exemplo, curtidas, compartilhamentos) enquanto processa consultas para insights em tempo real (por exemplo, tópicos em alta). O lado de consultas pode ser otimizado para velocidade sem ser afetado pelas atualizações contínuas no lado de comandos.
Arquiteturas de Microsserviços
Em sistemas baseados em microsserviços, o CQRS fornece serviços diferentes para lidar com comandos e consultas de forma independente. Por exemplo, em uma empresa de logística, um serviço pode gerenciar o processamento de pedidos (comandos), enquanto outro lida com rastreamento e relatórios (consultas), melhorando a flexibilidade e a manutenibilidade do sistema.
Ferramentas e Frameworks que Suportam CQRS
Várias ferramentas e frameworks facilitam a implementação do CQRS. Aqui está uma breve visão geral de algumas opções populares:
Axon Framework (Java) é um framework completo que suporta CQRS e event sourcing. Ele fornece componentes integrados para lidar com comandos, consultas e eventos, o que o torna uma escolha popular para aplicações Java complexas.
MediatR é outra biblioteca leve para aplicações .NET que simplifica a separação de comandos e consultas. Ela ajuda a encaminhar solicitações de forma limpa e organizada, o que é perfeito para CQRS em sistemas de pequeno a médio porte.
Laravel Command Bus faz parte do framework Laravel. Desenvolvedores usam esta ferramenta para definir comandos e consultas separadamente. É uma ótima opção para aplicações baseadas em PHP que buscam implementar CQRS.
EventStore é um banco de dados especializado projetado para event sourcing, frequentemente usado em conjunto com CQRS. Ele armazena eventos em vez de apenas dados, permitindo a fácil reprodução de eventos passados para reconstruir o estado do sistema.
NServiceBus é um framework de mensagens que funciona bem com CQRS ao lidar com comandos, eventos e mensagens em sistemas distribuídos. É ideal para arquiteturas de microsserviços que usam CQRS.
Vantagens do CQRS
Escalabilidade e desempenho aprimorados
Ao separar comandos e consultas, o CQRS pode escalar cada parte de forma independente. Por exemplo, se sua aplicação lida com muito mais operações de leitura (consultas) do que operações de escrita (comandos), você pode escalar o lado de consultas sem afetar o lado de comandos, melhorando o desempenho geral.
Organização de código mais clara
O CQRS promove uma separação limpa de responsabilidades. Comandos lidam com a realização de alterações, e consultas lidam com a recuperação de dados. Isso torna o código mais fácil de entender e manter, pois cada parte do sistema tem uma responsabilidade clara.
Melhor tratamento de regras de negócios complexas
Com CQRS, regras de negócios complexas relacionadas à atualização de dados podem ser tratadas no lado de comandos, enquanto consultas mais simples e eficientes podem ser usadas para ler dados. Essa divisão ajuda a gerenciar lógica intrincada sem sobrecarregar o sistema ou tornar o código complicado demais.
Flexibilidade nas escolhas de banco de dados para leitura vs. escrita de dados
CQRS oferece uma escolha aberta para usar diferentes bancos de dados para comandos e consultas. Por exemplo, você poderia usar um banco de dados NoSQL altamente otimizado para leituras rápidas (consultas) e um banco de dados relacional durante escritas (comandos). Essa flexibilidade permite que você escolha as melhores ferramentas para cada tarefa.
Desafios e Considerações do CQRS
Maior complexidade
Com CQRS, você deve gerenciar dois modelos separados: um para lidar com comandos (escritas) e outro para lidar com consultas (leituras). Isso adiciona complexidade à base de código, pois você deve manter e atualizar ambos os modelos, aumentando o esforço necessário para desenvolver e manter o sistema.
Desafios de sincronização
Manter os lados de comando e consulta sincronizados pode ser complicado. Quando dados são gravados por meio de um comando, pode levar tempo para que as alterações sejam refletidas no lado da consulta, levando a possíveis atrasos. Gerenciar essa sincronização é importante para garantir dados precisos em todo o sistema.
Decidir quando CQRS é exagero
CQRS não é necessário para aplicações CRUD (Create, Read, Update, Delete) simples. Em sistemas com requisitos de dados diretos, a complexidade adicional do CQRS pode não valer a pena. CQRS é mais adequado para sistemas complexos com um alto volume de leituras e escritas ou lógica de negócios intrincada.
Custo
Implementar CQRS frequentemente requer infraestrutura adicional, como manter bancos de dados separados para comandos e consultas. Isso pode aumentar os custos de hardware e de serviços em nuvem, especialmente ao escalar ambos os lados. A necessidade de múltiplas tecnologias para lidar com essas tarefas pode elevar as despesas.
Como o CQRS desempenha um papel em bancos de dados vetoriais e Big Data
Em bancos de dados vetoriais como Milvus, CQRS oferece uma maneira estruturada de lidar com diferentes tipos de operações:
Comandos: Estes envolvem tarefas como inserir ou atualizar grandes volumes de vetores (por exemplo, embeddings vetoriais gerados por modelos de machine learning). No Milvus, comandos atualizariam o estado do banco de dados.
Consultas: Estas operações recuperam vetores, como encontrar itens semelhantes em um grande conjunto de dados usando busca por similaridade. As consultas do Milvus podem retornar vetores de alta dimensionalidade que correspondem a critérios específicos, e elas são frequentemente usadas em análises em tempo real ou aplicações de IA, como sistemas de recomendação e geração aumentada por recuperação (RAG).
Exemplo: Lidando com consultas de análise em tempo real vs. inserção/atualização de vetores
Digamos que você esteja executando um sistema de recomendação baseado em IA no Zilliz Cloud (a versão gerenciada do Milvus). Quando novos dados de usuários ou vetores de produtos são gerados, o sistema emite comandos para atualizar o banco de dados vetorial com embeddings recentes. Esses comandos garantem que os vetores mais recentes sejam inseridos ou atualizados no Milvus.
Ao mesmo tempo, análises em tempo real são realizadas usando consultas para recuperar os vetores mais semelhantes para recomendações. O lado da consulta é otimizado para encontrar rapidamente dados relevantes sem ser impactado pelas constantes inserções de vetores no lado do comando.
Conclusão
CQRS fornece uma maneira poderosa de gerenciar sistemas complexos separando comandos (alterações de dados) e consultas (recuperação de dados). Essa separação melhora a escalabilidade, o desempenho e a clareza do código, especialmente em aplicações de grande escala com lógica de negócios complexa. Embora CQRS adicione alguma complexidade, oferece benefícios significativos quando usado nos cenários certos, como sistemas que lidam com análises em tempo real, altas cargas de trabalho de leitura/escrita ou event sourcing. No entanto, para aplicações mais simples, a complexidade adicional pode não ser necessária. Em conclusão, CQRS é uma ferramenta valiosa para aumentar a eficiência e a flexibilidade do sistema quando aplicado adequadamente.
FAQ’s de CQRS
- Qual é o principal benefício de usar CQRS?
O CQRS separa as responsabilidades de atualizar dados (commands) e recuperar dados (queries), o que melhora a escalabilidade, o desempenho e a clareza do código do sistema. Cada lado pode ser otimizado de forma independente, o que o torna útil para sistemas de alto volume ou complexos.
- Quando devo evitar usar CQRS?
O CQRS pode adicionar complexidade desnecessária para aplicações CRUD simples, nas quais não há necessidade de tratamento distinto para leituras e escritas. Se sua aplicação não tiver requisitos significativos de desempenho ou lógica de negócios complexa, o CQRS pode ser exagerado.
- Preciso usar bancos de dados separados para commands e queries no CQRS?
Não, usar bancos de dados separados para commands e queries não é obrigatório. Embora você possa usar bancos de dados diferentes para CQRS, o essencial é separar o comportamento e a responsabilidade no código. Você ainda pode usar um único banco de dados se isso atender às necessidades da sua aplicação.
- Como o CQRS funciona com event sourcing?
No event sourcing, toda mudança no sistema é armazenada como um evento. O CQRS complementa isso ao lidar com commands que geram eventos e usar queries para reconstruir o estado do sistema reproduzindo esses eventos. Assim, um histórico completo de mudanças é mantido, facilitando auditorias ou depuração.
- O CQRS pode melhorar o desempenho de aplicações de análise em tempo real?
Sim, o CQRS é útil para análise em tempo real. Ele permite que o sistema lide com atualizações contínuas (commands) separadamente das consultas de dados em tempo real, otimizando cada uma para seu propósito e evitando que uma desacelere a outra.
- Quais são os desafios de implementar CQRS?
Os principais desafios incluem maior complexidade, gerenciamento da sincronização entre os modelos de command e query, tratamento de problemas de consistência eventual e custos de infraestrutura potencialmente mais altos devido à manutenção de caminhos ou bancos de dados separados.
Recursos Relacionados
- O que é Command Query Responsibility Segregation (CQRS)?
- Conceitos-chave do CQRS
- Como o CQRS funciona?
- CQRS e Event Sourcing
- Diferença entre CQRS e CQS
- Casos de uso para CQRS
- Ferramentas e Frameworks que Suportam CQRS
- Vantagens do CQRS
- Desafios e Considerações do CQRS
- Como o CQRS desempenha um papel em bancos de dados vetoriais e Big Data
- Conclusão
- FAQ’s de CQRS
- Recursos Relacionados
Conteúdo
Comece grátis, escale facilmente
Experimente o banco de dados totalmente gerenciado, construído para seus aplicativos GenAI.
Experimente o Zilliz Cloud grátis