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?

arhivează

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:

  1. 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.
  2. 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.

Putem aplica acest lucru și altor variabile în afara timpului, cum ar fi un articol dintr-un magazin, un simbol stoc sau o locație geografică, dacă preferăm să ne arhivăm datele în afara timpului. De exemplu, datele geografice se pot schimba în timp (de multe ori perioade lungi de timp) și alimentarea datelor în scopul arhivării și scalării în funcție de regiune poate fi mai adecvată. Simbolurile de acțiuni oferă, de asemenea, un alt exemplu în acest sens: oamenii se pot abona doar la câteva simboluri și acest lucru poate fi scalat mai devreme ca fluxuri separate din diferite tabele sau baze de date. Arhivarea datelor devine mai ușoară, deoarece fiecare simbol este delimitat de altele, iar rapoartele generează mai repede pentru utilizator.

Fluxurile noastre de date rezolvă o posibilă problemă de scalare și soluționează problema arhivării datelor istorice care ar putea fi necesare pentru accesarea clienților.

Obținerea de date semnificative

Este posibil să stocăm date pe care nu le putem arhiva sau că interogarea și utilizarea aplicației ne limitează capacitatea de a migra date. Este posibil, de asemenea, să putem arhiva date, dar constatăm că acest lucru adaugă limitări, precum limitări de performanță sau limitări de stocare. În aceste situații, putem evalua folosind rezumate de date prin derivarea datelor pentru a reduce cantitatea de date stocate. Luați în considerare un exemplu cu date despre împrumuturi în care păstrăm întregul istoric al împrumuturilor și cum putem rezuma aceste date în moduri semnificative pentru clienții noștri. Să presupunem că preocuparea clientului nostru implică numărul total de plăți necesare pentru un împrumut, numărul total de plăți care au avut loc în prezent, plățile întârziate și anticipate și seria curentă de plăți. Imaginea de mai jos cu o structură de tabel este un exemplu în acest sens care rezumă datele despre împrumut:

În imaginea de mai sus, vedem un tabel care stochează datele de împrumut derivate din datele istorice. Acest lucru permite actualizări, dacă se dorește, și reduce spațiul necesar pentru stocarea informațiilor.

În raport cu ceea ce are nevoie clientul nostru, acesta poate oferi un rezumat semnificativ care elimină nevoia noastră de a stoca informații despre dată și oră pe plăți. Folosirea instrumentelor derivate de date ne poate economisi timp, cu condiția să știm ce vor să solicite clienții noștri și să nu eliminăm nimic din ceea ce consideră semnificativ. Dacă clienții noștri doresc informații detaliate, este posibil să fim limitați cu această tehnică și design pentru scară, cum ar fi utilizarea unei combinații de numere de împrumut pentru scară în exemplul de mai sus.

Regula 80-20 pentru arhivarea datelor

În majoritatea mediilor de date, vedem o distribuție Pareto de date pe care clienții o interogă în cazul în care distribuția poate fi similară cu regula 80-20 sau o altă distribuție: majoritatea interogărilor se vor derula împotriva minorității de date. Datele istorice tind să solicite mai puține interogări, în general, deși există unele excepții. Dacă suntem limitați să ne scalăm datele de la început pentru a ajuta la arhivarea automată și ne confruntăm cu limitări de resurse, avem alte opțiuni pentru a ne proiecta datele, având în vedere frecvența accesului.

  1. Vom folosi tehnici de economisire a resurselor cu date pe care clienții nu le interogă des, cum ar fi compresiile de rânduri sau pagini, indexuri de stocare a coloanelor grupate (versiuni ulterioare ale SQL Server) sau rezumate de date.
  2. Dacă avem doar bugetul pentru mai puține servere, vom scala datele cu acces mai redus la serverele cu resurse mai puține, păstrând în același timp datele cu acces înalt pe serverele cu mai multe resurse.
  3. În cele din urmă, în situațiile în care suntem foarte restricționați de resurse, putem folosi tehnici de restaurare a copiilor de rezervă pentru interogare, cum ar fi păstrarea datelor vechi pe copiile de rezervă copiind datele rapid într-o bază de date, făcând copie de rezervă a bazei de date și păstrându-le în dosar pentru restaurare . Deoarece acest lucru va încetini interogarea dacă datele sunt necesare, deoarece datele trebuie mai întâi restaurate, vom folosi această opțiune numai în medii în care ne confruntăm cu limitări semnificative ale resurselor. Exemplul de mai jos cu comentarii arată pașii acestui proces folosind un tabel de date care este salvat și restaurat de o fereastră de timp.