Bancos chave-valor

O problema: nem todo dado precisa de consultas

Muitos dados de um sistema são acessados sempre do mesmo jeito: pela chave. A sessão do usuário pelo identificador da sessão. O carrinho pelo usuário. O contador de requisições pelo cliente e pelo minuto. Para eles, as junções, os índices e as transações de um banco relacional são custo sem uso.

Um banco chave-valor guarda cada valor sob uma chave e o devolve pela mesma chave. O Redis, o mais usado, guarda tudo na memória e responde em frações de milissegundo. E vai além do chave-valor puro: o valor pode ser uma estrutura de dados com operações próprias.

O tópico de cache trata do Redis como cache. Este trata dele como banco: as estruturas, a atomicidade, o que trava o servidor e o que acontece com os dados numa queda. Os testes usaram o Redis 8.

As estruturas de dados

A escolha da estrutura é a modelagem do Redis. Um placar como string serializada obriga a ler, ordenar e gravar a lista inteira a cada ponto. Como sorted set, cada ponto é um ZINCRBY, e os dez primeiros saem de um ZRANGE, já ordenados.

Atômico é o comando

O Redis executa um comando de cada vez, numa única thread. Cada comando é atômico: nada acontece no meio dele. Mas dois comandos seguidos não são. Medimos com 10 clientes fazendo 200 incrementos cada, num contador:

Com GET e SET, 82% dos incrementos se perderam: vários clientes leram o mesmo valor e gravaram o mesmo resultado. É a atualização perdida, de novo. O Redis tem um comando atômico para quase todo caso comum (INCR, HINCRBY, ZINCRBY, SET ... NX). Para lógicas que precisam de vários passos, há os scripts em Lua e as funções, que rodam inteiros sem interrupção.

Idas e voltas custam mais que o comando

Cada comando enviado e esperado é uma ida e volta pela rede. O pipelining manda vários comandos de uma vez e lê as respostas no fim. Gravando 20 mil chaves:

Mais de sete vezes mais rápido, na mesma rede Docker. Com o Redis em outra máquina, a diferença cresce, porque a ida e volta pesa mais. Pipeline não é transação: os comandos de outros clientes podem se intercalar entre os seus.

Um comando lento para o servidor inteiro

A mesma thread única que garante a atomicidade faz de cada comando lento uma pausa para todos. Com 1 milhão de chaves, medimos a pior espera de um cliente que fazia GET simples enquanto outro listava as chaves:

O KEYS percorre todas as chaves num comando só, e o servidor para durante esse tempo. O SCAN faz o mesmo trabalho em pedaços, devolvendo o controle entre eles. O mesmo vale para outras operações sobre estruturas grandes: HGETALL num hash de um milhão de campos, LRANGE 0 -1 numa lista enorme, DEL de uma chave gigante (UNLINK apaga em segundo plano).

Memória é o limite

O Redis guarda tudo na memória, e o maxmemory define o teto. Quando ele chega, a política de despejo (maxmemory-policy) decide o que acontece. Testamos gravando 100 mil valores de 500 bytes com o limite em 20 MB:

Com noeviction, o Redis recusa as gravações quando a memória acaba, com o erro command not allowed when used memory > 'maxmemory'. A aplicação fica sabendo. Com allkeys-lru, todas as gravações foram aceitas, e 65 mil chaves foram apagadas sem nenhum aviso para dar lugar às novas. Para um cache, é o comportamento desejado. Para um carrinho, uma sessão ou uma fila, é perda de dados silenciosa.

Persistência: o que sobra depois de uma queda

Por padrão, o Redis grava fotografias periódicas da memória em disco (RDB), por regras como "a cada 60 segundos, se houver 10 mil mudanças". Também pode gravar cada comando num log (AOF). Gravamos 10 mil chaves, confirmadas pelo servidor, e matamos o processo com kill -9 logo em seguida:

Com o padrão, as 10 mil gravações confirmadas sumiram: nenhuma fotografia tinha sido tirada ainda. Com o AOF, todas sobreviveram. O kill -9 derruba o processo, mas não a máquina: o que o Redis já tinha escrito no arquivo continuava na memória do sistema operacional. Numa queda da máquina, que o teste não simulou, o everysec pode perder até cerca de um segundo de gravações, e o always não perde nenhuma, ao custo medido: cinco vezes menos gravações por segundo.

Por que isso importa quando a IA escreve o código

Um assistente que usa Redis costuma tratá-lo como um dicionário remoto:

• GET, cálculo na aplicação e SET, em vez do comando atômico.
• Um comando por ida e volta em laços, sem pipeline.
• KEYS em código de produção para listar ou apagar chaves.
• Estruturas inteiras serializadas em JSON numa string, em vez de hash, set ou sorted set.
• Dados que não podem se perder num Redis com a configuração padrão, ou com allkeys-lru.
• Chaves sem tempo de expiração, crescendo até a memória acabar.

O próximo nível compara os usos do Redis, as configurações de persistência e de memória, e as alternativas.