NoSQL buzzword ir metastāzēts jau vairākus gadus. Satraukums par šiem ātrajiem datu krājumiem ir bijis apreibinošs, un mēs esam tikpat vainīgi kā citi, redzot NoSQL revolucionāro pievilcību. Tomēr medusmēnesis tuvojas beigām, un ir pienācis laiks sākt līdzsvarot mūsu entuziasmu ar dažām stingrām patiesībām.
Nepārprotiet mūs. Mēs joprojām cenšamies izmēģināt jaunāko eksperimentu, lai izveidotu vienkāršu datu glabāšanas mehānismu. Mēs joprojām atrodam dziļu vērtību MongoDB, CouchDB, Cassandra, Riak un citās NoSQL izceļamās vietās. Mēs joprojām plānojam iemest dažus mūsu uzticamākos datus šajos koda krāvumos, jo tie katru dienu kļūst arvien labāki un kaujas pārbaudītāki.
[Arī vietnē: NoSQL standouts: Jaunas datu bāzes jaunām lietojumprogrammām Pirmais skatījums: Oracle NoSQL datu bāze | Katru dienu apkopojiet galvenos stāstus ikdienas biļetenā. ]
Bet mēs sākam izjust berzi, jo NoSQL sistēmas nebūt nav ideāli piemērotas un bieži berzē nepareizu ceļu. Gudrākie izstrādātāji to zināja jau no paša sākuma. Viņi nesadedzināja SQL rokasgrāmatas un nesūtīja nejaukas programmas sava kādreiz uzticīgā SQL pārdevēja pārdošanas komandai. Nē, viedie NoSQL izstrādātāji vienkārši atzīmēja, ka NoSQL apzīmē "Ne tikai SQL". Ja masas nepareizi interpretēja saīsinājumu, tā bija viņu problēma.
Šis lielo un mazo rokturu saraksts tādējādi ir mēģinājums dokumentēt šo faktu un atbrīvot gaisu. Tas ir domāts, lai tagad sakārtotu lietas, lai mēs varētu labāk strādāt, izprotot kompromisus un kompromisus.
NoSQL cietā patiesība Nr. 1: Pievienošanās nozīmē konsekvenci
Viens no pirmajiem jautājumiem, kas cilvēkiem ir par SQL sistēmām, ir skaitļošanas izmaksas, izpildot JOIN starp divām tabulām. Ideja ir glabāt datus vienā un tikai vienā vietā. Ja jūs uzturat klientu sarakstu, jūs ievietojat viņu adreses vienā tabulā un izmantojat viņu klientu ID katrā otrajā tabulā. Kad velkat datus, JOIN savieno ID ar adresēm, un viss paliek nemainīgs.
Problēma ir tāda, ka JOIN var būt dārga, un daži DBA ir izdomājuši sarežģītas JOIN komandas, kas nesaprot prātu, pat ātrāko aparatūru pārvēršot dūņās. Nebija pārsteigums, ka NoSQL izstrādātāji savu JOIN trūkumu pārvērta par funkciju: Saglabāsim tikai klienta adresi vienā tabulā kā viss pārējais! NoSQL veids ir galvenās vērtības pāru glabāšana katrai personai. Kad pienāks laiks, jūs tos visus izgūsiet.
Ak, cilvēkiem, kuri vēlas, lai viņu tabulas būtu konsekventas, joprojām ir vajadzīgi PIEVIENOŠANĀS. Kad sākat glabāt klientu adreses ar visu pārējo par viņiem, katrā tabulā bieži rodas vairākas šo adrešu kopijas. Un, ja jums ir vairākas kopijas, tās visas vienlaikus jāatjaunina. Dažreiz tas darbojas, bet, kad tas nedarbojas, NoSQL nav gatavs palīdzēt darījumos.
Pagaidiet, jūs sakāt, kāpēc gan jums nebūtu atsevišķas tabulas ar klienta informāciju? Tādā veidā būs jāmaina tikai viens ieraksts. Tā ir lieliska ideja, bet tagad jums ir jāpieraksta PIEVIENOTIES savā loģikā.
NoSQL cietā patiesība Nr. 2: viltīgi darījumi
Pieņemsim, ka jums ir labi dzīvot bez PIEVIENOŠANĀS tabulām, jo vēlaties ātrumu. Tas ir pieņemams kompromiss, un dažreiz SQL DBA denormalizē tabulas tikai šī iemesla dēļ.
Problēma ir tā, ka NoSQL apgrūtina dažādu ierakstu konsekvenci. Bieži vien netiek veikti darījumi, lai pārliecinātos, ka izmaiņas vairākās tabulās tiek veiktas kopā. Šim nolūkam jūs esat viens pats, un avārija var nodrošināt, ka tabulas kļūst pretrunīgas.
Agrākās NoSQL ieviešanas īkšķi nospieda šos darījumus. Viņi piedāvātu konsekventus datu sarakstus, izņemot gadījumus, kad tā nebija. Citiem vārdiem sakot, viņi sekoja datiem ar viszemāko vērtību, kur kļūdas neko nemainīja.
Tagad daži NoSQL ieviešanas varianti piedāvā kaut ko tuvoties darījumam. Piemēram, Oracle izstrādājums NoSQL piedāvā darījumu kontroli pār vienā mezglā ierakstītajiem datiem un ļauj izvēlēties elastīgu konsekvences daudzumu vairākos mezglos. Ja vēlaties perfektu konsekvenci, jums jāgaida, kamēr katrs raksts sasniedz visus mezglus. Vairāki citi NoSQL datu krājumi eksperimentē, pievienojot vairāk šādas struktūras un aizsardzības.
NoSQL cietā patiesība Nr. 3: Datu bāzes var būt gudras
Daudziem NoSQL programmētājiem patīk lielīties par to, kā viņu vieglais kods un vienkāršais mehānisms darbojas ārkārtīgi ātri. Viņiem parasti ir taisnība, ja uzdevumi ir tikpat vienkārši kā NoSQL iekšpuse, taču tas mainās, kad problēmas kļūst grūtākas.
Apsveriet veco VIENOŠANĀS izaicinājumu. Kad NoSQL programmētāji sāk ģenerēt savas JOIN komandas savā loģikā, viņi sāk mēģināt to izdarīt efektīvi. SQL izstrādātāji gadu desmitiem ir izstrādājuši sarežģītus dzinējus, lai pēc iespējas efektīvāk apstrādātu JOIN komandas. Viens SQL izstrādātājs man teica, ka viņš mēģina sinhronizēt savu kodu ar vērpjošo cieto disku, lai viņš pieprasītu datus tikai tad, kad galva atrodas tieši virs pareizās vietas. Tas var šķist ārkārtīgi, taču SQL izstrādātāji gadu desmitiem ir strādājuši pie līdzīgiem uzlaušanas gadījumiem.
Nav šaubu, ka programmētāji vairākas dienas pavelk matus, cenšoties strukturēt savus SQL vaicājumus, lai izmantotu visu šo latento intelektu. Varbūt nav viegli pieskarties, bet, kad programmētājs to izdomā, datu bāzes patiešām var dziedāt.
Izsmalcinātai vaicājumu valodai, piemēram, SQL, vienmēr ir iespējas pārspēt nesarežģītu vaicājumu valodu, piemēram, valodu NoSQL. Varbūt tam nav nozīmes ar vienkāršiem rezultātiem, bet, kad darbība kļūst sarežģīta, SQL tiek izpildīts mašīnā tieši blakus datiem. Tam ir maz pieskaitāmo datu ielādes un darba veikšanas. NoSQL serverim dati parasti jānosūta turp, kur tie notiek.
NoSQL cietā patiesība Nr. 4: Pārāk daudz piekļuves modeļu
Teorētiski SQL vajadzētu būt standarta valodai. Ja lietojat SQL vienai datu bāzei, jums vajadzētu būt iespējai palaist to pašu vaicājumu citā saderīgā versijā. Šis apgalvojums var darboties ar dažiem vienkāršiem vaicājumiem, taču katrs DBA zina, ka var paiet gadi, lai uzzinātu SQL īpatnības vienas un tās pašas datu bāzes dažādās versijās. Atslēgvārdi tiek definēti no jauna, un vaicājumi, kas darbojās vienā versijā, nedarbosies ar citu.
NoSQL ir vēl aizraujošāks. Tas ir kā Bābeles tornis. Kopš sākuma NoSQL izstrādātāji katrs ir mēģinājis iedomāties labāko iespējamo valodu, taču viņiem ir ļoti atšķirīga iztēle. Šis eksperimentu stends ir labs - līdz brīdim, kad mēģināt pāriet starp rīkiem. Vaicājums CouchDB tiek izteikts kā JavaScript funkciju pāris kartēšanai un samazināšanai. Agrīnās Cassandra versijās tika izmantots neapstrādāts, zema līmeņa API ar nosaukumu Thrift; jaunākās versijās tiek piedāvāta CQL - SQL līdzīga vaicājuma valoda, kas serverim ir jāparsē un jāsaprot. Katrs savā veidā ir atšķirīgs.
Katram rīkam ir ne tikai savas īpatnības, bet tas ir pilnīgi atšķirīga filozofija un veids, kā to izteikt. Nav vienkāršu veidu, kā pārslēgties starp datu krātuvēm, un jūs bieži atstājat daudz tonnu līme koda, lai dotu sev iespēju pārslēgties nākotnē. Tas var nebūt pārāk grūti, ja sistēmā ievietojat atslēgu un vērtību pārus, taču tas var arvien vairāk saasināt jūsu ieviesto sarežģītību.
NoSQL cietā patiesība Nr. 5: Shēmas elastība sagādā grūtības gaidīt
Viena no lieliskajām idejām no NoSQL modeļa neprasa shēmu. Citiem vārdiem sakot, programmētājiem nav iepriekš jāizlemj, kuras kolonnas būs pieejamas katrai tabulas rindai. Vienam ierakstam var būt pievienotas 20 virknes, citam var būt 12 veseli skaitļi, bet citā - pilnīgi tukša vieta. Programmētāji var pieņemt lēmumu ikreiz, kad viņiem kaut kas ir jāuzglabā. Viņiem nav jālūdz DBA atļauja, un viņiem nav jāaizpilda visi dokumenti, lai pievienotu jaunu kolonnu.
Visa šī brīvība izklausās reibinoši, un labajās rokās tā var paātrināt attīstību. Bet vai tā tiešām ir laba ideja datubāzei, kas varētu dzīvot trīs izstrādātāju komandās? Vai tas pat ir derīgs datubāzei, kas varētu ilgt vairāk nekā sešus mēnešus?
Citiem vārdiem sakot, izstrādātāji varētu vēlēties brīvību iemest jebkuru veco pāri datu bāzē, bet vai vēlaties būt piektais izstrādātājs, kurš ieradīsies pēc tam, kad četri ir izvēlējušies savus taustiņus? Ir viegli iedomāties dažādus “dzimšanas dienas” attēlojumus, kad katrs izstrādātājs izvēlas pats savu pārstāvniecību kā atslēgu, pievienojot ierakstam lietotāja dzimšanas dienu. Izstrādātāju komanda varētu iedomāties gandrīz jebko: "bday", "b-day", "birthday".
NoSQL struktūra nepiedāvā atbalstu, lai ierobežotu šo problēmu, jo tas nozīmētu pārdomāt shēmu. Tas nevēlas skarbi izturēties pret pilnīgi atdzist izstrādātājiem. Shēma varētu traucēt.
Fakts ir tāds, ka kolonnas pievienošana tabulai nav nekas liels, un disciplīna patiešām varētu būt noderīga izstrādātājam. Tāpat kā tas palīdz izstrādātājiem piespiest noteikt mainīgos veidus, tas palīdz arī izstrādātājiem noteikt kolonnai pievienoto datu veidu. Jā, DBA var piespiest izstrādātāju pirms šīs kolonnas pievienošanas trijos eksemplāros aizpildīt veidlapu, taču tas nav tik slikti, kā rīkoties ar pusduci dažādu atslēgu, kuras programmētājs izveidojis lidojumā.
NoSQL cietā patiesība Nr. 6: Nekādas ekstras
Pieņemsim, ka nevēlaties visus datus visās rindās, bet gan vienas kolonnas summu. SQL lietotāji var izpildīt vaicājumu ar operāciju SUM un nosūtīt jums vienu - tikai vienu - numuru.
NoSQL lietotāji atgūst visus nosūtītos datus un pēc tam paši var veikt papildinājumu. Pievienošana nav problēma, jo skaitļu saskaitīšana jebkurā mašīnā prasa apmēram tikpat daudz laika. Tomēr datu nosūtīšana apkārt ir lēna, un joslas platums, kas nepieciešams visu šo datu nosūtīšanai, var būt dārgs.
NoSQL datu bāzēs ir maz papildinājumu. Ja vēlaties kaut ko darīt, izņemot datu glabāšanu un izgūšanu, jūs, iespējams, darīsit to pats. Daudzos gadījumos jūs to darīsit citā mašīnā ar pilnīgu datu kopiju. Patiesā problēma ir tā, ka bieži vien var būt noderīgi veikt visu aprēķinu mašīnā, kurā glabājas dati, jo datu nosūtīšana prasa laiku. Bet jums grūts.
Parādās NoSQL risinājumi. Kartes un samazināšanas vaicājumu struktūra no MongoDB dod jums patvaļīgu JavaScript struktūru datu vārīšanai. Hadoop ir spēcīgs skaitļošanas izplatīšanas mehānisms visā mašīnu kaudzē, kas satur arī datus. Tā ir strauji attīstoša struktūra, kas piedāvā ātri uzlabojošus rīkus sarežģītas analīzes veidošanai. Tas ir ļoti foršs, bet tomēr jauns. Un tehniski Hadoop ir pavisam cits modes vārds nekā NoSQL, lai gan atšķirība starp tiem izzūd.
NoSQL cietā patiesība Nr. 7: mazāk rīku
Protams, jūs varat izveidot savu NoSQL kaudzīti un darboties savā serverī. Protams, jūs varat rakstīt savu pielāgoto kodu, lai virzītu un izvilktu datus no kaudzes. Bet ja jūs vēlaties darīt vairāk? Ko darīt, ja vēlaties iegādāties kādu no šīm iedomātajām ziņošanas paketēm? Vai grafiku pakete? Vai arī lejupielādēt dažus atvērtā pirmkoda rīkus diagrammu izveidošanai?
Diemžēl lielākā daļa rīku ir rakstīti SQL datu bāzēm. Ja vēlaties ģenerēt pārskatus, izveidot diagrammas vai kaut ko darīt ar visiem jūsu NoSQL kaudzes datiem, jums jāsāk kodēšana. Standarta rīki ir gatavi sagrābt datus no Oracle, Microsoft SQL, MySQL un Postgres. Jūsu dati ir NoSQL? Viņi strādā pie tā.
Un viņi mazliet strādās pie tā. Pat ja viņi lec cauri visiem lokiem, lai sāktu darboties ar kādu no NoSQL datu bāzēm, viņiem būs jāsāk viss no jauna, lai rīkotos ar nākamo sistēmu. Ir vairāk nekā 20 dažādas NoSQL izvēles iespējas, kuras visas sporto ar savu filozofiju un savu veidu, kā strādāt ar datiem. Rīku veidotājiem bija pietiekami grūti atbalstīt SQL savdabību un neatbilstību, taču vēl sarežģītāk ir panākt, lai rīki darbotos ar katru NoSQL pieeju.
Šī ir problēma, kas lēnām izzudīs. Izstrādātāji var sajust NoSQL satraukumu, un viņi pārveidos savus rīkus darbam ar šīm sistēmām, taču tas prasīs laiku. Varbūt tad viņi sāks darboties vietnē MongoDB, kas jums nepalīdzēs, jo jūs vadāt Kasandru. Standarti palīdz šādās situācijās, un NoSQL nav liels standartos.
NoSQL trūkumi īsumā
Visus šos NoSQL trūkumus var samazināt līdz vienam vienkāršam apgalvojumam: NoSQL ātruma dēļ izmet funkcionalitāti. Ja jums nav nepieciešama funkcionalitāte, jums viss būs kārtībā, bet, ja jums tas būs vajadzīgs nākotnē, jums būs žēl.
Revolūcijas ir tehniskas kultūras endēmiskas. Nāk jauna grupa un brīnās, kāpēc pēdējā paaudze uzbūvēja kaut ko tik sarežģītu, un viņi sāka nojaukt vecās iestādes. Pēc neilga laika viņi sāk saprast, kāpēc visas vecās iestādes bija tik sarežģītas, un viņi atkal sāka ieviest funkcijas.
Mēs to redzam NoSQL pasaulē, jo daži projekti sāk pievienot lietas, kas izskatās kā darījumi, shēmas un standarti. Tā ir progresa daba. Mēs nojaucam lietas tikai tāpēc, lai tās atkal atjaunotu. NoSQL ir pabeigts ar revolūcijas pirmo fāzi, un tagad ir pienācis laiks otrajam. Karalis ir miris. Lai dzīvo karalis.
Saistītie raksti
- NoSQL standouts: jaunas datubāzes jaunām lietojumprogrammām
- Pirmais skatījums: Oracle NoSQL datu bāze
- NoSQL elastīgums: MongoDB tiek pārskatīts
- 10 būtiski padomi par MySQL veiktspēju
- 10 būtiski MySQL rīki administratoriem
- Pārvaldiet MySQL Amazon mākonī
- NoSQL standartiem ir pienācis laiks
Šis stāsts "7 smagas patiesības par NoSQL revolūciju" sākotnēji tika publicēts .com. Sekojiet jaunākajiem notikumiem datu pārvaldībā vietnē .com. Lai uzzinātu jaunāko informāciju par biznesa tehnoloģiju jaunumiem, sekojiet .com vietnē Twitter.
