Sākumā bija faili. Vēlāk bija navigācijas datu bāzes, kuru pamatā bija strukturēti faili. Tad bija IMS un CODASYL, un apmēram pirms 40 gadiem mums bija dažas pirmās relāciju datu bāzes. 80. un 1990. gadu lielākajā daļā “datu bāze” stingri nozīmēja “relāciju datu bāzi”. SQL valdīja.
Tad, pieaugot objektorientēto programmēšanas valodu popularitātei, daži domāja, ka objektorientēto valodu un relāciju datu bāzu “pretestības neatbilstības” risinājums ir objektu kartēšana datu bāzē. Tādējādi mēs nonācām pie “objektorientētām datu bāzēm”. Smieklīgi objektu datu bāzēs bija tas, ka daudzos gadījumos tās būtībā bija parasta datu bāze ar iebūvētu objektu kartētāju. To popularitāte samazinājās, un nākamais reālais masu tirgus mēģinājums 2010. gadā bija “NoSQL”.
Uzbrukums SQL
NoSQL vienā un tajā pašā veidā uzbruka gan relāciju datu bāzēm, gan SQL. Šoreiz galvenā problēma bija tā, ka internets bija iznīcinājis 40 gadus vecās relāciju datu bāzes pārvaldības sistēmas (RDBMS) arhitektūras pamatnoteikumus. Šīs datu bāzes tika veidotas, lai saglabātu dārgo vietu diskā un mērogotu vertikāli. Tagad bija pārāk daudz lietotāju un pārāk daudz, lai viens tauku serveris varētu rīkoties. NoSQL datu bāzēs teikts, ka, ja jums būtu datu bāze bez pievienošanās, standarta vaicājuma valoda (jo SQL ieviešana prasa laiku) un datu integritāte, tad jūs varat mērogot horizontāli un apstrādāt šo sējumu. Tas atrisināja vertikālā mēroga jautājumu, bet radīja jaunas problēmas.
Paralēli šīm tiešsaistes darījumu apstrādes sistēmām (OLTP) izstrādātais bija cita veida galvenokārt relāciju datu bāze, ko sauc par tiešsaistes analītiskās apstrādes sistēmu (OLAP). Šīs datubāzes atbalstīja relāciju struktūru, bet izpildīja vaicājumus ar izpratni, ka tie atgriezīs lielu datu apjomu. Uzņēmumus 1980. un 1990. gados joprojām lielā mērā vadīja sērijveida apstrāde. Turklāt OLAP sistēmas attīstīja izstrādātāju un analītiķu spēju iztēloties un saglabāt datus kā n-dimensiju kubus. Ja jūs iztēlojaties divdimensiju masīvu un uz diviem rādītājiem balstītus uzmeklējumus, lai jūs būtībā būtu tikpat efektīvs kā nemainīgais laiks, bet pēc tam ņemiet to un pievienojiet citu vai citu dimensiju, lai jūs varētu darīt to, kas būtībā ir trīs vai vairāk faktoru meklēšana (teiksim piedāvājums, pieprasījums un konkurentu skaits) - jūs varētu efektīvāk analizēt un prognozēt lietas. To konstruēšana tomēr ir darbietilpīga un ļoti uz partijām vērsta.
Apmēram tajā pašā laikā, kad tika paplašināta NoSQL, parādījās grafu datu bāzes. Daudzas lietas pašas par sevi nav “relācijas” vai nav balstītas uz kopu teoriju un relāciju algebru, bet gan uz vecāku, bērnu vai draugu un draugu attiecībām. Klasisks piemērs ir produktu līnija līdz produkta zīmolam un modeļa komponentam. Ja vēlaties uzzināt, “kas ir mātesplatē manā klēpjdatorā”, jūs uzzināsiet, ka ražotājiem ir sarežģīti iegūt resursus, un ar zīmola vai modeļa numuru var nebūt pietiekami. Ja vēlaties uzzināt, kādas mātesplates tiek izmantotas produktu līnijā, klasiskajā (kas nav CTE vai Common Table Expression) SQL jums jāiet pa galdiem un jāizsniedz vaicājumi vairākos soļos. Sākotnēji lielākā daļa grafu datu bāzu nemaz nesabojās. Patiesībā daudzus grafu analīzes veidus var veikt, faktiski neglabājot datus kā grafiku.
NoSQL solījumi tiek pildīti un solījumi ir lauzti
NoSQL datu bāzes mērogoja daudz, daudz labāk nekā Oracle Database, DB2 vai SQL Server, kuru pamatā ir 40 gadus vecs dizains. Tomēr katram NoSQL datu bāzes tipam bija jauni ierobežojumi:
- Atslēgu vērtību krājumi: nav vienkāršākas uzmeklēšanas nekā db.get (atslēga). Tomēr lielu daļu pasaules datu un izmantošanas gadījumu nevar strukturēt šādā veidā. Turklāt mēs patiešām runājam par kešatmiņas stratēģiju. Primārā atslēga ir ātra jebkurā datu bāzē; svarīgi ir tikai tas, kas ir atmiņā. Labākajā gadījumā šīs skalas līdzinās jaucējkartei. Tomēr, ja jums ir jāveic 30 datu bāzes braucieni, lai atkal saliktu savus datus, vai veicat jebkāda veida sarežģītus vaicājumus - tas nedarbosies. Tagad tās tiek biežāk ieviestas kā kešatmiņas citu datu bāzu priekšā. (Piemērs: Redis.)
- Dokumentu datu bāzes: tās sasniedza savu popularitāti, jo izmanto JSON, un objektus ir viegli seriālizēt JSON. Pirmajām šo datu bāzu versijām nebija pievienošanās, un visas jūsu “entītijas” ievietošanai vienā milzu dokumentā bija savi trūkumi. Bez darījumu garantijām jums bija arī problēmas ar datu integritāti. Mūsdienās dažas dokumentu datubāzes atbalsta ne tik spēcīgu darījumu veidu, taču tas nav tāds pats garantijas līmenis, pie kā lielākā daļa cilvēku ir pieraduši. Arī vienkāršiem vaicājumiem tie latentuma ziņā bieži ir lēni - pat ja tie mērogojas labāk visā ziņā. (Piemēri: MongoDB, Amazon DocumentDB.)
- Kolonnu veikali: tie ir tikpat ātri kā uzmeklēšanas atslēgas vērtību veikali, un tie var uzglabāt sarežģītākas datu struktūras. Tomēr darīt kaut ko, kas izskatās kā savienojums trīs galdos (RDBMS lingo) vai trīs kolekcijās (MongoDB lingo), labākajā gadījumā ir sāpīgi. Tie ir patiešām lieliski laika rindu datiem (dodiet man visu, kas notika laikā no 13:00 līdz 14:00).
Un ir arī citas, ezotēriskākas NoSQL datu bāzes. Tomēr visām šīm datubāzēm kopīgs ir atbalsta trūkums kopīgām datu bāzu idiomām un tendence koncentrēties uz “īpašu mērķi”. Dažas populāras NoSQL datubāzes (piemēram, MongoDB) uzrakstīja lieliskus datu bāzes priekšpuses un ekosistēmas rīkus, kas padarīja izstrādātājus par ļoti viegli pieņemamiem, taču izstrādāja nopietnus ierobežojumus to glabāšanas motorā - nemaz nerunājot par elastības un mērogojamības ierobežojumiem.
Datu bāzes standarti joprojām ir svarīgi
Viena no lietām, kas relāciju datu bāzes padarīja dominējošu, bija tā, ka tām bija kopēja rīku ekosistēma. Pirmkārt, bija SQL. Lai gan dialekti varētu būt dažādi - kā izstrādātājam vai analītiķim, ja pārejāt no SQL Server 6.5 uz Oracle 7, iespējams, jums būs jālabo vaicājumi un jāizmanto “(+)” ārējiem savienojumiem, taču vienkāršie darbi strādāja un smagie materiāli bija samērā viegli tulkot.
Otrkārt, jums bija ODBC un vēlāk arī JDBC. Gandrīz jebkurš rīks, kas varētu izveidot savienojumu ar vienu RDBMS (ja vien tas nav īpaši izveidots, lai pārvaldītu šo RDBMS), varētu izveidot savienojumu ar jebkuru citu RDBMS. Ir daudz cilvēku, kas katru dienu izveido savienojumu ar RDBMS un iesūc datus programmā Excel, lai tos analizētu. Es neatsaucos uz Tableau vai kādu no simtiem citu rīku; Es runāju par “mātes kuģi”, Excel.
NoSQL atcēla standartus. MongoDB neizmanto SQL kā primāro valodu. Kad MongoDB tuvākais konkurents Couchbase meklēja vaicājumu valodu, lai aizstātu Java balstīto mapreduce sistēmu, viņi izveidoja savu SQL dialektu.
Standarti ir svarīgi neatkarīgi no tā, vai tie atbalsta rīku ekosistēmu, vai arī tāpēc, ka daudzi cilvēki, kas vaicā datubāzēs, nav izstrādātāji - un viņi zina SQL.
GraphQL un valsts vadības pieaugums
Jūs zināt, kam ir divi īkšķi un kurš vienkārši vēlas, lai viņa lietotnes stāvoklis nokļūtu datu bāzē, un vai tas ir vienaldzīgi? Šis puisis. Un izrādās visa izstrādātāju paaudze. GraphQL - kam nav nekāda sakara ar diagrammu datu bāzēm - jūsu objekta diagrammu glabā pamatā esošajā datu veikalā. Tas atbrīvo izstrādātāju no raizēm par šo problēmu.
Iepriekšējs mēģinājums bija objektu-relāciju kartēšanas rīki vai ORM, piemēram, hibernāts. Viņi paņēma objektu un būtībā to pārvērta par SQL, pamatojoties uz objekta-tabulas kartēšanas iestatījumu. Daudzas no dažām pirmajām paaudzēm bija grūti konfigurējamas. Turklāt mēs bijām uz mācīšanās līknes.
Lielākā daļa GraphQL ieviešanu darbojas ar objektu-relāciju kartēšanas rīkiem, piemēram, Sequelize vai TypeORM. Tā vietā, lai visā kodā nopludinātu valsts pārvaldības problēmas, labi strukturēta GraphQL ieviešana un API rakstīs un atgriezīs attiecīgos datus, kad jūsu objekta diagrammā notiks izmaiņas. Kas patiesībā lietojumprogrammas līmenī rūpējas par to, kā dati tiek glabāti?
Viens no objektorientēto un NoSQL datu bāzu pamatiem bija tas, ka lietojumprogrammu izstrādātājam bija jāapzinās sarežģītība, kā dati tiek glabāti datu bāzē. Protams, izstrādātājiem to bija grūti apgūt ar jaunākām tehnoloģijām, taču tas vairs nav grūti. Tā kā GraphQL šīs problēmas pilnībā novērš.
Ievadiet NewSQL vai sadalīto SQL
Google bija datu bāzes problēma, un viņš uzrakstīja darbu un vēlāk ieviešanu ar nosaukumu “Atslēga”, kurā aprakstīts, kā darbosies globāli izplatīta relāciju datu bāze. Uzgriežņu atslēga izraisīja jaunu inovāciju vilni relāciju datu bāzu tehnoloģijā. Jums faktiski varētu būt relāciju datu bāze, un, ja nepieciešams, to varētu mērogot ne tikai ar drupām, bet arī visā pasaulē. Un mēs runājam par mērogu mūsdienu izpratnē, nevis par bieži vilšanos un vienmēr sarežģītu RAC / Streams / GoldenGate veidu.
Tātad priekšstats par “objektu uzglabāšanu” relāciju sistēmā bija nepareizs. Ko darīt, ja galvenā problēma ar relāciju datu bāzēm bija aizmugure, nevis priekšējā daļa? Šī ir tā dēvēto “NewSQL” jeb pareizāk “izplatīto SQL” datu bāzu ideja. Ideja ir apvienot mācības NoSQL krātuvē un Google Spanner ideju ar nobriedušu, atvērta pirmkoda RDBMS priekšgalu, piemēram, PostgreSQL vai MySQL / MariaDB.
Ko tas nozīmē? Tas nozīmē, ka jūs varat saņemt savu kūku un arī to ēst. Tas nozīmē, ka jums var būt vairāki mezgli un mērogot horizontāli - tostarp visās mākoņu pieejamības zonās. Tas nozīmē, ka jums var būt vairāki datu centri vai mākoņa ģeogrāfiskie reģioni - ar vienu datu bāzi. Tas nozīmē, ka jums var būt patiesa uzticamība - datu bāzes kopa, kas nekad nemazinās, ciktāl tas attiecas uz lietotājiem.
Tikmēr visa SQL ekosistēma joprojām darbojas! To var izdarīt, nepārbūvējot visu IT infrastruktūru. Lai gan jūs, iespējams, neesat spēlējis savu tradicionālo RDBMS “izvilkšanai un nomaiņai”, lielākā daļa uzņēmumu nemēģina izmantot vairāk Oracle. Un pats labākais, jūs joprojām varat izmantot SQL un visus savus rīkus gan mākonī, gan visā pasaulē.
