Qual è il punto di più database Redis?

Quindi, sono arrivato in un posto in cui volevo segmentare i dati che conservo in redis in database separati poiché a volte ho bisogno di utilizzare il comando keys su un tipo specifico di dati e volevo separarli per renderlo più veloce .

Se segmento in più database, tutto è ancora a thread singolo e posso ancora usare solo un core. Se avessi appena lanciato un'altra istanza di Redis sulla stessa scatola, avrei potuto usare un core aggiuntivo. Inoltre, non posso nominare i database Redis né fornire loro alcun tipo di identificatore logico. Quindi, detto tutto ciò, perché / quando dovrei mai voler utilizzare più database Redis invece di creare semplicemente un'istanza aggiuntiva di Redis per ogni database aggiuntivo che desidero? E di conseguenza, perché Redis non tenta di utilizzare un core aggiuntivo per ogni database aggiuntivo che aggiungo? Qual è il vantaggio di essere single threading nei database?

In linea di principio, i database Redis nella stessa istanza non sono diversi dagli schemi nelle istanze del database RDBMS.

Quindi, detto tutto ciò, perché / quando dovrei mai voler utilizzare più database Redis invece di creare semplicemente un'istanza aggiuntiva di Redis per ogni database aggiuntivo che desidero?

C'è un chiaro vantaggio dell'utilizzo dei database redis nella stessa istanza redis, e questa è la gestione. Se esegui il rollup di un'istanza separata per ogni applicazione e supponiamo che tu abbia 3 app, sono 3 istanze redis separate, ognuna delle quali probabilmente avrà bisogno di uno slave per HA in produzione, quindi sono 6 istanze totali. Da un punto di vista gestionale, questo diventa molto veloce perché è necessario monitorarli tutti, eseguire aggiornamenti / patch, ecc. Se non si prevede di sovraccaricare i redis con I / O elevato, una singola istanza con uno slave è più semplice e più facile da gestire a condizione che soddisfi il tuo SLA.

Non si desidera utilizzare più database in un'unica istanza redis. È obsoleto e, come hai notato, più istanze ti consentono di sfruttare più core. Se si utilizza la selezione del database, sarà necessario eseguire il refactor durante l'aggiornamento. Monitorare e gestire più istanze non è difficile né doloroso.

In effetti, otterresti metriche molto migliori su ogni db per segregazione basata sull'istanza. Ogni istanza avrebbe statistiche che riflettono quel segmento di dati, che può consentire una migliore regolazione e un monitoraggio più reattivo e accurato. Utilizzare una versione recente e separare i dati per istanza.

Come disse Jonaton, non usare il comando keys. Troverai prestazioni molto migliori se crei semplicemente un indice chiave. Ogni volta che aggiungi una chiave, aggiungi il nome della chiave a un set. Il comando keys non è terribilmente utile una volta ingrandito poiché ci vorrà molto tempo per tornare.

Lascia che il modello di accesso determini come strutturare i tuoi dati piuttosto che archiviarli nel modo in cui pensi che funzioni e quindi aggirare il modo in cui accedervi e tritarli in un secondo momento. Vedrai prestazioni molto migliori e scoprirai che il codice che consuma dati spesso è molto più pulito e semplice.

Per quanto riguarda il thread singolo, considera che redis è progettato per velocità e atomicità. Le azioni che modificano i dati in un db non devono necessariamente attendere un altro db, ma cosa succede se tale azione viene salvata nel file di dump o elaborata le transazioni sugli slave? A quel punto inizi a entrare nelle erbacce della programmazione di concorrenza.

Utilizzando più istanze si trasforma la complessità del multi threading in un sistema di stile di passaggio messaggi più semplice.

Anche Salvatore Sanfilippo (creatore di Redis) pensa che sia una cattiva idea usare più DB in Redis. Vedi il suo commento qui:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

Capisco come questo possa essere utile, ma sfortunatamente considero gli errori di database multipli Redis la mia peggior decisione nella progettazione di Redis ... senza alcun tipo di guadagno reale, rende gli interni molto più complessi. La realtà è che i database non si adattano bene per una serie di motivi, come la scadenza attiva di chiavi e VM. Se la selezione del DB può essere eseguita con una stringa, vedo che questa funzione viene utilizzata come livello di dizionario O (1) scalabile, che invece non lo è.

Con i numeri di DB, con un valore predefinito di alcuni DB, stiamo comunicando meglio cos'è questa funzione e come posso usare penso. Spero che a un certo punto potremo eliminare del tutto il supporto di più DB, ma penso che probabilmente sia troppo tardi perché ci sono molte persone che fanno affidamento su questa funzionalità per il loro lavoro.

1. Non conosco davvero alcun vantaggio di avere più database in una singola istanza. Immagino sia utile se più servizi utilizzano gli stessi server di database, quindi puoi evitare collisioni chiave.

2. Non consiglierei di compilare usando il KEYScomando, dato che è O (n) e che non si adatta bene. Per cosa lo stai usando per quello che puoi realizzare in un altro modo? Forse redis non è la migliore corrispondenza per te se funzionalità come KEYSè vitale.

3. Penso che menzionino i vantaggi di un singolo server threaded nelle loro FAQ, ma la cosa principale è la semplicità: non devi preoccuparti della concorrenza in modo reale. Ogni azione è bloccata, quindi due cose non possono modificare il database contemporaneamente. Idealmente si avrebbe una (o più) istanze per core di ciascun server e si userebbe un algoritmo di hashing coerente (o un proxy) per dividere le chiavi tra loro. Certo, perderai alcune funzionalità: le tubazioni funzioneranno solo per cose sullo stesso server, i tipi diventeranno più difficili ecc.

Sto usando Redis per implementare una lista nera di indirizzi e-mail e ho valori TTL diversi per diversi livelli di lista nera, quindi avere DB diversi nella stessa istanza mi aiuta molto.

I database Redis possono essere utilizzati nei rari casi di distribuzione di una nuova versione dell'applicazione, in cui la nuova versione richiede l'utilizzo di entità diverse.

L'uso di più database in una singola istanza può essere utile nel seguente scenario:

Copie diverse dello stesso database potrebbero essere utilizzate per produzione, sviluppo o test utilizzando dati in tempo reale. Le persone possono usare la replica per clonare un'istanza redis per raggiungere lo stesso scopo. Tuttavia, il primo approccio è più semplice per i programmi in esecuzione esistenti, basta selezionare il database giusto per passare alla modalità prevista.

So che questa domanda ha anni, ma c'è un'altra ragione per cui più database potrebbero essere utili.

Se si utilizza un "Redis cloud" dal proprio provider di cloud preferito, probabilmente si dispone di una dimensione di memoria minima e si paga per ciò che si alloca. Se tuttavia il tuo set di dati è più piccolo di quello, sprecherai un po 'dell'allocazione e quindi sprecherai un po' di denaro.

Usando i database potresti usare la stessa istanza cloud Redis per fornire servizi per (diciamo) dev, UAT e produzione, o più istanze della tua applicazione, o qualsiasi altra cosa, usando così più memoria allocata e quindi un po 'più costosa- efficace.

Un caso d'uso che sto esaminando ha diverse istanze di un'applicazione che usano 200-300K ciascuna, ma l'allocazione minima sul mio provider cloud è 1M. Siamo in grado di consolidare 10 istanze su un singolo Redis senza fare davvero alcun problema, risparmiando così circa il 90% dei costi di hosting di Redis. Apprezzo che ci siano limitazioni e problemi con questo approccio, ma ho pensato che valesse la pena menzionarlo.