Pradžioje buvo bylos. Vėliau buvo navigacinės duomenų bazės, pagrįstos struktūriniais failais. Tada buvo IMS ir CODASYL, ir maždaug prieš 40 metų mes turėjome keletą pirmųjų reliacinių duomenų bazių. Didžiąją dalį devintojo ir dešimto dešimtmečių „duomenų bazė“ griežtai reiškė „reliacinę duomenų bazę“. SQL valdė.
Tada vis labiau populiarėjant į objektą orientuotoms programavimo kalboms, kai kurie manė, kad objektyvių kalbų ir reliacinių duomenų bazių „impedanso neatitikimo“ sprendimas yra objektų žemėlapis duomenų bazėje. Taigi mes sukūrėme „objektines duomenų bazes“. Juokingiausia objektų duomenų bazėse buvo tai, kad daugeliu atvejų jos iš esmės buvo įprasta duomenų bazė su įmontuotu objekto žemėlapiu. Jų populiarumas išblėso, o kitas tikras masinės rinkos bandymas buvo „NoSQL“ 2010-aisiais.
Ataka prieš SQL
„NoSQL“ tuo pačiu būdu atakavo ir reliacines duomenų bazes, ir SQL. Pagrindinė problema šįkart buvo ta, kad internetas sugriovė pagrindinę 40 metų senumo reliacinių duomenų bazių valdymo sistemos (RDBMS) architektūros prielaidą. Šios duomenų bazės buvo skirtos tausoti brangųjį diską ir vertikaliai mastelį. Dabar buvo per daug vartotojų ir per daug, kad vienas riebus serveris galėtų tvarkyti. „NoSQL“ duomenų bazėse sakoma, kad jei turėtumėte duomenų bazę be prisijungimų, be standartinės užklausos kalbos (nes SQL diegimas užima laiko) ir neturite duomenų vientisumo, galite mastelį keisti horizontaliai ir tvarkyti tą tūrį. Tai išsprendė vertikalaus masto klausimą, tačiau iškėlė naujų problemų.
Kartu su šiomis internetinių operacijų apdorojimo sistemomis (OLTP) sukurta buvo dar viena daugiausia reliacinių duomenų bazių rūšis, vadinama internetine analitinio apdorojimo sistema (OLAP). Šios duomenų bazės palaikė santykių struktūrą, tačiau vykdė užklausas suprasdamos, kad jos grąžins didžiulius duomenų kiekius. Devintojo ir dešimto dešimtmečių verslą vis dar lėmė paketinis apdorojimas. Be to, OLAP sistemos sukūrė kūrėjams ir analitikams galimybę įsivaizduoti ir saugoti duomenis kaip n matmenų kubus. Jei įsivaizduojate dvimatį masyvą ir peržiūras, pagrįstas dviem rodikliais, kad iš esmės būtų toks pat efektyvus kaip pastovus laikas, bet tada paimkite tai ir pridėkite kitą ar kitą dimensiją, kad galėtumėte atlikti tai, kas iš esmės yra trijų ar daugiau veiksnių paieška (tarkim, pasiūla, paklausa ir konkurentų skaičius) - galėtumėte efektyviau analizuoti ir prognozuoti dalykus. Tačiau jų sukūrimas yra sunkus ir labai į pastangas orientuotas.
Maždaug tuo pačiu metu, kai buvo išplėsta NoSQL, atsirado grafikų duomenų bazės. Daugelis dalykų savaime nėra „santykiniai“ arba nėra pagrįsti aibės teorija ir santykių algebra, o tėvo, vaiko ar draugo draugo santykiais. Klasikinis pavyzdys yra produktų linija nuo prekės ženklo iki modelio ir jo komponentų. Jei norite sužinoti „kokia pagrindinė plokštė yra mano nešiojamajame kompiuteryje“, sužinosite, kad gamintojai apsirūpino sudėtingais šaltiniais ir prekės ženklo ar modelio numerio gali nepakakti. Jei norite sužinoti, kokios visos pagrindinės plokštės naudojamos produktų linijoje, klasikinėje (ne CTE arba „Common Table Expression“) SQL versijoje turite vaikščioti po lenteles ir pateikti užklausas keliais žingsniais. Iš pradžių dauguma grafikų duomenų bazių visiškai nesuskaldė. Tiesą sakant, daugelį grafikų analizės tipų galima atlikti ir neišsaugant duomenų kaip grafiko.
„NoSQL“ pažadai įvykdyti ir pažadai neįvykdyti
„NoSQL“ duomenų bazių mastas buvo daug, daug geresnis nei „Oracle Database“, DB2 ar SQL Server, kurie visi remiasi 40 metų senumo dizainu. Tačiau kiekvienam „NoSQL“ duomenų bazės tipui buvo nustatyti nauji apribojimai:
- Pagrindinės vertės saugyklos: nėra paprastesnės paieškos nei db.get (raktas). Tačiau daugelio pasaulio duomenų ir naudojimo atvejų negalima taip struktūrizuoti. Be to, mes tikrai kalbame apie talpyklos strategiją. Pagrindinių raktų paieška yra greita bet kurioje duomenų bazėje; svarbu tik tai, kas yra atmintyje. Geriausiu atveju šios skalės yra kaip maišos žemėlapis. Tačiau, jei jūs turite atlikti 30 duomenų bazės kelionių, kad vėl sukurtumėte duomenis, arba atlikite bet kokią sudėtingą užklausą - tai neveiks. Dabar jie dažniau įgyvendinami kaip talpyklos prieš kitas duomenų bazes. (Pavyzdys: Redis.)
- Dokumentų duomenų bazės: šios pasiekė savo populiarumą, nes naudoja JSON, o objektus lengva serijizuoti į JSON. Pirmosiose šių duomenų bazių versijose nebuvo jokių prisijungimų, o jūsų viso „subjekto“ įtraukimas į vieną milžinišką dokumentą turėjo savų trūkumų. Neturėdami sandorių garantijų, taip pat turėjote duomenų vientisumo problemų. Šiandien kai kurios dokumentų duomenų bazės palaiko mažiau patikimą sandorių formą, tačiau tai nėra tas pats garantijos lygis, prie kurio dauguma žmonių yra įpratę. Be to, net ir atliekant paprastas užklausas, jos vėluoja dažnai lėtai, net jei jos mastelis yra geresnis. (Pavyzdžiai: „MongoDB“, „Amazon DocumentDB“.)
- Stulpelių parduotuvės: tai yra taip pat greitai, kaip ir svarbiausios paieškos paieškos, ir jose galima saugoti sudėtingesnes duomenų struktūras. Tačiau daryti tai, kas atrodo kaip sujungimas per tris lenteles (RDBMS lingo) arba tris kolekcijas (MongoDB lingo), geriausiu atveju yra skausminga. Tai tikrai tinka laiko eilučių duomenims (duok man viską, kas nutiko nuo 13:00 iki 14:00).
Ir yra kitų, labiau ezoterinių NoSQL duomenų bazių. Tačiau visos šios duomenų bazės turi bendrą trūkumą - tai trūksta palaikymo bendroms duomenų bazių idėjoms ir tendencija sutelkti dėmesį į „specialų tikslą“. Kai kurios populiarios „NoSQL“ duomenų bazės (pvz., „MongoDB“) parašė puikias duomenų bazių sąsajas ir ekosistemos įrankius, kuriuos kūrėjams buvo labai lengva pritaikyti, tačiau sukonstravo rimtus jų saugojimo variklio apribojimus - jau nekalbant apie atsparumo ir mastelio apribojimus.
Duomenų bazių standartai vis dar yra svarbūs
Reliacinių duomenų bazių dominavimu tapo tai, kad jos turėjo bendrą įrankių ekosistemą. Pirma, buvo SQL. Nors tarmės gali būti skirtingos - kaip kūrėjas ar analitikas, jei perėjote nuo „SQL Server 6.5“ prie „Oracle 7“, gali tekti taisyti savo užklausas ir išoriniams sujungimams naudoti „(+)“, bet paprastas dalykas pavyko ir sunkus dalykas buvo gana lengvas išversti.
Antra, jūs, be kita ko, turėjote ODBC ir vėliau JDBC. Beveik bet kuris įrankis, galintis prisijungti prie vieno RDBVS (nebent jis buvo sukurtas specialiai tam RDBVS valdyti), galėjo prisijungti prie bet kurio kito RDBVS. Yra daugybė žmonių, kurie kasdien prisijungia prie RDBVS ir sugeria duomenis į „Excel“, kad galėtų juos analizuoti. Aš neturiu omenyje „Tableau“ ar kokių nors šimtų kitų įrankių; Aš kalbu apie „motinystę“, „Excel“.
„NoSQL“ atsisakė standartų. „MongoDB“ nenaudoja SQL kaip pagrindinės kalbos. Kai artimiausias „MongoDB“ konkurentas „Couchbase“ ieškojo užklausos kalbos, pakeisiančios „Java“ pagrįstą „mapreduce“ sistemą, jie sukūrė savo SQL tarmę.
Standartai yra svarbūs palaikant įrankių ekosistemą, ar todėl, kad daugybė žmonių, kurie teikia užklausas duomenų bazėms, nėra kūrėjai - ir jie žino SQL.
„GraphQL“ ir valstybės valdymo iškilimas
Jūs žinote, kas turi du nykščius ir tiesiog nori, kad jo programos būsena patektų į duomenų bazę, ir nesvarbu, kaip? Šis vaikinas. Pasirodo, visa kūrėjų karta. „GraphQL“, kuris neturi nieko bendro su grafikų duomenų bazėmis, saugo jūsų objekto grafiką pagrindiniame duomenų saugykloje. Tai atleidžia kūrėją nuo nerimo dėl šios problemos.
Ankstesnis bandymas buvo objekto-reliacijos žemėlapių įrankiai arba ORM, pvz., „Hibernate“. Jie paėmė objektą ir iš esmės pavertė jį SQL, remdamiesi objekto-lentelės atvaizdavimo sąranga. Daugelį pirmųjų kelių kartų tai buvo sunku sukonfigūruoti. Be to, mes buvome mokymosi kreivėje.
Dauguma „GraphQL“ diegimų veikia su objekto-reliacijos atvaizdavimo įrankiais, tokiais kaip „Sequelize“ arba „TypeORM“. Užuot nutekinę būsenos valdymo rūpesčius visame kode, gerai struktūrizuotas „GraphQL“ diegimas ir API parašys ir grąžins atitinkamus duomenis, kai pasikeis jūsų objekto grafikas. Kas iš tikrųjų programos lygiu rūpinasi, kaip saugomi duomenys?
Vienas iš objektyvių ir „NoSQL“ duomenų bazių pagrindų buvo tas, kad programos kūrėjas turėjo žinoti apie duomenų saugojimo duomenų bazėje subtilybes. Natūralu, kad kūrėjams tai buvo sunku įvaldyti naudojant naujesnes technologijas, tačiau tai jau nėra sunku. Nes „GraphQL“ visiškai pašalina šį rūpestį.
Įveskite NewSQL arba paskirstytą SQL
„Google“ turėjo duomenų bazės problemų ir parašė dokumentą, o vėliau - „Veržliaraktį“, kuriame aprašyta, kaip veiks visame pasaulyje paskirstyta reliacinė duomenų bazė. Veržliaraktis sukėlė naują santykių duomenų bazių technologijos naujovių bangą. Jūs iš tikrųjų galite turėti reliacinę duomenų bazę ir, jei reikia, ją išplėsti ne tik skeveldromis, bet ir visame pasaulyje. Mes kalbame apie mastą šiuolaikine prasme, o ne apie dažnai nuviliantį ir nuolat sudėtingą RAC / Stream / GoldenGate būdą.
Taigi prielaida „laikyti daiktus“ santykių sistemoje buvo klaidinga. Ką daryti, jei pagrindinė reliacinių duomenų bazių problema buvo galinė, o ne priekinė dalis? Tai yra vadinamųjų „NewSQL“ arba, teisingiau, „paskirstytų SQL“ duomenų bazių idėja. Idėja yra sujungti „NoSQL“ saugojimo žinias ir „Google“ veržliarakčio idėją su brandaus, atviro kodo, RDBMS sąsaja, pvz., „PostgreSQL“ arba „MySQL / MariaDB“.
Ką tai reiškia? Tai reiškia, kad galite ir savo pyragą valgyti. Tai reiškia, kad galite turėti kelis mazgus ir keisti mastelį horizontaliai, įskaitant visas debesies prieinamumo zonas. Tai reiškia, kad jūs galite turėti kelis duomenų centrus arba debesies geografinius regionus - su viena duomenų baze. Tai reiškia, kad galite turėti tikrą patikimumą - duomenų bazių grupę, kuri niekada nesumažėja, kiek tai susiję su vartotojais.
Tuo tarpu visa SQL ekosistema vis dar veikia! Tai galite padaryti neatstatę visos savo IT infrastruktūros. Nors galbūt nesate žaidę, norėdami „nuplėšti ir pakeisti“ savo tradicinius RDBMS, dauguma kompanijų nebando naudoti daugiau „Oracle“. Kas geriausia, vis tiek galite naudoti SQL ir visus savo įrankius tiek debesyje, tiek visame pasaulyje.
