Cum să alegi un depozit de date pentru următorul lucru nou strălucitor

Notă: Aceasta este o postare tehnică pe blog scrisă de inginerul principal Silvia Botros și a apărut pentru prima dată pe blogul Sysadvent pe 25 decembrie 2017.

Bazele de date pot fi dificile. Știi ce e mai greu? Alegând unul în primul rând. Acest lucru este o provocare, indiferent dacă vă aflați într-o companie nouă care încă își găsește produsul/piața potrivită sau într-o companie care și-a găsit publicul și pur și simplu își extinde oferta de produse.

Când construim un lucru nou, una dintre primele părți ale procesului de proiectare este ce depozite de date ar trebui să folosim și ar trebui să fie un singur sau un plural? Ar trebui să folosim magazine relaționale sau trebuie să alegem un magazin cu valori cheie? Dar opțiunile de timp? Ar trebui să presărăm și o reluare a jurnalelor distribuite?

Asa de. Mulți. Opțiuni…

Voi încerca în acest articol să descriu un proces care, sperăm, va ghida acea decizie și, acolo unde este cazul, să explic modul în care dimensiunea și maturitatea organizației dvs. pot afecta această decizie.

Cerințe de bază

Datele sunt sângele vital al oricărui produs. Chiar dacă intenționăm în proiectare să folosim mai multă tehnologie de vârf pentru a stoca starea aplicației (deoarece MySQL sau Postgres nu mai sunt „mișto”), orice alegem este încă un depozit de date și, prin urmare, necesită să aplicăm rigoare atunci când făcând selecția noastră.

Important de reținut este că nimic nu este gratuit. Toate depozitele de date vin cu compromisuri și, dacă nu sunteți explicit cu privire la compromisurile pe care le luați ca risc de afaceri, vă veți asuma riscuri necunoscute care se vor arăta în cel mai rău moment posibil.

Managerul dvs. de produs este puțin probabil să știe sau chiar să aibă nevoie să-și pese de ceea ce utilizați pentru magazinul dvs. de date, dar el va determina nevoile care micșorează lista de opțiuni. Uneori, totuși, chiar și asta are nevoie de un ghiont din partea echipei de dezvoltare. Iată o listă de lucruri pe care trebuie să le întrebați echipei de produs pentru a vă ajuta să vă dezvoltați opțiunile:

• Rata de creștere: Cum se așteaptă să se schimbe datele în sine sau accesul la acestea în timp?
• Cum va folosi echipa de facturare aceste date noi?
• Cum va folosi echipa ETL aceste date?
• Ce cerințe de precizie/coerență sunt așteptate pentru această nouă caracteristică?
• Ce interval de timp pentru această consistență este acceptabil? Este acceptabilă corecția după procesare?

Găsiți contextul care nu este spus

Alegerea depozitului de date nu este o alegere rezervată DBA sau echipei de operațiuni sau chiar doar inginerul care scrie codul.

Organizațiile mature cu o piață adresabilă cunoscută trebuie să ia o decizie din partea părților interesate din întreaga organizație.

Dacă cerințele echipei de produs se potrivesc cu o duzină de depozite de date, cum determinați cerințele care nu sunt menționate în mod explicit?

Trebuie să evidențiați cerințele nerostite cât mai curând posibil, deoarece este drumul către așteptările eșuate pe linie.

O mulțime de lucruri implicite te pot face să eșuezi în această capcană „prea multe alegeri”. Aceasta include, dar nu se limitează la:

• Liste incomplete de caracteristici
• Cerințe de performanță care nu sunt enumerate în mod explicit
• Nevoi de coerență care sunt asumate
• Rata de creștere care nu este specificată
• Nevoi de facturare sau de interogare ETL care nu sunt încă disponibile/cunoscute

Acestea sunt toate modalitățile posibile prin care o echipă de inginerie se învârte prea mult timp, verificând o listă lungă de opțiuni pentru depozitul de date, pur și simplu pentru că criteriile explicite cu care lucrează sunt prea permisive sau incomplete.

Pentru mai multe produse „greenfield”, așa cum am menționat anterior, obiectivul dvs. este flexibilitatea. Așadar, un depozit de date cu scop mai general, de calitate cunoscută, vă va ajuta să vă apropiați de un produs livrat, știind că, în continuare, este posibil să aveți nevoie să treceți la un depozit de date care este mai adaptabil la noua dvs. scară.

Fă-ți lista

Este timpul să filtrați soluțiile potențiale după lista dvs. de cerințe. Lista rezultată nu trebuie să fie mai mult de o mână de depozite de date posibile. Dacă lista de baze de date potențiale pe care le puteți utiliza este mai mult decât atât, atunci cerințele dvs. sunt prea permisive și trebuie să vă întoarceți și să aflați mai multe informații.

Pentru companiile mai tinere, mai puțin mature, cerințele depozitului de date reprezintă zona celor mai necunoscute. Este posibil să construiți un lucru nou pe care nimeni nu îl oferă încă, așa că lucruri precum dimensiunea totală a pieței adresabile și rata de creștere pot fi relativ necunoscute și greu de cuantificat.

În acest caz, ceea ce aveți nevoie este să nu vă constrângeți prea devreme pe durata de viață a noii companii, folosind un depozit de date cu un singur truc. Da, la un moment dat datele dvs. vor crește în moduri noi și neașteptate, dar ceea ce aveți nevoie acum este flexibilitate, pe măsură ce încercați să vă găsiți nișa de piață și să aflați cum va arăta creșterea datelor dvs. și ce caracteristici specifice de scalabilitate vor deveni cruciale pentru creșterea ta.

