Valkey em cluster: namespace útil não é isolamento nem promessa de durabilidade

Em entrevista sobre a evolução do Valkey, Madelyn Olson e Viktor Söderqvist detalharam melhorias de execução, cluster e clientes, além de planos para usos além de cache.[18] A versão 9 passa a oferecer bancos numerados em modo cluster, migração atômica de slots e expiração de campos individuais de hashes.[18] A distinção importante é entre recursos disponíveis e garantias de durabilidade ainda em discussão.

O que muda para quem desenvolve

Bancos numerados removem uma dificuldade de quem dependia dos namespaces da instância única, mas não criam isolamento forte entre clientes nem eliminam restrições de operações entre slots.[18] Minha leitura: organização lógica de chaves e fronteira de segurança devem ser avaliadas separadamente. Não use um número de banco como única justificativa de isolamento de usuários.

A migração atômica de slots prepara os dados e faz uma troca final, evitando o estado parcialmente migrado de uma movimentação chave a chave interrompida.[18] Para a aplicação, ainda recomendo testar o comportamento de operações e clientes durante mudanças de topologia, em vez de assumir transparência completa.

A biblioteca GLIDE concentra lógica num núcleo Rust com interfaces por linguagem, procurando padronizar topologia, TLS, redirecionamentos, reconexões e pools.[18] Isso oferece uma direção para reduzir diferenças entre clientes, mas a escolha continua precisando atender às linguagens e às operações do sistema concreto.

Segundo Olson, melhorias de I/O nas versões 8.0 e 8.1 ampliaram a vazão de cerca de 200 mil a 250 mil requisições por segundo para aproximadamente um milhão por processo.[18] Esse relato não é uma previsão de capacidade para o seu conjunto de comandos, tamanho de valores e distribuição de acesso.

Como aplicar

Para avaliar uma migração de Redis, comece pelo inventário de comandos, clientes, configuração e formas de persistência realmente utilizadas. Defina quais dados podem ser reconstruídos e quais têm perda inaceitável.

Proponha um ensaio com carga representativa, incluindo valores e distribuição de chaves semelhantes aos do sistema. Compare latência, memória, erros e comportamento do cliente, não apenas a vazão máxima.

Depois, introduza falhas controladas e mudanças de topologia num ambiente de teste. Registre quais operações são repetidas, quais falham e como a aplicação recupera o estado. Se houver operações envolvendo várias chaves, confira sua distribuição e as restrições aplicáveis.

O critério de aceitação deve incluir recuperação, não somente desempenho. Para dados críticos, mantenha uma fonte persistente adequada até demonstrar que as garantias da versão e da configuração escolhidas atendem ao requisito.

Cuidados e limites

Replicação síncrona e armazenamento em camadas com dados quentes em RAM e frios em outros backends são planos de evolução descritos na entrevista.[18] Active-active entre clusters com consistência eventual é uma ideia de prazo mais longo, sem compromisso de implementação.[18] Não use esses itens como justificativa para garantias do software atual.

Parquet foi discutido para saída de CDC ou clickstream, não para reescrita dinâmica de dados numa camada de cache.[18] Preserve esse escopo. A decisão de arquitetura deve usar o que a versão implantada consegue demonstrar, e não a soma das possibilidades mais interessantes do roadmap.

Fonte

[18] Fonte: InfoQ