Módne slovo NoSQL metastázuje už niekoľko rokov. Nadšenie z týchto rýchlych dátových úložísk bolo opojné a my sme rovnako vinní ako ktokoľvek iný, že sme videli prelomovú príťažlivosť NoSQL. Svadobná cesta sa napriek tomu chýli ku koncu a je čas začať vyvážiť naše nadšenie niekoľkými tvrdými pravdami s miernym pohľadom.
Nechápte nás zle. Stále bežíme vyskúšať najnovší experiment v zostavovaní jednoduchého mechanizmu na ukladanie údajov. Stále nájdeme hlbokú hodnotu v štandardoch MongoDB, CouchDB, Cassandra, Riak a ďalších NoSQL. Stále plánujeme hodiť niektoré z našich najdôveryhodnejších údajov do týchto balíkov kódu, pretože každým dňom rastú a lepšie testujú.
[Tiež na: Štandardy NoSQL: Nové databázy pre nové aplikácie | Prvý pohľad: Oracle NoSQL Database | Získajte denné prehľady hlavných príbehov každý deň v dennom vestníku. ]
Ale začíname pociťovať trenie, pretože systémy NoSQL nie sú ani zďaleka dokonalé a často sa otierajú nesprávnym smerom. Najchytrejší vývojári to vedeli od začiatku. Nespálili príručky SQL a neposlali nastygramy predajnej sile svojho kedysi oddaného predajcu SQL. Nie, inteligentní vývojári NoSQL jednoducho poznamenali, že NoSQL znamená „nielen SQL“. Ak masy nesprávne interpretovali skratku, bol to ich problém.
Tento zoznam malých a veľkých úchopov je teda pokusom o zdokumentovanie tejto skutočnosti a vyčistenie vzduchu. Má to teraz ísť na pravú mieru, aby sme mohli lepšie porozumieť kompromisom a kompromisom.
Tvrdá pravda NoSQL č. 1: PRIPOJENIA znamenajú konzistenciu
Jedným z prvých uzlov, ktoré majú ľudia o systémoch SQL, sú výpočtové náklady na vykonanie spojenia medzi dvoma tabuľkami. Cieľom je uložiť údaje na jednom mieste a iba na jednom mieste. Ak vediete zoznam zákazníkov, umiestnite ich adresy do jednej tabuľky a ich identifikácie zákazníkov použijete v každej druhej tabuľke. Po vytiahnutí údajov JOIN spojí ID s adresami a všetko zostane konzistentné.
Problém je v tom, že JOINy môžu byť drahé a niektoré DBA si vymysleli zložité JOIN príkazy, ktoré zmätia myseľ a premenia aj najrýchlejší hardvér na kal. Nebolo prekvapením, že vývojári NoSQL zmenili svoj nedostatok JOINov na funkciu: Udržujme iba adresu zákazníka v rovnakej tabuľke ako všetko ostatné! Spôsob NoSQL spočíva v ukladaní párov kľúč - hodnota pre každú osobu. Keď na to príde čas, všetky ich vyhľadáte.
Bohužiaľ, ľudia, ktorí chcú, aby boli ich tabuľky konzistentné, stále potrebujú PRIPOJENIA. Len čo začnete ukladať adresy zákazníkov so všetkým ostatným, často sa v nich nachádza viac kópií týchto adries v každej tabuľke. A keď máte viac kópií, musíte ich aktualizovať všetky súčasne. Niekedy to funguje, ale keď nie, NoSQL nie je pripravený pomôcť s transakciami.
Počkajte, poviete si, prečo by ste nemali samostatnú tabuľku s informáciami o zákazníkovi? Takto bude možné zmeniť iba jeden záznam. Je to vynikajúci nápad, ale teraz si môžete zapísať spojenie sami do svojej vlastnej logiky.
Tvrdá pravda č. 2 č. 2: zložité transakcie
Povedzme, že máte v poriadku žiť bez PRIPOJENIA tabuliek, pretože chcete rýchlosť. Je to prijateľný kompromis a niekedy SQL DBA denormalizujú tabuľky práve z tohto dôvodu.
Problém je v tom, že NoSQL sťažuje konzistentnosť rôznych položiek. Často nie sú k dispozícii žiadne transakcie, ktoré by zabezpečili, že zmeny vo viacerých tabuľkách sa vykonajú spoločne. Ste za to sami a zlyhanie by mohlo zaistiť, že tabuľky budú nekonzistentné.
Najstaršie implementácie NoSQL búrali nosom nad týmito transakciami. Ponúkali by zoznamy údajov, ktoré by boli konzistentné, ibaže by neboli. Inými slovami, išli po údajoch s najnižšou hodnotou, kde by chyby nepriniesli žiadny zásadný rozdiel.
Niektoré implementácie NoSQL teraz ponúkajú niečo, čo sa blíži k transakcii. Napríklad produkt Oracle od NoSQL ponúka transakčnú kontrolu nad dátami zapísanými do jedného uzla a umožňuje vám zvoliť si flexibilnú mieru konzistencie medzi viacerými uzlami. Ak chcete dokonalú konzistenciu, musíte počkať, kým sa každý zápis dostane do všetkých uzlov. Niekoľko ďalších dátových skladov NoSQL experimentuje s pridaním ďalšej takejto štruktúry a ochrany.
Pravda NoSQL č. 3: Databázy môžu byť inteligentné
Mnoho programátorov NoSQL sa rád chváli tým, ako ich ľahký kód a jednoduchý mechanizmus fungujú mimoriadne rýchlo. Spravidla majú pravdu, keď sú úlohy také jednoduché ako vnútro NoSQL, ale to sa mení, keď sa problémy zhoršujú.
Zvážte starú výzvu PRIPOJENIA. Len čo programátori NoSQL začnú generovať svoje vlastné príkazy JOIN vo svojej vlastnej logike, začnú sa o to snažiť efektívne. Vývojári SQL strávili desaťročia vývojom sofistikovaných nástrojov na čo najefektívnejšie spracovanie príkazov JOIN. Jeden vývojár SQL mi povedal, že sa snaží synchronizovať svoj kód s rotujúcim pevným diskom, aby požadoval údaje, iba keď je hlava tesne nad správnym miestom. Môže sa to zdať extrémne, ale vývojári SQL pracujú na podobných hackeroch už celé desaťročia.
Niet pochýb o tom, že programátori trávia dni vyťahovaním vlasov, keď sa snažia štruktúrovať svoje dotazy SQL, aby využili všetky výhody tejto latentnej inteligencie. Možno to nebude jednoduché ťuknúť, ale keď to programátor zistí, databázy môžu naozaj spievať.
Sofistikovaný dotazovací jazyk ako SQL má vždy potenciál prekonať nenáročný dopytovací jazyk, aký sa nachádza v NoSQL. S jednoduchými výsledkami to nemusí mať význam, ale keď sa akcia stane zložitou, vykoná sa na stroji SQL hneď vedľa údajov. Má malú réžiu pri načítaní údajov a vykonaní práce. Server NoSQL musí zvyčajne odosielať údaje tam, kam smerujú.
Tvrdá pravda NoSQL č. 4: Príliš veľa prístupových modelov
Teoreticky sa predpokladá, že SQL je štandardný jazyk. Ak používate SQL pre jednu databázu, mali by ste byť schopní spustiť ten istý dotaz v inej kompatibilnej verzii. Toto tvrdenie môže fungovať s niekoľkými jednoduchými dotazmi, ale každý správca databáz DBA vie, že môže trvať roky, kým sa naučíte výstredné výrazy jazyka SQL pre rôzne verzie tej istej databázy. Kľúčové slová sú predefinované a dotazy, ktoré fungovali na jednej verzii, nebudú fungovať s druhou.
NoSQL je ešte tajomnejšia. Je to ako Babylonská veža. Od začiatku sa vývojári NoSQL snažili predstaviť si čo najlepší jazyk, ale predstavy majú veľmi odlišné. Táto ohnisko experimentov je dobrá - kým sa nepokúsite skákať medzi nástrojmi. Dotaz na CouchDB je vyjadrený ako dvojica funkcií JavaScriptu na mapovanie a redukciu. Prvé verzie Cassandry používali surové API nízkej úrovne s názvom Thrift; novšie verzie ponúkajú CQL, dotazovací jazyk podobný SQL, ktorý musí server analyzovať a rozumieť mu. Každá je svojim spôsobom iná.
Každý nástroj nemá iba svoje vlastné výstrednosti, ale má aj úplne inú filozofiu a spôsob vyjadrenia. Nie sú ľahké spôsoby prepínania medzi dátovými skladmi a často vám zostáva písanie ton kódu na lepenie, aby ste si v budúcnosti mohli prepnúť. To nemusí byť príliš ťažké, keď do systému vložíte páry kľúčov a hodnôt, ale čoraz zložitejšie to môže predstavovať čoraz väčšie stupňovanie.
Tvrdá pravda NoSQL č. 5: Flexibilita schémy je problém čakajúci na svoje uskutočnenie
Jeden z vynikajúcich nápadov z modelu NoSQL nevyžaduje schému. Inými slovami, programátori sa nemusia vopred rozhodovať, ktoré stĺpce budú k dispozícii pre každý riadok v tabuľke. Jeden záznam môže mať pripojených 20 reťazcov, ďalší môže mať 12 celých čísel a ďalší môže byť úplne prázdny. Programátori sa môžu rozhodnúť, kedykoľvek potrebujú niečo uložiť. Na pridanie nového stĺpca nepotrebujú povolenie DBA a nevyplňujú všetky doklady.
Celá táto sloboda znie opojne a v správnych rukách môže urýchliť vývoj. Ale je to naozaj dobrý nápad pre databázu, ktorá by mohla žiť cez tri tímy vývojárov? Je to vôbec možné pre databázu, ktorá by mohla trvať dlhšie ako šesť mesiacov?
Inými slovami, vývojári môžu chcieť slobodu prihodiť akýkoľvek starý pár do databázy, ale chcete byť piatym vývojárom, ktorý príde po tom, čo si štyria vyberú svoje vlastné kľúče? Je ľahké si predstaviť rôzne reprezentácie „narodenín“, keď si každý vývojár zvolí svoje vlastné zastúpenie ako kľúč pri pridávaní narodenín používateľa k záznamu. Tím vývojárov by si mohol predstaviť takmer čokoľvek: „bday“, „b-day“, „birthday“.
Štruktúra NoSQL neposkytuje žiadnu podporu na obmedzenie tohto problému, pretože by to znamenalo reimagining schémy. Nechce to tvrdo rozprávať s úplne super vývojármi. Do cesty by sa dostala schéma.
Faktom je, že pridanie stĺpca do tabuľky nie je veľký problém a disciplína môže byť pre vývojára skutočne dobrá. Rovnako ako pomáha vývojárom nútiť označovať typy premenných, pomáha vývojárom určovať typ údajov pripojených k stĺpcu. Áno, DBA môže vývojára prinútiť, aby pred pripojením tohto stĺpca vyplnil formulár v troch vyhotoveniach, ale nie je to také zlé ako zaoberať sa poltuctom rôznych kľúčov vytvorených za chodu programátorom.
Tvrdá pravda NoSQL č. 6: Žiadne doplnky
Povedzme, že nechcete všetky údaje vo všetkých riadkoch a chcete súčet jedného stĺpca. Používatelia SQL môžu vykonať dopyt pomocou operácie SUM a poslať vám jedno - iba jedno - číslo späť.
Používatelia NoSQL dostávajú všetky dáta dodané späť k nim a môžu si potom sami urobiť doplnenie. Sčítanie nie je problémom, pretože spočítanie čísel na ľubovoľnom stroji trvá približne rovnako dlho. Doručovanie údajov je však pomalé a šírka pásma potrebná na odoslanie všetkých týchto údajov môže byť drahá.
V databázach NoSQL je niekoľko doplnkov. Ak chcete robiť čokoľvek okrem ukladania a načítania údajov, pravdepodobne to urobíte sami. V mnohých prípadoch to urobíte na inom počítači s úplnou kópiou údajov. Skutočným problémom je, že môže byť často užitočné vykonať všetok výpočet na stroji, ktorý uchováva údaje, pretože odoslanie údajov si vyžaduje čas. Ale ťažké pre vás.
Objavujú sa riešenia NoSQL. Štruktúra dotazu Map and Reduce od MongoDB vám poskytuje ľubovoľnú štruktúru JavaScriptu na varenie údajov. Hadoop je výkonný mechanizmus na distribúciu výpočtov v rade strojov, ktoré tiež uchovávajú údaje. Jedná sa o rýchlo sa rozvíjajúcu štruktúru, ktorá ponúka rýchlo sa zlepšujúce nástroje na vytváranie sofistikovaných analýz. Je to veľmi cool, ale stále nové. A technicky je Hadoop úplne iné módne slovo ako NoSQL, aj keď rozdiel medzi nimi sa vytráca.
Tvrdá pravda NoSQL č. 7: Menej nástrojov
Iste môžete svoj server NoSQL na serveri spustiť a spustiť. Iste, môžete napísať svoj vlastný vlastný kód, pomocou ktorého budete dáta zo zásobníka tlačiť a vyberať. Čo však v prípade, že chcete urobiť viac? Čo ak si chcete kúpiť jeden z tých efektných balíkov správ? Alebo grafický balík? Alebo si stiahnuť nejaké open source nástroje na tvorbu grafov?
Je nám ľúto, väčšina nástrojov je určená pre databázy SQL. Ak chcete generovať prehľady, vytvárať grafy alebo robiť niečo so všetkými údajmi v zásobníku NoSQL, budete musieť začať programovať. Štandardné nástroje sú pripravené na zachytenie údajov z databáz Oracle, Microsoft SQL, MySQL a Postgres. Vaše údaje sú v NoSQL? Pracujú na tom.
A budú na tom trochu pracovať. Aj keď preskočia všetky obruče, aby sa dostali do chodu s jednou z databáz NoSQL, budú musieť začínať odznova, aby zvládli ďalší systém. Existuje viac ako 20 rôznych možností NoSQL, z ktorých všetky majú vlastnú filozofiu a vlastný spôsob práce s údajmi. Pre tvorcov nástrojov bolo dosť ťažké podporiť výstrednosti a nekonzistencie v SQL, ale je ešte komplikovanejšie zabezpečiť, aby nástroje fungovali pri každom prístupe NoSQL.
Toto je problém, ktorý pomaly zmizne. Vývojári môžu v NoSQL vycítiť vzrušenie a budú upravovať svoje nástroje tak, aby fungovali s týmito systémami, ale bude to chvíľu trvať. Možno potom začnú na MongoDB, čo vám nepomôže, pretože máte spustenú Cassandru. Normy pomáhajú v takýchto situáciách a NoSQL nie je veľký v štandardoch.
Stručne povedané, nedostatky NoSQL
Všetky tieto nedostatky NoSQL možno znížiť na jedno jednoduché vyhlásenie: NoSQL zahodí rýchlosť kvôli rýchlosti. Ak túto funkciu nepotrebujete, budete v poriadku, ale ak ju budete v budúcnosti potrebovať, bude vám to ľúto.
Revolúcie sú endemitom technologickej kultúry. Príde nová skupina, ktorá sa čuduje, prečo posledná generácia postavila niečo také zložité, a vydala sa zbúrať staré inštitúcie. Po chvíli si začnú uvedomovať, prečo boli všetky staré inštitúcie také zložité, a znova začnú tieto funkcie implementovať.
Vidíme to vo svete NoSQL, pretože niektoré projekty začínajú pridávať späť veci, ktoré vyzerajú ako transakcie, schémy a štandardy. To je podstata pokroku. Strhávame veci, len aby sme ich opäť postavili späť. NoSQL je hotové s prvou fázou revolúcie a teraz je čas na druhú. Kráľ je mŕtvy. Nech žije kráľ.
Súvisiace články
- Štandardy NoSQL: Nové databázy pre nové aplikácie
- Prvý pohľad: Oracle NoSQL Database
- Prebieha ohýbanie NoSQL: MongoDB
- 10 základných tipov na výkon pre MySQL
- 10 základných nástrojov MySQL pre správcov
- Ovládnite MySQL v cloude Amazon
- Nastal čas pre štandardy NoSQL
Tento príbeh, „7 tvrdých právd o revolúcii NoSQL“, bol pôvodne publikovaný na .com. Sledujte najnovší vývoj v správe údajov na .com. Najnovší vývoj v oblasti obchodných technologických noviniek nájdete na serveri .com na Twitteri.
