Uma camada de cache de banco de dados ainda é necessária?

Como discuti em um artigo anterior sobre cache, a introdução de uma camada de cache na frente de um banco de dados, seja externo ou interno, tem eficácia limitada na melhoria do desempenho de um aplicativo que sofre de acesso lento aos dados. O ponto principal a lembrar é que as funcionalidades do usuário final normalmente exigem vários acessos ao banco de dados.

Para que o cache melhore a experiência do usuário final, todas essas consultas ao banco de dados devem ser atendidas a partir do cache. Portanto, a menos que a taxa de acertos do cache seja excepcionalmente alta, é improvável que o armazenamento em cache seja benéfico.

Você pode estar se perguntando por que a maioria das tecnologias de banco de dados inclui uma camada de cache interna ou por que colocar uma tecnologia de cache na frente de um banco de dados é uma prática comum. A resposta curta é que o cache melhora efetivamente o rendimento, mas não a latência.

Taxa de transferência vs. Latência

Em teoria, a taxa de transferência e a latência são independentes. Isso significa que é possível ter um sistema com rendimento massivo, mas com tempo de resposta incrivelmente lento. Por exemplo, eu poderia preencher 1 petabyte de discos com as informações solicitadas e enviá-los ao cliente durante a noite. Nesse cenário, a taxa de transferência do sistema seria de impressionantes 11,6 gigabytes por segundo (1 petabyte/(24 horas * 3.600 segundos)). No entanto, a latência seria um dia péssima.

Na prática, entretanto, o rendimento insuficiente pode afetar significativamente a latência. Revisitando o exemplo anterior, vamos considerar que o cliente agora solicita 10 petabytes de informações, mas temos apenas 1 petabyte de discos disponíveis para envio. Conseqüentemente, o processo de entrega levaria vários dias: levaria um dia para enviar o primeiro petabyte e outro dia para o cliente devolver os discos. Esse ciclo se repetiria até o 19º dia, quando todos os dados seriam finalmente enviados. Portanto, a falta de rendimento aumentaria efetivamente o tempo de resposta por um fator de 19.

Aumentando o rendimento com uma camada de cache

Com base no exemplo anterior, a introdução de uma camada de cache é semelhante à configuração de um hub local projetado para armazenar 90% dos dados que um cliente provavelmente solicitará. Este hub está equipado para despachar até 9 petabytes de dados por remessa, permitindo que as entregas sejam concluídas em apenas uma hora.

Para entregar 10 petabytes de dados ao cliente, 9 petabytes podem ser enviados do hub local em uma hora e o 1 petabyte restante será entregue do armazenamento principal no dia seguinte. Ao implementar um hub local, aumentamos o rendimento em dez vezes e melhoramos o tempo de resposta por um fator de 19.

É crucial compreender que esta melhoria drástica no tempo de resposta é atribuída exclusivamente ao aumento da produtividade; a velocidade de entrega em si não influencia esta melhoria.

Armazenar em cache ou não armazenar em cache

Até agora, aprendemos que adicionar um cache melhora a latência se e apenas se a lentidão é devido ao rendimento insuficiente. No exemplo acima, se o cliente não estiver satisfeito com o tempo de resposta de um dia, aumentar a capacidade do disco de remessa ou a porcentagem de dados armazenados no hub local para menos de 100% não aumentará o tempo de resposta.

Para determinar se um cache pode ser benéfico, é essencial considerar os algoritmos e estruturas de dados do banco de dados, o hardware em que ele opera e os padrões de acesso aos dados do aplicativo. Consequentemente, não existe uma resposta única para todos. Em vez de me contentar com a resposta vaga e insatisfatória de “depende”, pretendo fornecer uma análise detalhada nas seções a seguir, descrevendo as vantagens e as desvantagens do armazenamento em cache.

O caso contra o cache

Começo apresentando o argumento contra o armazenamento em cache porque, dadas as capacidades do hardware comum atual, o armazenamento em cache geralmente deveria ser desnecessário.

Isto levanta a questão: por que quase todas as tecnologias de banco de dados conhecidas ainda incluem um cache interno?

A resposta é bastante fascinante, exigindo uma exploração de numerosos detalhes. Por enquanto, consideremos esta prova por contradição: o Aerospike, um banco de dados que opera sem cache, consegue igualar ou até superar o desempenho de tecnologias que armazenam parte ou todos os seus dados na memória. Isto demonstra claramente que o cache não é indispensável para alcançar o desempenho ideal.

Concordo que o cache tem sido historicamente sinônimo de alto desempenho e, para muitos, a noção de um banco de dados operando sem uma camada de cache parece inconcebível. No entanto, as capacidades do hardware moderno e pronto para uso, juntamente com as mudanças nas práticas de desenvolvimento de software nos últimos anos, transformaram dramaticamente o cenário.

Por exemplo, unidades de estado sólido (SSDs) modernas e prontas para uso agora podem atingir taxas de transferência de 12 a 14 gigabytes por segundo – aproximadamente 60 vezes mais rápido do que os discos giratórios que eram comuns há uma década. Este avanço significativo é particularmente digno de nota dado que as velocidades de clock das nossas CPUs e as frequências da nossa memória permaneceram praticamente inalteradas durante este período.

