Separarea citire-scriere
Când afacerea unei companii continuă să se extindă și numărul utilizatorilor crește semnificativ, baza de date originală este probabil să nu se poată susține. Atunci da
- Scale-in, care extinde performanța hardware-ului, dar este probabil ca numărul utilizatorilor să continue să crească, iar performanța crescută va fi în curând devorată.
- Separarea citire-scriere: Baza de date nu poate rezista, nu este decât prea multă citire și scriere, mai ales dacă există interogări complexe, cum ar fi cele mai populare produse din ultimele 24 de ore. Necesită instrucțiuni SQL foarte complexe și, desigur, rulează lent.
Totuși, pentru a separa citirile și scrierile, baza de date trebuie împărțită în biblioteci master și slave.
Principalele baze de date relaționale de pe piață suportă replicarea datelor, astfel încât poți împărți o bază de date în două roluri: Master și Slave, să scrii operațiuni pe master și să sincronizezi serverul master cu alte servere slave.
Operațiunile offline, cum ar fi operațiunile de citire și analiza datelor, sunt efectuate pe serverul Slave.
Știm că multe aplicații de pe Internet sunt citite, astfel încât mai mulți sclavi să poată împărți sarcina și să asigure disponibilitatea și corectitudinea datelor.
Totuși, codul original corespunzător al aplicației trebuie modificat și trebuie schimbat pentru a folosi biblioteca principală pentru a scrie date și pentru a folosi biblioteca slave la citirea datelor, ceea ce este echivalent cu rescrierea.
Interogări complexe
Totuși, chiar și după rescrierea codului, am constatat că performanța nu a fost semnificativ îmbunătățită deoarece au fost folosite prea multe interogări complexe, iar în componenta de bază de date am spus că join-urile sunt foarte solicitante din punct de vedere al performanței.
Deci putem folosi un tabel separat pentru a stoca produsele populare din ultimele 24 de ore, astfel încât să avem nevoie doar de SQL simplu pentru a face asta.
Cu alte cuvinte, un singur set de tabele de baze de date este nepotrivit pentru comportamente diferite, cum ar fi rapoarte, căutări, tranzacții etc.
Tabelul actual este conceput pentru a adăuga și modifica date și nu este potrivit pentru interogări complexe.
Dar trebuie să luăm în considerare și modul în care această bază de interogări este actualizată, sau dacă putem tolera această întârziere, dacă nu poate fi actualizată în timp real.
CQRS
Dacă întârzierea poate fi tolerată trebuie privită dintr-o perspectivă de afaceri, cum ar fi cele mai populare produse din ultimele 24 de ore, puțină informație depășită nu are un impact prea mare, este necesară doar consistența finală.
Putem folosi CQRS (Command Query Responsibility Segregation), adică separarea comenzilor pentru adăugarea sau modificarea comenzilor de responsabilitățile interogării.
În CQRS, accentul este pus pe separarea dintre citire (Interogare) și scriere (Comandă), deoarece datele citite de utilizatori sunt de obicei depășite, așa că de ce trebuie să citești din baza de date, poți stabili direct o sursă de date de citire. Poate fi Cache, poate fi XML, JSON etc.
Cum să rezolv problema modului de actualizare menționată anterior? Poți folosi Event, adică un eveniment, de exemplu, când un produs este vândut, poți publica un eveniment pentru a modifica modelul original de citire.
Astfel, sincronizarea devine asincronă prin mecanismul evenimentului.
În cele din urmă, această metodă este cel mai bine folosită doar pentru interogări complexe, iar interogările simple originale sunt încă preluate în baza de date relațională. De ce? Deoarece introducerea unei noi tehnologii necesită un preț, cum ar fi pașii de mutație sincronă și mecanismele evenimentelor, nu putem vedea doar avantajele noilor tehnologii, nu și dezavantajele.
|
Postat pe 04.05.2020 09:58:50
|
|
|
|
