„NoSQL“ žinomas žodis metastazavo keletą metų. Jaudulys dėl šių greitų duomenų saugyklų buvo svaiginantis, ir mes esame tokie pat kalti, kad matėme novatorišką „NoSQL“ patrauklumą. Medaus mėnuo jau eina į pabaigą, ir laikas pradėti subalansuoti mūsų entuziazmą su kai kuriomis sunkiomis tiesomis.
Nesupraskite mūsų neteisingai. Mes vis dar bandome išbandyti naujausią eksperimentą, kaip sukurti paprastą duomenų saugojimo mechanizmą. Mes vis dar randame didelę vertę MongoDB, CouchDB, Cassandra, Riak ir kituose NoSQL išskirtiniuose. Mes vis dar planuojame mesti kai kuriuos patikimiausius duomenis į šiuos kodų šūsnius, nes jie kiekvieną dieną auga geriau ir labiau išbandomi mūšyje.
[Taip pat: NoSQL išskirtiniai: naujos duomenų bazės naujoms programoms | Pirmas žvilgsnis: „Oracle NoSQL“ duomenų bazė | „Daily“ naujienlaiškyje kiekvieną dieną gaukite svarbiausių istorijų santrauką. ]
Bet mes pradedame jausti šlifavimą, nes „NoSQL“ sistemos toli gražu nėra tobulos ir dažnai trinasi neteisingai. Protingiausi kūrėjai tai žinojo nuo pat pradžių. Jie nesudegino SQL vadovų ir nesiuntė nemalonių savo kadaise atsidavusio SQL pardavėjo pardavėjams. Ne, protingi „NoSQL“ kūrėjai tiesiog pažymėjo, kad „NoSQL“ reiškia „ne tik SQL“. Jei masės neteisingai aiškino santrumpą, tai buvo jų problema.
Taigi šis didelių ir mažų rankenų sąrašas yra bandymas užfiksuoti šį faktą ir išvalyti orą. Jis skirtas viską ištaisyti dabar, kad galėtume geriau atlikti kompromisų ir kompromisų supratimą.
„NoSQL“ tikroji tiesa Nr. 1: PRISIJUNGIMAI reiškia nuoseklumą
Vienas iš pirmųjų problemų, susijusių su SQL sistemomis, yra JOIN vykdymo tarp dviejų lentelių skaičiavimo išlaidos. Idėja yra saugoti duomenis vienoje ir vienoje vietoje. Jei vedate klientų sąrašą, į vieną lentelę įtraukite jų gatvių adresus, o kitose lentelėse naudojate jų klientų ID. Kai traukiate duomenis, JOIN susieja ID su adresais ir viskas išlieka nuosekli.
Bėda ta, kad JOIN gali kainuoti brangiai, o kai kurie DBA sukūrė sudėtingas JOIN komandas, kurios apgaubia protą ir net greičiausią aparatūrą paverčia dumblu. Nenuostabu, kad „NoSQL“ kūrėjai JOIN trūkumą pavertė funkcija: Tiesiog pasilikime kliento adresą toje pačioje lentelėje kaip ir visa kita! „NoSQL“ būdas yra raktų ir reikšmių porų saugojimas kiekvienam asmeniui. Kai ateis laikas, juos visus gausite.
Deja, žmonėms, norintiems, kad jų stalai būtų nuoseklūs, vis tiek reikia JOIN. Pradėję saugoti klientų adresus su visa kita apie juos, kiekvienoje lentelėje dažnai gausite kelias tų adresų kopijas. Jei turite kelias kopijas, turite jas visas atnaujinti vienu metu. Kartais tai veikia, bet kai ne, „NoSQL“ nėra pasirengusi padėti atlikti operacijas.
Palaukite, sakote, kodėl gi neturint atskiros lentelės su kliento informacija? Tokiu būdu bus pakeistas tik vienas įrašas. Tai puiki idėja, bet dabar jūs turite patys parašyti JUNGTI pagal savo logiką.
„NoSQL“ tikroji tiesa Nr. 2: keblūs sandoriai
Tarkime, kad jūs galite gyventi be JUNGTIS lentelių, nes norite greičio. Tai yra priimtinas kompromisas, ir kartais SQL DBA denormalizuoja lenteles tik dėl šios priežasties.
Bėda ta, kad „NoSQL“ sunku išlaikyti įvairių įrašų nuoseklumą. Dažnai nėra jokių operacijų, kurios užtikrintų, kad kelių lentelių pakeitimai būtų atliekami kartu. Dėl to jūs esate vienas, o avarija gali užtikrinti, kad lentelės pasisuks nenuosekliai.
Ankstyviausios „NoSQL“ diegimo priemonės pirštu davė pirmenybę šiems sandoriams. Jie siūlytų nuoseklius duomenų sąrašus, išskyrus atvejus, kai to nebuvo. Kitaip tariant, jie sekė mažiausios vertės duomenis, kur klaidos neturėjo jokio esminio skirtumo.
Dabar kai kurie „NoSQL“ diegimo būdai artėja prie sandorio. Pavyzdžiui, „Oracle“ gaminys „NoSQL“ siūlo operacijų valdymą duomenims, užrašytiems į vieną mazgą, ir leidžia pasirinkti lanksčią nuoseklumo sumą keliuose mazguose. Jei norite tobulo nuoseklumo, turite palaukti, kol kiekvienas rašymas pasieks visus mazgus. Keletas kitų „NoSQL“ duomenų saugyklų bando pridėti daugiau tokios struktūros ir apsaugos.
„NoSQL“ tikroji tiesa Nr. 3: Duomenų bazės gali būti protingos
Daugelis „NoSQL“ programuotojų mėgsta pasigirti, kaip jų lengvas kodas ir paprastas mechanizmas veikia itin greitai. Paprastai jie teisūs, kai užduotys yra tokios paprastos kaip „NoSQL“ vidus, tačiau tai pasikeičia, kai problemos tampa vis sunkesnės.
Apsvarstykite seną JUNGTIS iššūkį. Kai „NoSQL“ programuotojai pradeda kurti savo JOIN komandas pagal savo logiką, jie pradeda stengtis tai padaryti efektyviai. SQL kūrėjai dešimtmečius kūrė sudėtingus variklius, kad JOIN komandos būtų kuo efektyviau valdomos. Vienas SQL kūrėjas man pasakė, kad bando sinchronizuoti savo kodą su besisukančiu standžiuoju disku, kad jis paprašytų duomenų tik tada, kai galva yra tiesiai virš reikiamos vietos. Tai gali atrodyti ekstremalu, tačiau SQL kūrėjai dešimtmečius dirbo prie panašių įsilaužimų.
Neabejotina, kad programuotojai kelias dienas traukia plaukus ir bando susisteminti savo SQL užklausas, kad galėtų pasinaudoti visa šia latentine žvalgyba. Gal nėra paprasta paliesti, bet kai programuotojas tai išsiaiškina, duomenų bazės gali tikrai dainuoti.
Tokia sudėtinga užklausų kalba, kaip SQL, visada gali perteikti neįmantrią užklausos kalbą, tokią, kokia yra „NoSQL“. Gali būti nesvarbu su paprastais rezultatais, tačiau kai veiksmas tampa sudėtingas, SQL vykdomas mašinoje šalia duomenų. Ji turi mažai pridėtinių duomenų, kad gautų duomenis ir atliktų darbą. „NoSQL“ serveris paprastai turi perduoti duomenis ten, kur jie eina.
„NoSQL“ tikroji tiesa Nr. 4: per daug prieigos modelių
Teoriškai SQL turėtų būti standartinė kalba. Jei naudojate SQL vienai duomenų bazei, turėtumėte galėti tą pačią užklausą vykdyti kitoje suderinamoje versijoje. Šis teiginys gali veikti su keliomis paprastomis užklausomis, tačiau kiekvienas DBA žino, kad gali prireikti metų, kol išmoksi SQL savitumą skirtingoms tos pačios duomenų bazės versijoms. Raktiniai žodžiai yra iš naujo apibrėžti, o užklausos, kurios veikė su viena versija, neveiks su kita.
„NoSQL“ yra dar paslaptingesnė. Tai tarsi Babelio bokštas. Nuo pat pradžių „NoSQL“ kūrėjai bandė įsivaizduoti kuo geresnę kalbą, tačiau jų vaizduotė labai skiriasi. Šis eksperimentų židinys yra geras - kol bandysite pereiti tarp įrankių. „CouchDB“ užklausa išreiškiama kaip „JavaScript“ funkcijų pora, skirta susieti ir sumažinti. Ankstyvosiose „Cassandra“ versijose buvo naudojama neapdorota, žemo lygio API, vadinama „Thrift“; naujesnėse versijose siūloma CQL - į SQL panaši užklausų kalba, kurią serveris turi išanalizuoti ir suprasti. Kiekvienas savaip skiriasi.
Kiekvienas įrankis turi ne tik savitą savitumą, bet ir visiškai kitokią filosofiją bei jo išreiškimo būdą. Nėra paprastų būdų, kaip persijungti tarp duomenų saugyklų, ir jūs dažnai paliekate rašyti daugybę klijų kodų, kad ateityje galėtumėte sau perjungti. Tai gali būti ne per sunku, kai į sistemą įkeliate raktų ir reikšmių poras, tačiau tai gali vis labiau pabloginti jūsų įvestą sudėtingumą.
„NoSQL“ tikroji tiesa Nr. 5: Schemos lankstumas yra sunkumų laukiantis įvykis
Viena iš puikių „NoSQL“ modelio idėjų nereikalauja schemos. Kitaip tariant, programuotojams nereikia iš anksto nuspręsti, kurie stulpeliai bus prieinami kiekvienai lentelės eilutei. Viename įraše gali būti pridėta 20 eilučių, kitame gali būti 12 sveikųjų skaičių, o kitame gali būti visiškai tuščia. Programuotojai gali priimti sprendimą, kai tik reikia ką nors laikyti. Jiems nereikia prašyti DBA leidimo ir nereikia užpildyti visų dokumentų, kad būtų galima pridėti naują stulpelį.
Visa ta laisvė skamba svaiginančiai, o teisingose rankose ji gali paspartinti plėtrą. Bet ar tai tikrai gera duomenų bazės, kuri gali gyventi per tris kūrėjų komandas, idėja? Ar tai netgi įmanoma duomenų bazei, kuri gali trukti ilgiau nei šešis mėnesius?
Kitaip tariant, kūrėjai gali norėti laisvės mesti bet kokią seną porą į duomenų bazę, bet ar norite būti penktasis kūrėjas, pasirodęs po to, kai keturi pasirinko savo raktus? Lengva įsivaizduoti įvairius „gimtadienio“ atvaizdavimus, kai kiekvienas kūrėjas pridedant vartotojo gimtadienį prie įrašo pasirenka savo atvaizdą kaip raktą. Kūrėjų komanda gali įsivaizduoti beveik viską: „bday“, „b-day“, „gimtadienis“.
„NoSQL“ struktūra nepalaiko šios problemos apribojimo palaikymo, nes tai reikštų iš naujo įsivaizduoti schemą. Tai nenori griežti dėl visiškai šaunių kūrėjų. Schema trukdytų.
Faktas yra tas, kad stulpelio pridėjimas prie lentelės nėra didelis dalykas ir disciplina iš tikrųjų gali būti naudinga kūrėjui. Kaip tai priverčia kūrėjus paskirti kintamųjų tipus, taip pat padeda priversti kūrėjus nurodyti prie stulpelio pridedamų duomenų tipą. Taip, DBA gali priversti kūrėją užpildyti formą trimis egzemplioriais prieš pridedant tą stulpelį, tačiau tai nėra taip blogai, kaip susidoroti su puse tuzino skirtingų raktų, kuriuos programuotojas sukūrė skraidydamas.
„NoSQL“ tikroji tiesa Nr. 6: jokių priedų
Tarkime, kad nenorite visų duomenų visose eilutėse, o norite vieno stulpelio sumos. SQL vartotojai gali atlikti užklausą naudodami operaciją SUM ir išsiųsti jums vieną - tik vieną - numerį.
„NoSQL“ vartotojai grąžina visus duomenis, kuriuos jie išsiuntė, ir tada patys gali atlikti papildymą. Papildymas nėra problema, nes skaičiuojant bet kurią mašiną reikia maždaug tiek pat laiko. Tačiau duomenų perdavimas aplink yra lėtas, o pralaidumas, reikalingas visiems šiems duomenims perduoti, gali būti brangus.
„NoSQL“ duomenų bazėse yra nedaug priedų. Jei norite padaryti bet ką, išskyrus saugoti ir gauti duomenis, tikriausiai tai padarysite patys. Daugeliu atvejų tai darysite kitame kompiuteryje su visa duomenų kopija. Tikroji problema yra ta, kad dažnai gali būti naudinga atlikti visus skaičiavimus mašinoje, kurioje laikomi duomenys, nes duomenų siuntimas užtrunka. Bet jums sunku.
Kuriasi „NoSQL“ sprendimai. „MongoDB“ užklausos „Žemėlapis ir sumažinimas“ struktūra suteikia jums savavališką „JavaScript“ struktūrą duomenims virinti. „Hadoop“ yra galingas skaičiavimo paskirstymo mašinų šūsnyje mechanizmas, kuriame taip pat laikomi duomenys. Tai greitai besikeičianti struktūra, siūlanti greitai tobulėjančius įrankius sudėtingai analizei kurti. Tai labai šaunu, bet vis tiek nauja. Techniškai „Hadoop“ yra visiškai kitoks nei „NoSQL“ madingas žodis, nors skirtumas tarp jų nyksta.
„NoSQL“ tikroji tiesa Nr. 7: mažiau įrankių
Žinoma, galite paleisti „NoSQL“ kaupą savo serveryje. Žinoma, galite parašyti savo pasirinktinį kodą, kad galėtumėte stumti ir ištraukti duomenis iš rietuvės. Bet ką daryti, jei norite padaryti daugiau? Ką daryti, jei norite nusipirkti vieną iš šių prašmatnių ataskaitų paketų? Arba grafikų paketas? Arba atsisiųsti keletą atvirojo kodo įrankių, skirtų kurti diagramas?
Deja, dauguma įrankių yra skirti SQL duomenų bazėms. Jei norite generuoti ataskaitas, kurti diagramas ar ką nors padaryti su visais duomenimis, esančiais „NoSQL“ rietuvėje, turėsite pradėti koduoti. Standartiniai įrankiai paruošti „Oracle“, „Microsoft SQL“, „MySQL“ ir „Postgres“ duomenų rinkimui. Jūsų duomenys yra „NoSQL“? Jie tuo dirba.
Ir jie šiek tiek stengsis. Net jei jie peršoks visus ratus, norėdami atsistoti ir paleisti su viena iš NoSQL duomenų bazių, jie turės viską pradėti nuo pradžių, kad galėtų tvarkyti kitą sistemą. Yra daugiau nei 20 skirtingų „NoSQL“ pasirinkimų, kurie visi naudoja savo filosofiją ir savo darbo su duomenimis būdą. Įrankių kūrėjams buvo pakankamai sunku palaikyti SQL savitumus ir nenuoseklumus, tačiau dar sudėtingiau priversti įrankius dirbti su kiekvienu „NoSQL“ požiūriu.
Tai problema, kuri lėtai praeis. Kūrėjai gali nujausti „NoSQL“ jaudulį ir modifikuos savo įrankius, kad galėtų dirbti su šiomis sistemomis, tačiau tai užtruks. Gal tada jie pradės veikti „MongoDB“, o tai jums nepadės, nes naudojate „Cassandra“. Standartai padeda tokiose situacijose, o „NoSQL“ nėra didelis.
„NoSQL“ trūkumai trumpai
Visus šiuos „NoSQL“ trūkumus galima sumažinti vienu paprastu teiginiu: „NoSQL“ išmeta funkcionalumą, kad būtų greitesnis. Jei jums nereikia šios funkcijos, viskas bus gerai, bet jei jums jos prireiks ateityje, apgailestausite.
Revoliucijos yra endemiškos technologijų kultūrai. Atsiranda nauja grupė ir stebisi, kodėl paskutinė karta pastatė kažką tokio sudėtingo, ir jie ėmė griauti senąsias institucijas. Po truputį jie pradeda suprasti, kodėl visos senosios įstaigos buvo tokios sudėtingos, ir vėl pradeda įgyvendinti šias funkcijas.
Tai matome „NoSQL“ pasaulyje, nes kai kurie projektai pradeda papildyti dalykus, kurie atrodo kaip sandoriai, schemos ir standartai. Tai pažangos pobūdis. Mes griauname daiktus tik tam, kad juos vėl sugrąžintume. „NoSQL“ yra baigtas pirmuoju revoliucijos etapu, o dabar atėjo laikas antram. Karalius mirė. Tegyvuoja karalius.
Susiję straipsniai
- „NoSQL“ išskirtiniai: naujos duomenų bazės naujoms programoms
- Pirmas žvilgsnis: „Oracle NoSQL“ duomenų bazė
- „NoSQL“ lankstumas: peržiūrima „MongoDB“
- 10 esminių „MySQL“ našumo patarimų
- 10 esminių „MySQL“ įrankių administratoriams
- „MySQL“ valdymas „Amazon“ debesyje
- „NoSQL“ standartų laikas jau yra
Ši istorija „7 sunkios tiesos apie„ NoSQL “revoliuciją“ iš pradžių buvo paskelbta .com. Stebėkite naujausius duomenų valdymo pokyčius .com. Norėdami sužinoti naujausius verslo technologijų naujienas, sekite .com „Twitter“.