Por outro lado, os aplicativos de software modernos são executados na nuvem e dependem da comunicação entre componentes em redes que normalmente oferecem até 12,5 gigabytes por segundo de largura de banda (100 gigabits por segundo). No entanto, este número é meramente teórico. Na prática, as ineficiências em nossa pilha de rede, incluindo sobrecargas de tamanho de pacotes e quadros, atrasos e outros fatores, nos impedem de usar até mesmo um terço dessa capacidade.

Estas mudanças são significativas por duas razões principais. Primeiro, nas aplicações modernas, a rede, e não o disco, tornou-se o componente mais lento da pilha. Segundo, a lacuna de desempenho entre memória e disco diminuiu substancialmente; embora os discos fossem anteriormente duas a três ordens de magnitude mais lentos que a memória, agora eles são apenas cerca de uma ordem de magnitude mais lentos.

Por estes motivos, implantar um cache na frente de um banco de dados, seja interno ou externo, costuma ser ineficiente:

• Cache externo: o cache deve ser acessado por uma rede, o que normalmente fornece uma taxa de transferência significativamente menor em comparação com o acesso direto à memória. Esse arranjo pode levar à subutilização das capacidades de desempenho da RAM.
• Cache interno: Os computadores modernos normalmente incorporam vários discos que, coletivamente, fornecem uma taxa de transferência muito superior à que a rede pode suportar. Portanto, o rendimento adicional obtido de um cache interno não se traduz necessariamente em desempenho aprimorado.

Conforme destacado no início desta seção, se um banco de dados puder usar totalmente toda a taxa de transferência de disco disponível, não será necessário armazenar os dados em cache na memória.

O caso a favor do cache

Neste ponto, você pode estar pensando que tenho uma tendência contra caches! Nada poderia estar mais longe da verdade. Deixe-me fornecer algumas diretrizes sobre quando o cache é realmente eficaz:

• Armazenando resultados de cálculos ou transformações: a recuperação de dados às vezes envolve operações computacionais ou transformações que exigem ciclos adicionais de CPU. Armazenar em cache os resultados desses cálculos ou transformações pode aumentar efetivamente a largura de banda computacional do aplicativo, melhorando o desempenho geral.
• Alto rendimento em um pequeno conjunto de dados: considere um cenário em que você precisa gerenciar 400 gigabytes de dados, mas exige uma taxa de transferência equivalente a 10 discos. Nesses casos, usar um banco de dados na memória pode ser uma solução mais eficaz. No entanto, é crucial lembrar que os bancos de dados na memória são voláteis. Se os dados forem críticos, será necessário um banco de dados na memória com armazenamento para proteção contra perda de dados.
• Melhorando o desempenho para uma sequência de solicitações: Embora idealmente o acesso sequencial deva ser evitado, às vezes é inevitável. Nesses casos, ter um cache, mesmo com uma taxa de acertos de cache muito baixa, ainda pode melhorar a experiência do usuário.
• Melhorando a localidade dos dados: armazenar dados em cache mais próximos dos usuários pode reduzir significativamente os custos de rede se a fonte estiver localizada longe. Por exemplo, os componentes estáticos de um site podem ser armazenados em cache mais perto do cliente para reduzir custos e minimizar a falta de confiabilidade associada à transferência de dados entre continentes pela Internet pública.
• Eliminando a latência da rede: configurar um cache local no servidor de aplicativos pode remover completamente a latência da rede, melhorando o desempenho.
• Usando memória excedente: muitos aplicativos não exigem quantidades significativas de memória, mas os servidores geralmente são equipados com bastante memória. Empregar esse excesso de memória para armazenamento em cache pode ser vantajoso. Quero enfatizar que os caches geralmente não causam danos; é a relação custo-eficácia que muitas vezes inclina a balança contra eles. Contanto que você não dependa apenas da adição de mais RAM como estratégia de ajuste de desempenho, aproveitar o excesso de memória para armazenamento em cache é uma abordagem decente.
• Usando cache como banco de dados na memória: para aplicativos que dependem consistentemente de uma porção específica de dados, como dados da última semana ou mês, considere usar um cache como um banco de dados na memória para manter prontamente disponíveis esses dados acessados ​​com frequência.
• Armazenando dados em cache localmente no processo: Um pequeno desvio aqui — o cache local não é diretamente relevante para o foco deste artigo ou do artigo anterior. Pretendo apenas esclarecer aos leitores a distinção entre tecnologias de cache e cache local.

Empacotando

Para casos de uso geral, considere usar um banco de dados moderno como o Aerospike, que usa eficientemente a taxa de transferência do disco. Isto eliminaria a necessidade de gastar dinheiro e recursos excessivos em tecnologias que exigem memória substancial para armazenamento em cache. Além de fornecer funções básicas de banco de dados, ele também pode ser configurado como um banco de dados na memória, um banco de dados na memória com suporte de armazenamento, cache na memória ou cache em disco. Essa adaptabilidade garante que, se o seu caso de uso puder se beneficiar do cache, o Aerospike também poderá atender perfeitamente a esse requisito.

O Aerospike versão 7.1 introduz a remoção precisa do cache menos usado recentemente (LRU) no núcleo do banco de dados, expandindo sua capacidade de impulsionar casos de uso de cache na memória de nível empresarial. Saiba mais em Aerospike.com.