Bučna beseda NoSQL metastazira že nekaj let. Navdušenje nad temi hitrimi shrambami podatkov je bilo opojno in tudi mi smo kot vsi krivi, da smo videli prelomno privlačnost NoSQL. Kljub temu se medeni tedni končujejo in čas je, da začnemo svoje navdušenje uravnotežiti z nekaterimi trdo resnicami, ki jih je videti.
Ne razumite nas narobe. Še vedno tečemo, da bi preizkusili najnovejši eksperiment pri gradnji preprostega mehanizma za shranjevanje podatkov. Še vedno najdemo globoko vrednost v izstopajočih MongoDB, CouchDB, Cassandri, Riaku in drugih NoSQL. Še vedno načrtujemo, da bomo nekaj teh najbolj zaupanja vrednih podatkov prenesli v te sklade kode, ker so vsak dan boljši in bolj preizkušeni.
[Tudi na: Izstopajoče NoSQL: Nove zbirke podatkov za nove aplikacije | Prvi pogled: Oracle NoSQL Database | Vsak dan v dnevniškem dnevniku preberite povzetek ključnih zgodb. ]
Toda začenjamo čutiti drgnjenje, saj sistemi NoSQL še zdaleč niso popolnoma primerni in se pogosto držijo napačno. Najpametnejši razvijalci so to vedeli že od začetka. Niso spali priročnikov SQL in poslali nastygramov prodajalcem svojega nekoč predanega prodajalca SQL. Ne, pametni razvijalci NoSQL so preprosto ugotovili, da NoSQL pomeni "Ne samo SQL". Če so množice napačno razlagale kratico, je bil to njihov problem.
Ta seznam napak, velikih in majhnih, je tako poskus dokumentiranja tega dejstva in čiščenja zraka. Zdaj naj bi stvari postavili naravnost, da bomo lahko bolje razumeli kompromise in kompromise.
NoSQL trda resnica št. 1: JOIN-i pomenijo doslednost
Eden prvih problemov, ki jih imajo ljudje pri sistemih SQL, so računski stroški izvajanja JOIN med dvema tabelama. Ideja je shraniti podatke na enem mestu. Če vodite seznam strank, v eno tabelo vnesete njihove naslove in v vsako drugo tabelo uporabite njihove ID-je strank. Ko povlečete podatke, JOIN poveže ID-je z naslovi in vse ostane skladno.
Težava je v tem, da so JOIN-i lahko dragi, nekateri DBA-ji pa so sestavili zapletene JOIN-ukaze, ki zmotijo um in celo najhitrejšo strojno opremo pretvorijo v blato. Ni presenetilo, da so razvijalci NoSQL pomanjkanje JOIN-ov spremenili v funkcijo: Naj ostane naslov stranke v isti tabeli kot vse ostalo! NoSQL način je shranjevanje parov ključ / vrednost za vsako osebo. Ko pride čas, jih vse pridobite.
Žal ljudje, ki želijo, da so njihove tabele skladne, še vedno potrebujejo PRIDRUŽITVE. Ko začnete shranjevati naslove strank z vsem ostalim o njih, v vsaki tabeli pogosto dobite več kopij teh naslovov. In če imate več kopij, jih morate posodobiti vse hkrati. Včasih to deluje, če pa ne, NoSQL ni pripravljen pomagati pri transakcijah.
Počakajte, pravite, zakaj ne bi imeli ločene tabele s podatki o stranki? Tako se bo spremenil le en zapis. To je dobra ideja, zdaj pa lahko sami pišete JOIN v svoji logiki.
NoSQL trda resnica št. 2: Zapletene transakcije
Recimo, da lahko živite brez pridružitve miz, ker želite hitrost. To je sprejemljiv kompromis in včasih SQL DBA razvrstijo tabele ravno iz tega razloga.
Težava je v tem, da NoSQL težko ohranja doslednost različnih vnosov. Pogosto ni transakcij, s katerimi bi zagotovili, da se spremembe več tabel izvedejo skupaj. Za to ste sami in zrušitev lahko zagotovi, da se tabele spremenijo v neskladje.
Najzgodnejše implementacije NoSQL so si pri teh transakcijah zaslepile nos. Ponudili bi sezname podatkov, ki bi bili dosledni, razen kadar niso. Z drugimi besedami, iskali so podatke z najnižjo vrednostjo, kjer napake ne bi bistveno vplivale.
Zdaj nekatere izvedbe NoSQL ponujajo nekaj, kar se približuje transakciji. Oraclov izdelek NoSQL na primer ponuja nadzor nad transakcijami nad podatki, zapisanimi v eno vozlišče, in vam omogoča, da izberete prilagodljivo količino skladnosti med več vozlišči. Če želite popolno skladnost, morate počakati, da vsak zapis doseže vsa vozlišča. Številne druge shrambe podatkov NoSQL eksperimentirajo z dodajanjem takšne strukture in zaščite.
NoSQL trda resnica št. 3: Zbirke podatkov so lahko pametne
Mnogi programerji NoSQL se radi pohvalijo, kako njihova lahka koda in preprost mehanizem delujeta izjemno hitro. Običajno imajo prav, če so naloge tako preproste kot notranjost NoSQL, vendar se to spremeni, ko so težave težje.
Razmislite o starem izzivu PRIDRUŽITEV. Ko NoSQL programerji začnejo generirati lastne ukaze JOIN v svoji logiki, začnejo to skušati učinkovito. Razvijalci SQL so desetletja razvijali dovršene motorje za čim bolj učinkovito obdelavo ukazov JOIN. En razvijalec SQL mi je povedal, da poskuša sinhronizirati svojo kodo s predenjem trdega diska, tako da bo zahteval podatke le, če je glava tik nad desnim mestom. To se morda zdi skrajno, vendar razvijalci SQL že desetletja delajo na podobnih hakovih.
Nobenega dvoma ni, da programerji dneve vlečejo za lase in poskušajo strukturirati svoje SQL poizvedbe, da bi izkoristili vse te latentne inteligence. Morda ni enostavno tapkati, ko pa programer to ugotovi, lahko zbirke podatkov resnično zapojejo.
Prefinjen jezik poizvedb, kot je SQL, lahko vedno zasenči nezahteven jezik poizvedb, kakršen najdemo v NoSQL. Mogoče ni pomembno pri preprostih rezultatih, toda ko postane dejanje zapleteno, se SQL izvrši na napravi tik ob podatkih. Ima malo režijskih stroškov za pridobivanje podatkov in opravljanje dela. Strežnik NoSQL mora podatke običajno poslati tja, kamor gredo.
NoSQL trda resnica št. 4: Preveč modelov dostopa
V teoriji naj bi bil SQL standardni jezik. Če za eno bazo podatkov uporabljate SQL, bi morali isto poizvedbo zagnati v drugi združljivi različici. Ta trditev morda deluje z nekaj preprostimi poizvedbami, vendar vsak DBA ve, da lahko traja leta, da se naučimo posebnosti SQL za različne različice iste baze podatkov. Ključne besede so na novo opredeljene in poizvedbe, ki so delovale v eni različici, ne bodo delovale z drugo.
NoSQL je še bolj skrivnosten. To je kot babilonski stolp. Že od začetka so si razvijalci NoSQL skušali predstavljati najboljši možni jezik, vendar imajo zelo različne domišljije. To žarišče eksperimentiranja je dobro - dokler ne poskušate skakati med orodji. Poizvedba za CouchDB je izražena kot par funkcij JavaScript za preslikavo in zmanjšanje. Zgodnje različice Cassandre so uporabljale surovi API nizke ravni, imenovan Thrift; novejše različice ponujajo CQL, SQL-podobnemu poizvedbenemu jeziku, ki ga mora strežnik razčleniti in razumeti. Vsak je po svoje drugačen.
Vsako orodje nima samo svojih posebnosti, temveč ima povsem drugačno filozofijo in način izražanja. Ni preprostih načinov za preklapljanje med shrambami podatkov in pogosto ostanete, da napišete tone kode lepila samo zato, da si v prihodnosti omogočite preklop. To morda ni preveč težko, če v sistem vstavljate pare ključev in vrednosti, lahko pa narašča, kar otežuje večjo zapletenost, ki jo uvajate.
NoSQL trda resnica št. 5: Prilagodljivost sheme je težava, ki čaka, da se zgodi
Ena odličnih idej iz modela NoSQL ne zahteva sheme. Z drugimi besedami, programerjem ni treba vnaprej odločiti, kateri stolpci bodo na voljo za vsako vrstico v tabeli. En vnos ima lahko priloženih 20 nizov, drugi ima lahko 12 celih števil, drugi pa je lahko popolnoma prazen. Programerji se lahko odločijo vsakič, ko morajo nekaj shraniti. Za dodajanje novega stolpca jim ni treba prositi dovoljenja DBA in jim ni treba izpolniti vseh dokumentov.
Vsa ta svoboda zveni opojno in v pravih rokah lahko pospeši razvoj. Toda ali je res dobra ideja za bazo podatkov, ki bi lahko preživela tri skupine razvijalcev? Ali je sploh izvedljivo za bazo podatkov, ki bi lahko trajala dlje kot šest mesecev?
Z drugimi besedami, razvijalci bi si morda želeli svobodo metanja katerega koli starega para v bazo podatkov, toda ali želite biti peti razvijalec, ki se je pojavil po tem, ko so štirje izbrali lastne ključe? Preprosto si je predstavljati različne predstavitve "rojstnega dne", pri čemer vsak razvijalec izbere svojo predstavitev kot ključ, ko vnosu doda uporabnikov rojstni dan. Skupina razvijalcev si lahko predstavlja skoraj vse: "bday", "b-day", "birthday".
Struktura NoSQL ne ponuja nobene podpore za omejevanje te težave, ker bi to pomenilo novo sliko sheme. Noče biti oster na milost popolnoma kul razvijalcev. Shema bi se ovirala.
Dejstvo je, da dodajanje stolpca v tabelo ni velika težava, disciplina pa bi dejansko lahko koristila razvijalcu. Tako kot pomaga prisiliti razvijalce, da določijo spremenljive tipe, pomaga tudi razvijalcem, da določijo vrsto podatkov, ki so priloženi stolpcu. Da, DBA lahko razvijalca prisili, da izpolni obrazec v treh izvodih, preden pritrdi ta stolpec, vendar ni tako slabo, kot da bi imel opravka s pol ducata različnih tipk, ki jih je sproti ustvaril programer.
NoSQL trda resnica št. 6: Brez dodatkov
Recimo, da ne želite vseh podatkov v vseh vrsticah in želite vsoto enega stolpca. Uporabniki SQL lahko izvedejo poizvedbo z operacijo SUM in vam pošljejo eno - samo eno - številko.
Uporabniki NoSQL dobijo vse podatke, ki jim jih pošljejo nazaj, nato pa lahko dodajo sami. Dodatek ni težava, ker traja približno toliko časa, da seštejete številke na katerem koli računalniku. Vendar pa je pošiljanje podatkov naokoli počasno in pasovna širina, potrebna za pošiljanje vseh teh podatkov, je lahko draga.
V zbirkah podatkov NoSQL je malo dodatkov. Če želite storiti kaj drugega kot shraniti in pridobiti podatke, boste to verjetno storili sami. V mnogih primerih boste to storili na drugem računalniku s popolno kopijo podatkov. Prava težava je v tem, da je pogosto koristno opraviti vse izračune na stroju, ki hrani podatke, ker pošiljanje podatkov zahteva čas. Ampak težko zate.
Pojavljajo se rešitve NoSQL. Struktura poizvedbe Map and Reduce iz MongoDB vam daje poljubno strukturo JavaScript za vrenje podatkov. Hadoop je močan mehanizem za distribucijo računanja po svežnju strojev, ki hrani tudi podatke. Je hitro razvijajoča se struktura, ki ponuja hitro izboljšana orodja za izdelavo izpopolnjene analize. Je zelo kul, a vseeno nov. In tehnično je Hadoop povsem drugačna modna beseda kot NoSQL, čeprav razlika med njima bledi.
NoSQL trda resnica št. 7: Manj orodij
Seveda lahko vaš NoSQL postavi v strežnik in ga zažene. Seveda lahko napišete svojo kodo po meri, s katero potisnete in povlečete podatke iz sklada. Kaj pa, če želite narediti več? Kaj, če želite kupiti enega od teh modnih paketov poročanja? Ali pa grafični paket? Ali pa prenesti nekaj odprtokodnih orodij za ustvarjanje grafikonov?
Žal je večina orodij napisana za zbirke podatkov SQL. Če želite ustvariti poročila, ustvariti grafikone ali narediti nekaj z vsemi podatki v vašem skladu NoSQL, boste morali začeti s kodiranjem. Standardna orodja so pripravljena za lovljenje podatkov iz Oracle, Microsoft SQL, MySQL in Postgres. Vaši podatki so v NoSQL? Delajo na tem.
In še malo se bodo potrudili. Tudi če skočijo skozi vse obroče, da bi vstali in zagnali eno od baz podatkov NoSQL, bodo morali znova začeti znova, da bodo lahko upravljali naslednji sistem. Na voljo je več kot 20 različnih izbir NoSQL, vse pa imajo svojo filozofijo in svoj način dela s podatki. Izdelovalci orodij so bili dovolj težko podpirati posebnosti in nedoslednosti v SQL, še bolj zapleteno pa je, da orodja delujejo z vsakim pristopom NoSQL.
To je težava, ki bo počasi izginila. Razvijalci lahko zaznajo navdušenje nad NoSQL in bodo prilagodili svoja orodja za delo s temi sistemi, vendar bo trajalo nekaj časa. Mogoče bodo potem začeli na MongoDB, kar vam ne bo pomagalo, ker vodite Cassandro. Standardi pomagajo v takih situacijah, NoSQL pa ni pomemben za standarde.
Na kratko pomanjkljivosti NoSQL
Vse te pomanjkljivosti NoSQL lahko zreduciramo na eno preprosto izjavo: NoSQL hitrost odvrže od funkcionalnosti. Če funkcije ne potrebujete, boste v redu, če pa jo boste potrebovali v prihodnosti, vam bo žal.
Revolucije so značilne za tehnično kulturo. Pride nova skupina, ki se sprašuje, zakaj je zadnja generacija zgradila nekaj tako zapletenega, in so se lotili rušenja starih institucij. Čez nekaj časa se začnejo zavedati, zakaj so bile vse stare institucije tako zapletene, in znova začnejo izvajati funkcije.
To vidimo v svetu NoSQL, saj nekateri projekti začnejo dodajati stvari, ki so videti kot transakcije, sheme in standardi. To je narava napredka. Stvari rušimo samo zato, da jih spet zgradimo nazaj. NoSQL je končal s prvo fazo revolucije in zdaj je čas za drugo. Kralj je mrtev. Naj živi kralj.
Povezani članki
- NoSQL izstopa: nove zbirke podatkov za nove aplikacije
- Prvi pogled: Oracle NoSQL Database
- Napenjanje NoSQL: pregled MongoDB
- 10 bistvenih nasvetov za zmogljivost MySQL
- 10 osnovnih orodij MySQL za skrbnike
- Obvladajte MySQL v Amazonovem oblaku
- Čas za standarde NoSQL je zdaj
Ta zgodba, "7 trdnih resnic o revoluciji NoSQL," je bila prvotno objavljena na .com. Spremljajte najnovejša dogajanja na področju upravljanja podatkov na .com. Za najnovejši razvoj novosti o poslovnih tehnologijah sledite .com na Twitterju.
