Separazione lettura-scrittura
Quando il business di un'azienda continua ad espandersi e il numero di utenti aumenta significativamente, il database originale probabilmente non sarà più in grado di sostenersi. Allora sì
- Scale-in, che espande le prestazioni dell'hardware, ma è probabile che il numero di utenti continui a crescere e le prestazioni aumentate saranno presto consumate.
- Separazione tra lettura-scrittura: Il database non può resistere, non è altro che troppa lettura e scrittura, specialmente se ci sono query complesse come i prodotti più popolari delle ultime 24 ore. Richiede istruzioni SQL molto complesse e, naturalmente, è lento da eseguire.
Tuttavia, per separare letture e scritture, il database deve essere diviso in librerie master e slave.
I principali database relazionali sul mercato supportano la replica dei dati, quindi puoi suddividere un database in due ruoli: Master e Slave, scrivere operazioni sul master e sincronizzare il server master con altri server slave.
Le operazioni offline come le operazioni di lettura e l'analisi dei dati vengono eseguite sul server Slave.
Sappiamo che molte applicazioni su Internet vengono lette, così che più schiavi possano condividere il carico e garantire la disponibilità e la correttezza dei dati.
Tuttavia, anche il corrispondente codice applicativo originale deve essere modificato, e deve essere modificato per usare la libreria master per scrivere i dati, e usare la libreria slave per la lettura dei dati, il che equivale a riscriverli.
Query complesse
Tuttavia, anche dopo aver riscritto il codice, ho notato che le prestazioni non erano ancora significativamente migliorate perché venivano usate troppe query complesse, e abbiamo detto nel componente database che le join richiedono molto prestazioni.
Possiamo quindi usare una tabella separata per memorizzare i prodotti popolari delle ultime 24 ore, così da dover usare solo SQL semplice per farlo.
In altre parole, un unico insieme di tabelle di database è inappropriato per comportamenti diversi come report, ricerche, transazioni, ecc.
La tabella attuale è progettata per aggiungere e modificare dati ed è non adatta a query complesse.
Ma dobbiamo anche considerare come questa query base viene aggiornata, o se possiamo tollerare questo ritardo, se potrebbe non essere aggiornata in tempo reale.
CQRS
Se il ritardo possa essere tollerato deve essere valutato dal punto di vista aziendale, come i prodotti più popolari delle ultime 24 ore, un po' di informazioni obsolete non ha molto impatto, serve solo la coerenza finale.
Possiamo usare CQRS (Command Query Responsibility Segregation), cioè la separazione dei comandi per aggiungere o modificare comandi dalle responsabilità delle query.
In CQRS, l'enfasi è sulla separazione tra read (Query) e write (Command), perché i dati letti dagli utenti sono solitamente obsoleti, quindi perché dover leggere dal database? Puoi stabilire direttamente una fonte di dati di lettura. Può essere Cache, può essere XML, JSON, ecc.
Come risolvere il problema di come aggiornare menzionato prima? Puoi usare Event, cioè un evento, ad esempio, quando un prodotto viene venduto, puoi pubblicare un evento per modificare il modello di lettura originale.
In questo modo, la sincronizzazione diventa asincrona attraverso il meccanismo degli eventi.
Infine, questo metodo è meglio usato solo per query complesse, e le query semplici originali vengono comunque recuperate nel database relazionale. Perché? Poiché l'introduzione di una nuova tecnologia richiede un prezzo, come le fasi di mutazione sincrona e i meccanismi di evento, non possiamo vedere solo i vantaggi delle nuove tecnologie e non gli svantaggi.
|
Pubblicato su 04/05/2020 09:58:50
|
|
|
|
