Problema Poliglotului: rezolvarea paradoxului bazei de date ‘dreapta’

(Leszek Glasner/)

persistența poliglotă, introdusă pentru prima dată în 2011, este acum aproape drept canonic în ea. Deci, ceea ce am de spus poate veni peste ca blasfemie.

majoritatea organizațiilor de astăzi au adoptat conceptul de persistență poliglotă — implementând o varietate de tehnologii diferite de stocare a datelor bazate pe varietatea de moduri în care interogă, analizează și implementează datele lor. Și creșterea și omniprezența magazinelor de date cheie / valoare, grafic, serii de timp și JSON a oferit dezvoltatorilor opțiuni abundente pentru a alege instrumentul de date potrivit pentru jobul potrivit.

dar cererile pentru noi, ca dezvoltatori, au evoluat rapid și cred că persistența Poliglotului se va lupta rapid pentru a ține pasul. Sau, poate, aceasta este deja realitatea cu care te confrunți astăzi. De ce? Deoarece sarcina pe care o avem este descurajantă, iar echipele de dezvoltare sunt deja întinse.

diversitatea bazelor de date

trebuie să fim experți într-un spectru larg de tehnologii de baze de date, fiecare cu propriile limbaje de interogare. Avem nevoie ca aplicațiile noastre să ofere rezultate eficiente într-un număr tot mai mare de cazuri de utilizare. Și ni se cere să construim și să gestionăm sute crescând la mii de aplicații bazate pe date diverse care necesită o varietate de modele de date și implementări. Vă puteți imagina stăpânirea și menținerea unei alte tehnologii sau a unui limbaj de interogare? Ce zici de încă cinci? Încă zece?

Software-ul mănâncă lumea, eforturile noastre de dezvoltare vor crește doar, timpul și costurile pentru integrarea mai multor magazine de date sunt de neconceput, iar dezvoltatorii au nevoie disperată să se concentreze pe un set finit de tehnologii de baze de date.

mai important, cazurile de Utilizare cresc în sofisticare și ceea ce vom cere datelor noastre va necesita utilizarea mai multor modele de date, poate chiar instantaneu. Construirea de soluții în codul aplicației pentru a calcula interogările nu este durabilă sau scalabilă. Cred că este timpul ca organizațiile să caute abordări hibride care să le permită atât să-și simplifice portofoliul tehnologic, cât și să aibă flexibilitatea de a alege modelul de date potrivit pentru locul de muncă potrivit.

explorarea modelelor de date

am constatat că este util să înțelegem ce modele de date funcționează bine pentru diferite utilizări și modul în care acestea pot fi combinate.

baze de date de documente JSON

JSON este foarte versatil pentru date nestructurate și structurate. Natura recursivă a JSON permite încorporarea subdocumentelor și a listelor de lungime variabilă. În plus, puteți stoca chiar și rândurile unui tabel ca documente JSON, iar magazinele de date moderne sunt atât de bune la comprimarea datelor încât nu există în esență nici o memorie deasupra capului în comparație cu bazele de date relaționale. Pentru datele structurate, validarea schemei poate fi implementată după cum este necesar folosind un API HTTP extensibil.

baze de date grafice

bazele de date grafice sunt modele de date bune pentru relații. În multe cazuri din lumea reală, un grafic este un model de date foarte natural. Captează relațiile și poate conține informații despre etichetă cu fiecare margine și cu fiecare vârf. Documentele JSON sunt o potrivire naturală pentru a stoca acest tip de date de vârf și margine.

o bază de date grafic este deosebit de bun pentru interogări „graphy”. Lucrul crucial aici este că limbajul de interogare trebuie să implementeze rutine precum” calea cea mai scurtă „și” traversarea graficului”, capacitatea fundamentală pentru acestea este de a accesa rapid lista tuturor marginilor de ieșire sau de intrare ale unui nod.

baze de date Multi-Model

o bază de date multi-model combină capabilitățile bazelor de date document, cheie/valoare și grafic. Vă permite să alegeți diferite modele de date cu cheltuieli mai puțin operaționale. Având mai multe modele de date disponibile într-un singur motor de baze de date, atenuează unele dintre provocările utilizării diferitelor modele de date în același timp, deoarece înseamnă mai puține cheltuieli operaționale și mai puține sincronizări de date și, prin urmare, permite un salt uriaș în flexibilitatea modelării datelor.

aveți brusc opțiunea de a păstra datele conexe împreună în același magazin de date, chiar dacă are nevoie de modele de date diferite. Posibilitatea de a amesteca diferitele modele de date într-o singură interogare crește opțiunile pentru proiectarea aplicațiilor și optimizări de performanță. Și dacă alegeți să împărțiți stratul de persistență în mai multe instanțe de baze de date diferite (chiar dacă utilizează același model de date), aveți în continuare avantajul de a trebui să implementați o singură tehnologie. În plus, este prevenită blocarea modelului de date.

soluția poliglotă

persistența Poliglotului a fost acceptată deoarece ne-a permis să evităm compromiterea unei tehnologii de baze de date monolitice. Am înțeles că persistența Poliglotului a avut un cost în complexitate, un cost pentru performanță și un cost pentru consistență și disponibilitate pe măsură ce clusterele au crescut din ce în ce mai mari. Dar majoritatea, dacă nu toți, am simțit că beneficiile flexibilității modelului de date au depășit cu mult aceste costuri, deoarece o bază de date monolitică nu ar exista niciodată și nu va exista niciodată pentru a aborda toate sau chiar majoritatea cerințelor și cazurilor de utilizare.

