Solid Cache: internos do banco
O curso abre a gem solid_cache e lê o código e o SQL que ela envia ao Postgres. Acompanha a leitura pelo key_hash e pelo índice único, e a escrita por um único upsert que calcula o byte_size e nunca altera o created_at. Testa unless_exist e increment com dez threads concorrentes e mostra como o tamanho do cache é estimado a partir de dois índices. Explica como a expiração apaga linhas em ordem de id. Trata ainda do failsafe, dos shards com Maglev, da thread de fundo e da escolha entre Solid Cache e Redis.
O que você vai aprender
- ✓Como a leitura transforma a chave num key_hash de 64 bits servido por um índice único
- ✓Como uma escrita vira um único upsert, com compressão e byte_size calculado
- ✓Onde o FOR UPDATE deixa unless_exist e increment sem atomicidade em chaves ausentes
- ✓Como o tamanho do cache é estimado pelos índices de byte_size e composto
- ✓Como a expiração disparada por escritas apaga as linhas mais antigas por id
- ✓Como funcionam o failsafe, os shards com Maglev e a thread de fundo
Uma query por leitura: key_hash e o índice único
O curso de nível Júnior "Solid Cache: cache no banco de dados" terminou na tabela: SolidCache::Entry, uma linha por fragmento cacheado, com uma coluna byte_size real que dava para somar. Este curso abre a gem e lê o código que coloca essas linhas ali. Cada afirmação abaixo foi executada contra o…
Ler a aula completa grátis →Currículo
7 aulasUma query por leitura: key_hash e o índice único
A leitura transforma a chave num key_hash de 64 bits com sinal, via SHA-256, e o busca pelo índice único.
O caminho da escrita: upsert, compressão e byte_size
Uma escrita é um único upsert com ON CONFLICT que comprime o valor, calcula o byte_size e preserva o created_at.
FOR UPDATE trava linhas, não ausências
Testes com dez threads mostram unless_exist e increment exatos em linhas existentes e sujeitos a corrida em chaves ausentes.
Estimando o tamanho do cache a partir de dois índices
O tamanho do cache é estimado pelas maiores linhas e por um intervalo aleatório de key_hash, usando dois índices.
Expiração: FIFO por id, não LRU
Escritas disparam lotes de expiração que apagam primeiro os menores ids, e o expires_in só é checado na leitura.
Failsafe, shards e a thread de fundo
Erros transitórios viram cache miss, a expiração roda numa thread de fundo e o Maglev distribui chaves entre shards.
Juntando tudo: um fetch, de ponta a ponta
Um fetch rastreado por todas as camadas, com os custos de cada escolha do desenho e a comparação com Redis.