Dati di basePrestazioni

Caching

Tieni in memoria i tuoi dati più caldi e rispondi alle letture in molto meno di un millisecondo, su un motore che mette al lavoro ogni core.

GET/s in pipeline, misurati: 36.6M
precisione del TTL: ns
i client esistenti funzionano: RESP2/3

Passo 1 di 5

Leggi attraverso la cache

Un hit torna direttamente dalla memoria. Il database non viene toccato.

Sessione di esempioplaying

# Leggi attraverso la cache

hotkv> GET product:1001

"{\"name\":\"Desk lamp\",\"price\":39}"

Una dimostrazione animata con comandi HotKV reali e risposte di esempio. Clicca su un passo qualsiasi per andarci. Comandi e risposte restano in inglese, esattamente come li digiti e li vedi in HotKV.

Il problema

I database sono lenti e costosi da interrogare per dati letti migliaia di volte al secondo. Ogni visualizzazione di pagina, chiamata API o aggiornamento di dashboard ripete la stessa query, e il database diventa il collo di bottiglia molto prima della tua applicazione.

Come lo gestisce HotKV

HotKV si mette davanti al database e tiene i risultati in memoria. La tua applicazione legge prima da HotKV e ripiega sul database solo in caso di miss. Poiché HotKV esegue i comandi su molti thread contemporaneamente, una cache molto carica non fa passare ogni client per un solo core, e i tag ti permettono di invalidare un intero gruppo di voci quando cambiano i dati sottostanti.

Passo dopo passo

Cosa succede, comando per comando

01
Leggi attraverso la cache
Un hit torna direttamente dalla memoria. Il database non viene toccato.
GET product:1001
02
Miss, quindi carica una volta e metti in cache
In caso di miss l'applicazione legge il database una volta e mette in cache il risultato per cinque minuti.
SET product:2002 "{\"name\":\"Oak desk\",\"price\":420}" EX 300
03
Tagga le voci in base a ciò da cui dipendono
Ogni pagina in cache che mostra prodotti di illuminazione ha lo stesso tag.
TAG.SET product:1001 catalog:lighting
04
Invalida il gruppo
I prezzi sono cambiati. Elenca ogni chiave con il tag e cancellale in una sola pipeline.
TAG.MEMBERS catalog:lighting
05
Voci dalla vita brevissima
Un token flash, già impostato, che deve sparire dopo 250 ms, con precisione al nanosecondo.
NEXPIRE flash:token:9 250000000

Dove si usa

Scenari reali

Negozi online

Pagine prodotto, prezzi e livelli di stock vengono letti migliaia di volte al secondo e aggiornati per tag quando cambia il catalogo.

API e backend mobile

Le risposte degli endpoint più popolari vengono messe in cache con TTL brevi, così i picchi di traffico colpiscono la memoria invece del database.

Siti di contenuti

Frammenti renderizzati e metadati degli articoli vengono messi in cache per alcuni minuti e invalidati per tag quando una redazione pubblica.

Integrato

Cosa ottieni

TTL dai secondi ai nanosecondi

EXPIRE e PEXPIRE funzionano come ti aspetti. NEXPIRE aggiunge la precisione al nanosecondo.

EXPIREPEXPIRENEXPIRE

Invalidazione per tag

Etichetta le chiavi con TAG.SET, poi trova ogni chiave con un'etichetta.

TAG.SETTAG.MEMBERS

Compressione opzionale

I payload grandi si possono comprimere, così una parte maggiore del tuo working set entra in memoria.

Letture multithread

I comandi vengono eseguiti su thread paralleli, quindi il throughput cresce con i core. I numeri sono nella pagina Performance.

GETMGET

Riferimento:SET NEXPIRE TAG.SET TAG.MEMBERS

Domande frequenti

Posso usare il mio client Redis esistente?

HotKV parla il protocollo Redis (RESP2 e RESP3), quindi i client Redis standard si connettono. Controlla nel riferimento dei comandi quelli su cui fai affidamento.

Come invalido un gruppo di chiavi in cache?

Tagga le chiavi con TAG.SET quando le metti in cache, poi chiama TAG.MEMBERS e cancella ciò che viene restituito.

Da dove viene il dato di 36.6M?

È il throughput di GET in pipeline del benchmark pubblicato di HotKV. Metodo e hardware sono nella pagina Performance.