NoSQL vs SQL 2017. aastal

Jõudsin siin olevale pildile ja see pani mind naeratama. Mitte andmebaasi valimise eeldatava keerukuse tõttu, vaid reaalsusega, millega see vooskeem kajastab andmebaasimaailma olukorda 2017. aastal. Muidugi on mis tahes andmebaasi haldamine, mille lõpuks tootmises valite, täiesti uue keerukusastme.

Olen töötanud hajutatud süsteemide alal viimased 10+ aastat. Töötas Cassandra kallal enne, kui see oli avatud lähtekoodiga või kutsuti isegi Cassandraks, ja töötas HBase'is Facebookis hunniku kasutusjuhtude jaoks, milles oli 100 petabaiti andmeid. Kõik see algas perioodil, enne kui NoSQL oli asi, ja enne, kui inimesed lugesid NoSQL-i ja SQL-i, kuni nende silmamunad välja kukkusid. Nii tahtsin oma mõtteid jagada.

Algselt olid domineerivad andmebaasid RDBMS. Vaja skaleerida? Hankige kohvimasin. See oli vanus, mil populaarseks said DB2, Oracle, SQLServer, MySQL, Postgres ja teised. Varsti sai selgemaks, et RDBMS-ide puhtalt suurendamine suurema lihamasina hankimisega ei lahenda nende andmete säilitamise probleemi - andmeid, mis hakkasid lagunema nagu tuletõrjevoolik. Ja isegi kui see kuidagi toimiks, oleks see ülemäära kallis.

Lahenduse loomulik järgmine samm oli ehitada üles hajutatud SQL-andmebaasid. Ühtse sõlme SQL andmebaas jagati mitmeks loogiliseks andmebaasiks, andmeid hajutati rakenduse kihis ja replikatsiooni / HA-d haldas operatsioonide meeskond. See tähendas loobumist RDBMSi puhtalt „relatsioonilistest” aspektidest - näiteks liitumised, võõrad võtmed jne ja skeemi deormaliseerimine. See lahendus on toimiv, kuigi ilmselgelt väga keeruline (üldiselt rakenduste arendusmeeskondadest operatiivmeeskondadeni).

Kui järele mõelda, on ülaltoodud lahendus väga korratav - eriti kui andmebaasi kasutajad on vaimselt valmistunud loobuma RDBMS-i suhtelistest aspektidest. Lahendust saab väljendada väga konkreetselt:

  1. kaudselt varjutatud andmed, et võimaldada skaleerimist
  2. rikete ületamiseks korrake andmeid automaatselt
  3. sujuvalt käsitleda sõlme tõrkeid HA pakkumisel (kasutades koopiaid)
  4. võimaldavad lihtsat viisi sharding, päringute, replikatsioonide väljendamiseks

Ülaltoodud lahenduse pakkumiseks loodi andmebaasid NoSQL. Kuid esimese põlvkonna andmebaasid keskendusid palju keelte jaoks, mida kasutatakse varjestamise ja päringute esitamiseks, ning mitte piisavalt tootlikkuse klassi stabiilsusele, järjepidevusele ja andmete replikatsiooni / HA tagatistele. Siit leiate Vikipeedia määratluse NoSQL kohta:

NoSQL (viitab algselt „mitte SQL-i” või „mitterelatsioonilisele”) [1] andmebaas pakub andmete säilitamise ja hankimise mehhanismi, mis on modelleeritud muul viisil kui relatsiooniandmebaasides kasutatavad tabelisuhted.

Nii sai kiiresti fookuseks see, kuidas SQL kui keel polnud ideaalne ja kuidas oli vaja teistsugust programmilist API koos mõistetega nagu baitvõtmed, veerud, veergude perekonnad jne. Järjepidevus, replikatsioonid ja HA-garantiid jäid kuidagi segadusse , mille tulemuseks on andmebaasid, mis pole tootmissüsteemi süsteemide jaoks eriti töökindlad. Ja sellele haavale soola hõõrumiseks liigitatakse Redis millegipärast NoSQL-i andmebaasiks - mõtlen seda alati kui Memcache ++. Tänu kõigele sellele on andmebaasiruum uskumatult keeruline, kuna lõppkasutaja uurib, millist süsteemi kasutada.

Selle asemel, et NoSQL oleks mitte-SQL-andmebaasid, peaks keskenduma hoopis mitterelatsioonilistele SQL-andmebaasidele (jah, nimi ei kõla liiga lahedalt). Inimesed mõistsid, et päringu paradigma muutmine ei pidanud olema põhirõhk. Nii ehitati hunnik andmebaase või täiustati neid SQL-laadse päringkeelega ja mõiste NoSQL simple sai sõnaks “Not only SQL”. Probleem lahendatud? Mitte päris - järjepidevuse, kordamise ja HA tagatistega ikka veel ei tegeleta.

Nii jõuame tänapäevani, kui hajutatud (või mõnel juhul suurendatakse) SQL-andmebaasid on missioonikriitiliste OLTP-rakenduste käitamiseks kõige usaldusväärsemad. NoSQL andmebaase (ja Redisi) kasutatakse kõrvuti pidevalt kasvavate andmekogude või kiirema andmetele juurdepääsuga. See muudab tootmises oleva andmeinfrastruktuuri töötamise väga raskeks, kuna süsteeme on mitu ja andmeid tuleb nende vahel sünkroonida. Ja kui sõidate mitme piirkonna / alalisvoolu piirkondades või pilvekeskkonnas, on „väga raske” suur alahindamine.

Uuendus: üks lugejatest küsis, kuidas klastritud SQL-lahendus sellesse kõige paremini sobib. See on suurepärane küsimus.
Siin on link, mis kirjeldab klastritud SQL-i lahendust: https://www.brentozar.com/archive/2012/02/introduction-sql-server-clusters/
Ülaltoodud lingi jaotis selle kohta, mis klastrisse ei aita, on asjakohane.
1. Klastrimine ei paranda teie toimivust. Nii et see ei ole ulatuse vähendamise lahendus, vaid HA-ga laiendamise lahendus
2. Rühmitamine ei säästa ruumi ega vaeva varundamiseks ega hoolduseks. Nii et see ei muuda asju operatiivselt lihtsaks
3. Rühmitamine ei aita teil ka teie lugemist mõõta. Jällegi, mitte ulatuse vähendamise lahendus.
4. Klastrid ei anna teile 100% tööaega. Nii et see on kõrgem HA tase, kuid tal on siiski käsitsi bitti.
Seetõttu kuulub klastrimine kategooriasse „mastaapimine”. Klastrimist saab kombineerida käsitsi varjutamisega, et saavutada ulatus ja HA, kuid selle ehitamine on äärmiselt keeruline lahendus.

Kas teile meeldiks kuulda inimestest, kes jooksevad või mõtlevad tootmises teravdatud SQL-i ja / või NoSQL-i käiku - millised on teie mõtted? Milliste probleemidega silmitsi seisad?