Cache contro decisione progettuale DB?

Question

Cache contro decisione progettuale DB?

#1 da (3 voti)

0

Numero di volte in cui questa domanda viene rivolta alla mia e alla mia squadra, se dovessimo conservare o memorizzare nella cache i dati. Capisco che un po 'di tempo è funzionale requisito che abbiamo bisogno di persistere in DB. Ma nel mio caso non ce n'è.

Ma qui parlo principalmente in termini di scalabilità / esecuzione, mentre il design è migliore. Facciamo un esempio di Parcheggio dove posso mantenere completamente i dati nella cache distribuita con persistenza (se richiesto) come Redis o in DBMS come oracle / MySQL. Per sopravvivere al crash del server / al guasto del nodo, posso mantenere il set di repliche redis.

Quindi la domanda viene qui completamente basata sulle prestazioni che è meglio.

Secondo me ci sono due approcci per selezionarne uno (cache vs DB): -

Un modo è l'approccio passivo. Implementa sia l'approccio DB che cache, simula il carico e analizza il risultato. Ma credo che questo approccio richieda tempo. Inoltre, devi avere risorse e hardware per fare lo stesso.
La mia domanda è: in che modo è teoricamente possibile analizzare entrambi gli approcci basati su un carico? Considerare che ogni sistema in millisecondi ottiene 10 richieste di parcheggio.

La mia comprensione della strategia basata sulla cache sarà più utile in quanto possiamo salvare le operazioni di I / O. Ma in che modo teoricamente posso calcolare concretamente e avvicinarmi alla conclusione? Come posso calcolare qualcosa del genere La richiesta di 10 K al secondo impiegherà circa questo tempo con persistenza (con questa infrastruttura) e questo molto tempo sull'approccio basato sulla cache (con questa infrastruttura)? Questo potrebbe non essere corretto al 100% ma vicino a quello.

Di seguito è riportato un breve disegno del parcheggio per riferimento

public class ParkingLot 
{
    Vector<ParkingSpace> vacantParkingSpaces = null;
    Vector<ParkingSpace> fullParkingSpaces = null;

    int parkingSpaceCount = 0;

    boolean isFull;
    boolean isEmpty;

.................
}

public class ParkingSpace 
{
    boolean isVacant;
    Vehicle vehicle;
    ParkingType parkingType;
    int distance;
}

public class Vehicle 
{
    int num;
}

public enum ParkingType
{
    REGULAR,
    HANDICAPPED,
    COMPACT,
    MAX_PARKING_TYPE,
}

design java enterprise-architecture caching persistence

posta user3198603 12.08.2018 - 10:18

fonte

1 risposta

Leggi altre domande sui tag design java enterprise-architecture caching persistence

Che cos'è l'elenco di matrici in python? Come affrontare i lunghi test del sistema di processo?

score 3 · Answer 1

Potresti considerare quanto segue:

Mentre i Redis possono persistere dei dati, questo non era il suo obiettivo originale. È stato originariamente progettato come soluzione cache, non come database. Ciò è particolarmente importante se si prevede di rimanere flessibili e, infine, di passare a un'altra soluzione cache come memcached.
Redis è estremamente veloce quando i dati non sono persistenti. Se la persistenza è abilitata, mi aspetto che Redis abbia le sue prestazioni paragonabili ad altri database come Apache Cassandra.
A seconda della struttura dei dati, un archivio di valori-chiave può essere una soluzione ottimale, oppure no. Forse avrebbe senso archiviarlo come documento, nel qual caso avrebbe senso usare un database come MongoDB. O forse hai bisogno di un modello relazionale strong, e quindi un RDBMS sarebbe una buona scelta.

Si noti che non si tratta di essere in grado di rappresentare i propri dati usando questa o quella struttura: nella maggior parte dei casi (con alcune eccezioni molto strette), gli stessi dati potrebbero essere rappresentati come un documento, o come un gruppo di valori-chiave o l'utilizzo di un modello relazionale. Si tratta più del il modo più adatto per memorizzare i dati.

Supponiamo che sia un archivio di valori-chiave sia un RDBMS sembrino essere adatti. Quale sarebbe più veloce? (Allo stesso modo, immagina di dover scegliere tra più RDBMS o più database di documenti, ognuno dei quali corrisponde alle tue esigenze: quale ti darebbe prestazioni più elevate?)

Per avere un risultato affidabile, non hai altra scelta che implementare uno scenario di test di base utilizzando entrambe le soluzioni e confrontarle chiaramente eseguendole sullo stesso hardware. Questo è esattamente ciò che hai suggerito nel tuo primo punto. Non è necessario codificare l'intero livello di accesso ai dati dell'applicazione per due volte; prendi un po 'di operazioni che sono presumibilmente rappresentative dell'applicazione, fai un test ed eseguilo ripetutamente per un po' di tempo.

Per quanto riguarda i calcoli teorici, non farlo. Se sei un amministratore di database a tempo pieno e hai una competenza in entrambi i database che stai considerando di utilizzare per la tua applicazione, potresti trovare qualcosa di utile (tuttavia, con dieci anni di esperienza in entrambi i database, probabilmente sapresti già quale uno dei due che dovresti usare comunque). Altrimenti, i tuoi calcoli non saranno affidabili, o sarebbero semplicemente errati e fuorvianti, mentre impiegheresti più tempo che avresti impiegato per scrivere i test in primo luogo.