Dacă sunteți o companie mai mare, cu un număr tot mai mare de clienți plătitori, sarcina dvs. aici este să micșorați lista de opțiuni la depozitele de date pe care le aveți deja și le întrețineți. Când ai deja mulți clienți plătitori, riscul de a adăuga noi depozite de date cu care echipa ta nu este familiarizată devine mai mare și, în funcție de contextul datelor, pur și simplu inacceptabil.

Un alt lucru de reținut este ce instrumente există deja pentru depozitele de date și ce ar însemna adoptarea unuia nou în ceea ce privește munca din față pe care trebuie să o facă echipa ta. Gestionarea configurației, scripturi de backup, scripturi de recuperare a datelor, noi verificări de monitorizare, noi tablouri de bord pentru a construi și a vă familiariza. Lista costurilor operaționale ale unui nou depozit de date, indiferent de risc, nu este banală.

Alege-ți otrava

Deci, iată un secret prost păstrat pe care DBA îl păstrează. Bazele de date sunt toate groaznice la ceva. Există chiar și o întreagă teoremă despre asta. Nu doar bazele de date în sensul tradițional, ci orice tehnologie care stochează va fi oribilă într-un mod unic pentru modul în care o utilizați.

Acesta este doar un fapt al vieții pe care mai bine îl interiorizați acum. Nu, nu spun că ar trebui să evitați utilizarea vreuneia dintre aceste tehnologii, spun să vă păstrați așteptările sănătoase și să știți că TU și numai tu și echipa ta deții în cele din urmă să-ți împlinești promisiunile pe care le faci.

Ce înseamnă asta în termeni non-abstracti? Odată ce aveți o idee solidă ce depozite de date vor face parte din ceea ce construiți, ar trebui să începeți prin a cunoaște punctele slabe ale acestor depozite de date. Aceste puncte slabe includ, dar nu se limitează la:

• Funcționează bine acest depozit de date în cazul interogărilor de scanare?
• Acest depozit de date se bazează pe un protocol de bârfă pentru replicarea datelor? dacă da, cum gestionează partițiile de rețea? Câte date sunt implicate în acea bârfă?
• Acest depozit de date are un singur punct de eșec?
• Cât de maturi sunt șoferii din comunitate să vorbească cu ea sau trebuie să-ți faci singuri?
• Această listă poate fi uriașă

Gândirea la punctele slabe ale potențialelor soluții încă de pe lista dvs. ar trebui să elimine mai multe opțiuni de pe listă. Aceasta este acum realitatea care îndeplinește promisiunile înalte ale tehnologiei.

Foaie de calcul și coace!

Odată ce lista dvs. de opțiuni se reduce la o mână mică, este timpul să le puneți pe toate într-o foaie de calcul și să începeți să sapi puțin mai adânc. Aveți nevoie de o coloană de pro și o coloană de dezavantaje și, în acest moment, va trebui să petreceți ceva timp în documentația fiecărei baze de date pentru a afla detalii serioase despre cum să faceți anumite sarcini.

Dacă acestea sunt date la care vă așteptați să aveți o rată de creștere mare, trebuie să știți care dintre aceste opțiuni este mai ușor de extins. Dacă aceasta este o caracteristică care efectuează multe căutări neclare, trebuie să știți ce depozit de date poate gestiona mai bine scanările sau căutarea printr-un număr mare de rânduri și cu ce design. Ținta în această etapă este de a reduce lista la 2 sau 3 opțiuni, în mod ideal, doar prin documentație, deoarece dacă această nouă caracteristică este suficient de critică pentru succesul companiei, va trebui să le comparați pe toate trei.

De ce benchmark zici? Pentru că nu există 2 companii care utilizează același depozit de date în același mod. Pentru că uneori documentarea implică avertismente care sunt expuse doar în poveștile de război ale altor oameni.

Pentru că nimeni nu deține stabilitatea, fiabilitatea și predictibilitatea acestui depozit de date, în afară de tine.

Proiectați-vă reperul în avans. În mod ideal, configurați o instanță completă a depozitelor de date din lista dvs. cu specificații la nivel de producție și produceți date de testare care nu sunt prea mici pentru a face testarea de încărcare inutilă. Asigurați-vă că nu numai să faceți benchmark pentru „încărcare normală”, ci și să testați unele scenarii de defecțiune.

Speranța este că, prin intermediul benchmark-ului, puteți afla orice avertismente care sunt suficient de severe pentru a vă determina să revizuiți lista de opțiuni acum, nu mai târziu, când tot codul este scris și vă aflați acum în faza de exercițiu de incendiu cu mult timp. și efort depus pentru alegerea pe care ați făcut-o.

Documentați alegerea dvs

Indiferent ce faci, trebuie să documentezi și să difuzezi intern metoda prin care ai ajuns la alegerea ta și alternativele care au fost investigate pe traseul către acea decizie. Presupunând că există o arhitectură generală a modului în care va fi creată această nouă caracteristică și toate componentele sale, asigurați-vă că creați o secțiune dedicată depozitului de date care alimentează această nouă caracteristică, cu link-uri către toate punctele de referință realizate pentru a ajunge la decizia la care a ajuns echipa. .

Acest lucru nu este doar în beneficiul viitorilor noi angajați, ci și în beneficiul echipei dvs. acum. Un document pe care oamenii îl pot citi asincron și despre care să dezvolte opinii oferă o modalitate de a menține procesul decizional transparent, de a crește sentimentul de cea mai bună intenție în rândul membrilor echipei și poate aduce critici din perspective pe care nu le-ați prevăzut.

Concluzii

Acești pași nu vor duce doar la decizii bazate pe date atunci când crește oferta de afaceri, dar vor duce și la o infrastructură robustă și o abordare mai disciplinată a când și unde utilizați un domeniu în continuă creștere de tehnologii pentru a oferi valoare plății dvs. Clienți.