Separação de leitura e escrita
Quando o negócio de uma empresa continua a se expandir e o número de usuários aumenta significativamente, o banco de dados original provavelmente não conseguirá se sustentar. Então sim
- O sistema de escalonamento, que expande o desempenho do hardware, mas é provável que o número de usuários continue crescendo, e o aumento de desempenho logo será consumido.
- Separação de leitura e escrita: O banco de dados não consegue se sustentar, não passa de leitura e escrita em excesso, especialmente se houver consultas complexas, como os produtos mais populares das últimas 24 horas. Exige instruções SQL muito complexas e, claro, é lento para rodar.
No entanto, para separar leituras e escritas, o banco de dados precisa ser dividido em bibliotecas master e slave.
Os principais bancos de dados relacionais no mercado suportam replicação de dados, então você pode dividir um banco de dados em dois papéis: Master e Slave, escrever operações no master e sincronizar o servidor master com outros servidores slave.
Operações offline, como leitura e análise de dados, são realizadas no servidor Slave.
Sabemos que muitas aplicações na Internet são lidas, para que múltiplos escravos possam compartilhar a carga e garantir a disponibilidade e correção dos dados.
No entanto, o código original correspondente também precisa ser modificado, e deve ser alterado para usar a biblioteca mestre para escrever dados, e usar a biblioteca escrava ao ler dados, o que equivale a reescrever.
Consultas complexas
No entanto, mesmo depois de reescrever o código, percebi que o desempenho ainda não melhorou significativamente porque muitas consultas complexas foram usadas, e já dissemos no componente do banco de dados que joins são muito intensivos em desempenho.
Então, podemos usar uma tabela separada para armazenar os produtos populares das últimas 24 horas, para que só precisemos usar SQL simples para isso.
Em outras palavras, um único conjunto de tabelas de banco de dados é inadequado para comportamentos diferentes, como relatórios, buscas, transações, etc.
A tabela atual foi projetada para adicionar e modificar dados, e não é adequada para consultas complexas.
Mas também precisamos considerar como essa base de consultas é atualizada, ou se podemos tolerar esse atraso, se pode não ser atualizada em tempo real.
CQRS
Se o atraso pode ser tolerado precisa ser visto sob a perspectiva dos negócios, como os melhores produtos populares das últimas 24 horas; um pouco de informação desatualizada não tem muito impacto, apenas a consistência final é necessária.
Podemos usar CQRS (Command Query Responsibility Segregation), ou seja, a separação de comandos para adicionar ou modificar comandos das responsabilidades de consulta.
No CQRS, a ênfase está na separação entre leitura (Consulta) e escrita (Comando), porque os dados lidos pelos usuários geralmente estão desatualizados, então por que precisar ler do banco de dados, você pode estabelecer diretamente uma fonte de dados de leitura. Pode ser Cache, pode ser XML, JSON, etc.
Como resolver o problema de como atualizar mencionado antes? Você pode usar o Evento, ou seja, um evento, por exemplo, quando um produto é vendido, você pode publicar um evento para modificar o Modelo de Leitura original.
Dessa forma, a sincronização torna-se assíncrona por meio do mecanismo de eventos.
Por fim, esse método é melhor usado apenas para consultas complexas, e as consultas simples originais ainda são buscadas no banco de dados relacional. Por quê? Como a introdução de uma nova tecnologia exige um preço, como etapas de mutação síncrona e mecanismos de eventos, não podemos apenas ver as vantagens das novas tecnologias e não as desvantagens.
|
Publicado em 04/05/2020 09:58:50
|
|
|
|
