Cum se arhivează datele SQL Server având în vedere scala

Gestionăm datele într-un mediu în creștere, în care clienții noștri interogă unele dintre datele noastre și, uneori, vor interoga datele din trecut. Nu avem un mediu care să scale și știm că trebuie să arhivăm unele dintre datele noastre într-un mod care să le permită clienților să le acceseze, dar, de asemenea, nu interferează cu datele actuale, clienții sunt mai interesați de interogare. Cu datele actuale din mediul nostru și cu noile seturi de date pe care le vom folosi în viitor, care sunt câteva modalități prin care ne putem arhiva și scala mediul nostru?

Prezentare generală

Cu seturi mari de date, scala și arhivarea datelor pot funcționa împreună, întrucât gândirea la scară poate ajuta ulterior la arhivarea datelor vechi de care utilizatorii accesează sau au nevoie rareori. Din acest motiv, vom discuta despre arhivarea datelor într-un context care include scalarea datelor inițial, deoarece mediile cu nevoi de arhivare tind să fie medii de date mai mari.

Începe cu sfârșitul în minte

Una dintre cele mai populare tehnici de arhivare cu date care include informații despre dată și oră este arhivarea datelor printr-o fereastră de timp, cum ar fi o săptămână, o lună sau un an. Acesta oferă un exemplu simplu de proiectare cu un scop în minte din partea arhitecturală, deoarece acest lucru devine mult mai ușor de făcut dacă aplicația noastră ia în considerare timpul în care se întâmplă o interogare sau un proces. Putem scala de la început folosind timpul, mai degrabă decât migrarea ulterioară a datelor dintr-o bază de date. Luați în considerare următoarele două scenarii ca o comparație:

Scenariul 1: adăugăm, transformăm și alimentăm date în rapoarte dintr-o bază de date sau dintr-un set de baze de date. Aplicația și rapoartele indică aceste baze de date. Când trebuie să arhivăm date, migrăm date sub formă de inserții și le ștergem din aceste baze de date într-o altă bază de date în care stocăm date istorice. Dacă un utilizator are nevoie să acceseze date istorice, interogările se execută în raport cu acest mediu istoric.
Scenariul 2: adăugăm, transformăm și alimentăm date în rapoarte din mai multe baze de date (sau tabele) create de fereastra de timp din aplicația în care datele sunt primite (sau necesare pentru clienți) și stocate pentru acel moment, cum ar fi toate datele pentru 2017 fiind stocat doar într-o bază de date 2017. Deoarece există o fereastră de timp, bazele de date nu cresc ca în Scenariul 1. Fereastra de timp pentru această bază de date (sau structura tabelului) determină ce date sunt stocate și nu este necesară arhivarea, deoarece putem pur și simplu copia de rezervă și restaurarea bazei de date pe un alt server dacă trebuie să migram datele.

Aceasta este o tehnică populară pentru stocarea datelor - datele provin dintr-o aplicație sau strat ETL într-o bază de date. Pe măsură ce baza de date crește și trebuie să arhivăm datele, migrăm datele în altă parte către alte baze de date de pe alte servere.

Acest lucru este proiectat pentru scalare imediat. Datele provin dintr-o aplicație sau strat ETL și intră într-o bază de date concepută pentru acea partiție de date, cum ar fi anul în care au provenit datele sau o cheie partiționată, cum ar fi o zonă geografică. În afara mutării bazelor de date, nu este necesară arhivarea.

Fluxuri de date

Când luăm în considerare utilizarea finală a datelor noastre, este posibil să descoperim că modelarea datelor noastre din fluxuri ne va ajuta clienții și ne va ajuta cu amploarea. Imaginați-vă un raport în care oamenii selectează dintr-un meniu derulant intervalul de timp în care doresc să interogheze date - fie în ani, luni sau zile. În culise, interogarea determină ce bază de date sau baze de date sunt utilizate (sau tabele, dacă facem o scalare după tabele). În acest caz, tratăm timpul ca variabila care determină fluxul, cum ar fi 2017, fiind fluxul de date pentru toți din anul 2017.