Você já ouviu falar da teoria do búfalo? De acordo com esta teoria, uma manada de búfalos só pode mover-se tão rapidamente quanto o búfalo mais lento.” Surpreendentemente, esta sabedoria encontra um paralelo na operação de programas de computador: a velocidade de uma aplicação é limitada pelo seu subprocesso mais lento.
Consideremos o site de um varejista online. A tarefa de carregar a página de um produto está longe de ser trivial – ela exige a execução contínua de múltiplas suboperações, incluindo, mas não se limitando a:
Recuperando descrições detalhadas do produto
Carregando imagens e vídeos de produtos
Buscando avaliações de clientes
Gerando sugestões para produtos semelhantes
Compilando recomendações para itens comumente agrupados
Acessando detalhes da conta do usuário
Resumindo o conteúdo do carrinho de compras
Exibindo itens visualizados recentemente
Apresentando descontos disponíveis
Muitas dessas tarefas exigem consultas ao banco de dados. Se fizéssemos um gráfico do tempo que o banco de dados leva para fornecer as informações necessárias para cada suboperação, o padrão seria semelhante ao seguinte:
Claramente, o tempo de carregamento da página não pode ultrapassar a duração da suboperação mais demorada, que neste cenário é a suboperação 5. Nos esforços para simplificar o desempenho, a abordagem convencional envolve a implantação de um cache na frente do banco de dados. Esta estratégia mudaria os tempos de resposta para:
Algumas operações se beneficiarão do cache, recuperando dados rapidamente, enquanto outras exigirão acesso direto ao banco de dados, que será tão lento quanto antes. Dado que a velocidade geral de carregamento da página depende apenas da tarefa mais lenta, a introdução de um cache produz um efeito mínimo no tempo total de carregamento da página.
O termo “mínimo” é usado deliberadamente porque, na prática, a introdução de um cache pode melhorar ligeiramente os tempos de resposta para operações que não atingem o cache. Essencialmente, colocar um cache na frente do banco de dados reduz sua carga de trabalho, o que pode resultar em um desempenho um pouco melhor. No entanto, é improvável que essa melhoria seja drástica, a menos que o banco de dados esteja extremamente subprovisionado.
No entanto, esta melhoria marginal poderá não justificar o investimento, tendo em conta que melhorias semelhantes poderiam ser alcançadas através da simples atribuição de mais recursos à base de dados. Essa estratégia não complicaria o aplicativo ou a infraestrutura, como poderia acontecer com a adição de um sistema de cache.
Pode-se especular se uma taxa de acertos de cache suficientemente alta poderia melhorar decisivamente o desempenho. Infelizmente, a resposta permanece negativa. Este otimismo não considera um detalhe crucial: o aumento da latência média não afeta a latência máxima. À medida que o número de subprocessos aumenta, a probabilidade de atingir um acerto de cache para todas as operações cai exponencialmente, destacando a eficácia limitada do armazenamento em cache à medida que os subprocessos se acumulam.
O gráfico a seguir ilustra a diminuição da eficácia das estratégias de cache à medida que o número de subprocessos aumenta:
É importante destacar que mesmo com uma impressionante taxa de acertos de cache de 99%, conseguida mantendo um tamanho de cache substancial, a probabilidade de um carregamento de página envolvendo cinco suboperações ser servido somente a partir do cache não excederia %95 (=%99^5) . Embora um nível de eficiência de 95% seja digno de nota, a maioria das empresas pretende garantir o desempenho ideal para 99% das solicitações dos usuários, destacando uma lacuna entre os resultados ideais e os reais com essa estratégia de cache.
Redefinindo a solução
Abordar a questão central é essencial para resolver o problema. O problema do cache é que ele melhora a latência média dos subprocessos, o que tem impacto mínimo na latência geral do aplicativo. Para melhorar significativamente o desempenho, o foco deve mudar para a redução da latência máxima entre os subprocessos (especificamente, o percentual de latência mais alto).
Simplificando, se o acesso aos dados estiver deixando seu aplicativo lento, a única solução é um banco de dados mais rápido, não um cache. Vários fornecedores se gabam de oferecer valores de latência abaixo de um milissegundo; no entanto, a maioria atinge esses números através da dependência de uma camada de cache interna. É importante observar que as limitações das estratégias de cache, conforme discutido anteriormente, são igualmente aplicáveis a esses caches internos.
Procure uma tecnologia de banco de dados como o Aerospike, capaz de fornecer latência inferior a um milissegundo sem depender de uma camada de cache. Ao entregar dados diretamente do disco – acessando qualquer segmento de dados, mesmo quando a proporção de memória para disco é tão baixa quanto 1% – ele alcança desempenho equivalente ao de tecnologias que exigem que os dados sejam servidos a partir da memória para atingir tempos de resposta rápidos.
Estudo de caso: Transformando uma grande empresa de comércio eletrônico
A transformação de um varejista on-line líder ilustra o impacto da otimização estratégica de banco de dados.
O varejista depende de análises de dados complexas para fornecer recomendações de produtos e posicionamentos de anúncios eficazes. Após migrar para o Aerospike, a empresa observou um aumento de 6% no tamanho do carrinho do cliente e uma redução de 30% no abandono do carrinho. Estes números sublinham o potencial transformador da otimização do acesso aos dados no cenário do comércio digital.
Visite nosso site para saber mais sobre o banco de dados Aerospike.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
Behrad Babaee é um evangelista de tecnologia na Aerospike. Ele arquitetou vários aplicativos que você pode usar diariamente. Ele está interessado em atributos não funcionais de aplicações com uso intensivo de dados, como desempenho, escalabilidade, disponibilidade e eficiência. Behrad usa sua ampla habilidade e experiência…
Este site utiliza cookies para melhorar sua experiência de navegação. Ao continuar, você concorda com o uso de cookies. Para mais informações, consulte nossa Política de Privacidade.
Funcional
Sempre ativo
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos.O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.