Redis o Valkey: il fork vince solo quando cresce la concorrenza

Nella tesi sperimentale dell’Università di Umeå, Valkey 8.0.2 supera Redis 7.2.7 nel throughput soprattutto quando crescono le connessioni simultanee nel carico con il 95% di letture; Redis conserva un vantaggio nella fascia di concorrenza bassa e intermedia quando letture e scritture sono in parti uguali. Il sorpasso riguarda quelle versioni e quella configurazione, non qualsiasi installazione dei due database.

Per scegliere, conta anzitutto il traffico che l’applicazione genera davvero. Valkey è interessante per una cache con molte richieste concorrenti e per chi richiede una licenza permissiva; Redis può risultare preferibile con altri carichi o quando servono funzioni sviluppate dopo la separazione dei progetti. Se l’obiettivo è migrare, la capacità del client di connettersi è soltanto una parte della compatibilità: vanno considerati anche comandi, moduli e dati persistenti.

La licenza può decidere prima della velocità

Il repository di Valkey identifica il progetto come fork di Redis e ne indica la licenza BSD a tre clausole. Per chi distribuisce software o mantiene modifiche proprie, i termini di una licenza permissiva possono essere un requisito architetturale indipendente dalle operazioni al secondo. La licenza del codice, però, non descrive da sola le condizioni economiche o operative di un servizio cloud gestito.

Per Redis bisogna distinguere versioni e prodotti. La comparazione pubblicata da Redis indica che Redis Open Source, dalla versione 8, offre AGPLv3 insieme a RSALv2 e SSPLv1 e include funzioni come JSON, serie temporali e ricerca. La stessa pagina distingue il software open source dagli strumenti delle offerte commerciali. Una valutazione della licenza deve quindi riferirsi alla versione e al prodotto che saranno effettivamente installati, mentre una valutazione delle funzioni deve verificare quelle chiamate dall’applicazione.

Il throughput cambia con il carico; la latenza non segue sempre

Nel test universitario, Valkey resta dietro a Redis per gran parte delle condizioni con metà letture e metà scritture e lo supera di poco soltanto nella fascia più affollata. Nel carico dominato dalle letture il vantaggio cambia prima e diventa più visibile all’aumentare delle connessioni. Questo andamento dà una ragione concreta per provare Valkey sotto traffico concorrente, ma non permette di attribuire il risultato al solo nome del motore: sono state confrontate anche versioni diverse.

La latenza delle richieste più lente richiede una lettura distinta dal throughput. Nel carico con più scritture, i valori di coda di Valkey oscillano attorno a quelli di Redis senza un vantaggio costante. Nel carico orientato alle letture, la latenza migliora in diverse condizioni di alta concorrenza, ma non in ogni misura e a ogni livello. Un’applicazione che dipende da risposte prevedibili può dunque preferire la configurazione con meno richieste lente anche quando un’altra completa più operazioni complessive.

Una successiva pubblicazione su arXiv firmata anche dall’autore della tesi è stata ritirata: la nota segnala errori numerici rilevanti e conclusioni non sostenute dai dati sottostanti. I risultati della tesi restano consultabili, ma questa circostanza rende imprudente trasformare le sue differenze di throughput in una previsione del guadagno ottenibile migrando.

Quali condizioni rendono confrontabili due benchmark

Il numero di connessioni non basta a descrivere la concorrenza. Bisogna conoscere anche quanti thread genera il client di prova, se invia richieste in pipeline, quale protocollo usa e quanti thread I/O sono attivi sul server. A parità di connessioni, una pipeline può tenere occupato il database in modo diverso da client che attendono ogni risposta prima di inviare la richiesta successiva. Se il generatore di carico o la rete raggiungono il proprio limite, il throughput osservato smette di rappresentare la capacità del database.

Nella prova di Umeå, ogni prodotto era un’istanza singola in Kubernetes, con persistenza disattivata, un limite di due core e richieste senza pipeline; il generatore impiegava dieci thread. Il confronto riguardava chiavi precaricate e due proporzioni di letture e scritture. Queste condizioni rendono leggibile il risultato, ma lasciano fuori il costo di replica, cluster, salvataggi e failover. Anche i valori predefiniti dei diversi pacchetti di distribuzione possono influire sulle differenze misurate.

Per trasferire quel confronto a un’applicazione reale, conviene mantenere identici dati, dimensione dei valori, distribuzione delle chiavi, TLS, percorso di rete e impostazioni di persistenza. Throughput e latenza di coda vanno osservati allo stesso livello di concorrenza, con le versioni candidate e con la pipeline usata dall’applicazione. In questo modo il risultato risponde alla domanda utile: quale configurazione sostiene il traffico previsto entro il limite di latenza richiesto?

Compatibilità: client, funzioni e file di dati

La guida alla migrazione di Valkey documenta la compatibilità con Redis OSS fino alla serie 7.2 per protocollo, configurazione e formati RDB e AOF; i client Redis possono collegarsi tramite RESP. La guida avverte però che i file di dati prodotti da Redis Community Edition 7.4 e successive non sono compatibili con una copia diretta verso Valkey. Una connessione riuscita, quindi, non garantisce che si possano trasferire allo stesso modo i dati salvati su disco.

Il controllo dell’applicazione riguarda i comandi effettivamente usati, gli script Lua, i moduli e la versione delle librerie client. Le due linee di sviluppo hanno aggiunto funzioni proprie dopo il fork: un client può parlare con entrambi i server e dipendere comunque da un comando o da un tipo di dato disponibile soltanto in uno. Per un archivio persistente occorre inoltre verificare quale versione ha scritto i backup e provare il ripristino, non soltanto l’avvio con una cache vuota.

• Applicazione: inventariare comandi, tipi di dati, script, moduli e librerie client in uso.
• Dati: identificare la versione che ha prodotto RDB o AOF e verificare tempi e correttezza del ripristino.
• Esercizio: confrontare autenticazione, metriche, replica e comportamento durante il failover.
• Cloud: controllare versioni e funzioni offerte dal fornitore, insieme alle procedure di passaggio e ritorno.

La scelta per l’installazione prevista

Valkey merita una prova diretta quando il carico è dominato dalle letture, le connessioni simultanee sono numerose e l’applicazione usa funzioni disponibili in entrambi i progetti. Redis resta una scelta plausibile se prevalgono altri carichi, se serve una sua funzione specifica o se il servizio gestito soddisfa meglio i requisiti operativi. La licenza può decidere anche quando la differenza di prestazioni è piccola.

Il risultato più utile di un test locale è il margine rispetto al limite di latenza dell’applicazione, insieme alla possibilità di migrare dati e dipendenze senza perdere funzioni necessarie. Quel margine, misurato con le versioni e le impostazioni che entreranno in produzione, conta più di un vincitore dichiarato per tutti i carichi.

Leggi anche:

• Asana o Trello: il team piccolo paga la semplicità quando cresce
• LangChain o LlamaIndex: nei benchmark il framework non decide da solo
• OpenAI Dots resta sempre attivo mentre cresce l’allarme sicurezza