astăzi, este clar că avem nevoie de beneficiile persistenței Poliglotului fără costuri. Trebuie să avem flexibilitatea de a construi aplicații de înaltă performanță care să se scaleze orizontal și să utilizeze o varietate de modele de date. Avem nevoie de limbi de interogare care ne permit să interogăm nativ și pe diferite modele de date. Avem nevoie de baze de date care să ne ofere libertatea și flexibilitatea de a utiliza diferite modele de date în moduri unice, pe măsură ce proiectele noastre evoluează inevitabil.

pentru multe organizații avansate, este deja obișnuit să se utilizeze o bază de date grafică mică într-o parte a unui proiect, o implementare cheie/valoare mare pentru alta sau o combinație de modele grafic, cheie/valoare și document (JSON) pentru alta.

versatilitatea datelor

luați în considerare un set de date complex ca cel pentru o flotă de aeronave formată din mai multe aeronave, fiecare constând din mai multe milioane de părți, care formează subcomponente, apoi componente mai mari și mai mici, toate acestea se încadrează într-o ierarhie de „articole.”

pentru o întreținere optimă a flotei, organizația trebuie să stocheze o varietate de date la diferite niveluri ale ierarhiei, de ex. nume de piese sau componente, numere de serie, informații despre producător, intervale de întreținere, date de întreținere, informații despre subcontractanți, linkuri către manuale și documentație, persoane de contact, informații despre garanție și contract de service etc. Acest tip de ierarhie de date este o potrivire naturală clară pentru o bază de date grafică, deoarece surprinde relațiile dintre diferite puncte de date, inclusiv informații despre fiecare margine și vârf. Dar este o bază de date grafică ideală pentru a răspunde eficient întrebărilor cheie din partea echipei de întreținere a flotei?

o bază de date grafic funcționează bine pentru întrebarea: „Care sunt toate părțile dintr-o componentă dată?”Și ar putea ajuta la răspunsul la întrebarea:” având în vedere partea a ruptă, care este cea mai mică componentă a aeronavei care conține piesa și pentru care există o procedură de întreținere?”Dar o bază de date grafică ar fi oarecum inutilă, cu o întrebare obișnuită, cum ar fi „Ce părți ale acestei aeronave au nevoie de întreținere săptămâna viitoare?”deoarece structura graficului nu se potrivește interogării.

cu toate acestea, dacă datele grafice ar putea fi stocate ca documente JSON, asociind date arbitrare cu vârfuri și margini, această întrebare ar putea fi ușor de răspuns printr-o interogare de document.

ideea este că pentru a face toate interogările din acel sistem rapid, aveți nevoie de o bază de date care poate stoca informații ca o varietate de modele de date, adesea numită bază de date multi-model. Nu ar fi frumos dacă acea bază de date grafic ar putea implementa indici secundari pe datele sale vertex?

dar apoi ar deveni în esență o bază de date multi-model. E un prim pas bun. Scenariul ideal este folosind un grafic, document, și un model de date cheie/valoare toate în același timp, pentru a găsi mai întâi piese cu întreținere datorate, se execută calculul calea cea mai scurtă de mai sus pentru fiecare dintre ele, și apoi efectuați o operațiune se alăture cu colecția de contacte pentru a adăuga informații de contact concrete. Accesarea unui model de date diferit ar trebui să schimbe doar o interogare, nu baza de date. Acolo trebuie să mergem și în curând.

acest exemplu de întreținere a flotei nu este unic sau chiar special. Vorbind cu dezvoltatorii, am constatat că este pur și simplu un analog bun pentru numărul tot mai mare și diversitatea cazurilor de utilizare pe care le văd dezvoltatorii. Din punctul meu de vedere, învățarea fundamentală a persistenței Poliglotului este necesitatea de a utiliza modelul de date potrivit pentru locul de muncă potrivit. Și cu inovații în tehnologia bazelor de date putem avea mai multe în același motor de baze de date. În caz contrar, trebuie să recunoaștem că persistența Poliglotului este propriul său compromis care ne limitează și ne va pune în cele din urmă în spatele concurenților noștri.

despre autor: Max Neunhoeffer este dezvoltator senior și arhitect la ArangoDB. În cariera sa academică, a lucrat timp de 16 ani la dezvoltarea și implementarea de noi algoritmi în algebra computerizată. Cu câțiva ani în urmă, și-a mutat accentul pe bazele de date NoSQL. La ArangoDB, el este responsabil pentru” toate lucrurile distribuite”, inclusiv implementarea pe Kubernetes, dar și rezistența, eșecul și scalabilitatea. Interesele sale particulare includ tranzacții distribuite, sisteme distribuite de auto-vindecare și tuning de performanță. Dacă zilele sale ar avea 48 de ore, ar juca golf, ar naviga, ar cânta la pian și ar inventa un nou limbaj de programare.

Tag-uri: ArangoDB, grafic, json, cheie-valoare, baza de date multi-model, poliglot, persistența poliglot, relațională

Lasă un răspuns

Adresa ta de email nu va fi publicată.