|
Aplicativos orientados a dados abrangem uma ampla gama de complexidade, desde microsserviços simples a sistemas orientados a eventos em tempo real sob carga significativa. No entanto, como qualquer equipe de desenvolvimento e/ou DevOps encarregada de melhorias de desempenho atestará, tornar os aplicativos orientados a dados rápidos globalmente é “não trivial”.
Arquiteturas de aplicativos modernos, como o JAMstack, reforçam a separação de interesses movendo os dados e os requisitos de persistência para a API. A separação clara de conteúdo estático, lógica de negócios e persistência de dados permite que cada um seja dimensionado e gerenciado de forma independente.
Muitas empresas também estão focadas em desacoplar seus aplicativos monolíticos para utilizar microsserviços e geralmente estão implantando em ambientes sem servidor. Essa mudança para mais dissociação para melhor isolamento ambiental também pode fornecer melhor agilidade regional em relação a onde a lógica de negócios é implantada e como ela é dimensionada. Os aplicativos agora podem ser implantados globalmente em uma única ação de CI/CD.
A camada de dados, no entanto, apresenta maior complexidade. Existem desafios práticos, como consistência transacional, alta disponibilidade e desempenho de consulta sob carga. Existem restrições, como aderir a PII e requisitos de conformidade. E há limites intransponíveis como os que as leis da física impõem à latência.
Cache de aplicativo
Muitas equipes de desenvolvimento procuram o cache para resolver esses problemas na camada do aplicativo, apoiadas por camadas de persistência como Redis ou sistemas internos. O conceito é simples:armazenar os dados solicitados pelo cliente por um período de tempo e se voltarmos a vê-los, já os temos prontos para atender a próxima solicitação sem recorrer ao banco de dados de origem. A engenharia de uma boa estratégia de armazenamento em cache traz seu próprio conjunto de desafios:quais dados armazenar em cache, como armazená-los em cache e quando. E talvez mais importante, o que, como e quando remover dados do cache. A estratégia de cache deve ser bem definida, compreendida e empregada para cada novo conjunto de recursos adicionado ao aplicativo, entre desenvolvedores e equipes potencialmente departamentais. O tempo de desenvolvimento e a complexidade são o custo.
Réplicas de leitura do banco de dados
Como alternativa, muitas empresas resolvem os desafios de latência e dimensionamento com réplicas de leitura de banco de dados. As réplicas de leitura são instâncias somente leitura do banco de dados primário e são mantidas sincronizadas automaticamente (de forma assíncrona) à medida que as atualizações são feitas no primário. Projetar uma estratégia de réplica de leitura sólida é uma tarefa assustadora cheia de seus próprios custos e complexidades sutis e não tão sutis.
Grande parte dessa complexidade pode ser domada com ScaleGrid. Réplicas de leitura totalmente gerenciadas podem ser implantadas com o clique de um botão do ScaleGrid (com suporte HA) em todas as principais nuvens e regiões, com o principal benefício de que os dados são mantidos em sincronia com o banco de dados primário automaticamente.
No entanto, as réplicas de leitura não podem escapar da necessidade de executar vários, talvez vários servidores de banco de dados e seus custos associados.
Uma abordagem diferente:PolyScale.ai Edge Cache
O PolyScale é um cache de borda de banco de dados que adota uma abordagem diferente. O cache do PolyScale oferece dois benefícios principais:latência de consulta aprimorada e carga de trabalho de banco de dados reduzida. Vamos detalhar um pouco:
Latência regional é resolvido como um CDN; O PolyScale fornece uma rede global de pontos de presença (PoP) e armazena as respostas de consulta do banco de dados perto do cliente de origem, acelerando significativamente as respostas.
Desempenho da consulta de leitura foi drasticamente aprimorado, pois o PolyScale atenderá a qualquer solicitação de banco de dados em cache em <10 ms, independentemente da complexidade da consulta. Além disso, como as solicitações de leitura são atendidas pelo PolyScale, essa carga nunca afeta o banco de dados de origem.
Implementação
O PolyScale pode ser implementado sem escrever código ou implantar servidores em poucos minutos. Basta atualizar a cadeia de conexão do cliente de banco de dados (seja um aplicativo Web, microsserviço ou ferramenta de BI, como o Tableau) com o nome do host PolyScale. O tráfego do banco de dados passará pela rede de borda e estará pronto para armazenamento em cache.
Sendo compatível com MySQL e Postgres, o PolyScale é completamente transparente para clientes de banco de dados, portanto, nada muda com sua arquitetura atual. Sem migrações, sem alterações na transacionalidade e sem alterações em seu idioma de consulta atual. Verdadeiramente plug and play.
Como funciona?
A rede global da PolyScale faz proxy e cache de protocolos de fio de banco de dados nativos para que seja transparente para qualquer cliente de banco de dados. As consultas são inspecionadas e lidas (SQL SELECT ) pode ser armazenado em cache geograficamente próximo à origem solicitante para desempenho acelerado. Todos os outros tráfegos (INSERT , UPDATE e DELETE ) passa perfeitamente para o banco de dados de origem.
A IA da PolyScale está no caminho da automação total. Em vez de configurar o cache conforme necessário, a plataforma medirá o fluxo de tráfego e ajustará continuamente as propriedades do cache para fornecer um desempenho ideal. Você pode ler mais sobre o modelo de cache PolyScale AI aqui.
Conclusões
O PolyScale.ai fornece uma abordagem moderna e plug and play para desempenho e dimensionamento na camada de dados. A plataforma PolyScale está no caminho da automação total onde, uma vez conectada, gerenciará de forma inteligente o armazenamento em cache dos dados para um desempenho ideal.
Como o PolyScale é compatível com o seu banco de dados atual, nenhuma alteração é necessária para dimensionar as leituras globalmente em minutos. De uma chance!
