Módní slovo NoSQL metastázuje již několik let. Vzrušení z těchto rychlých datových úložišť bylo opojné a my jsme stejně vinni jako kdokoli, kdo viděl průkopnickou přitažlivost NoSQL. Líbánky se přesto chýlí ke konci a je načase začít vyvažovat naše nadšení několika tvrdými pravdami s nepatrným pohledem.
Nechápejte nás špatně. Stále běžíme, abychom vyzkoušeli nejnovější experiment v budování jednoduchého mechanismu pro ukládání dat. Stále najdeme hlubokou hodnotu v MongoDB, CouchDB, Cassandra, Riak a dalších standartech NoSQL. Stále plánujeme hodit některá z našich nejdůvěryhodnějších dat do těchto hromádek kódu, protože každým dnem rostou a jsou stále více testovány.
[Také na: NoSQL standouts: Nové databáze pro nové aplikace | První pohled: Oracle NoSQL Database | Získejte přehled klíčových příběhů každý den v denním zpravodaji. ]
Ale začínáme pociťovat odření, protože systémy NoSQL nejsou ani zdaleka dokonalé, a často se třou špatně. Nejchytřejší vývojáři to věděli od začátku. Neopálili příručky SQL a neposílali ošklivé programy prodejní síle svého kdysi oddaného prodejce SQL. Ne, inteligentní vývojáři NoSQL jednoduše poznamenali, že NoSQL znamená „nejen SQL“. Pokud masy nesprávně interpretovaly zkratku, byl to jejich problém.
Tento seznam úchopů, malých i velkých, je tedy pokusem dokumentovat tuto skutečnost a vyčistit vzduch. Má to nyní dát věci do pořádku, abychom mohli lépe porozumět kompromisům a kompromisům.
Tvrdá pravda NoSQL č. 1: PŘIPOJENÍ znamenají konzistenci
Jedním z prvních uzlů, které lidé o systémech SQL mají, jsou výpočetní náklady na provedení spojení mezi dvěma tabulkami. Myšlenkou je ukládat data na jediné místo. Pokud vedete seznam zákazníků, vložíte jejich adresy do jedné tabulky a použijete jejich ID zákazníků do všech ostatních tabulek. Když vytáhnete data, JOIN spojí ID s adresami a vše zůstane konzistentní.
Potíž je v tom, že JOINy mohou být drahé a některé DBA vytvořily složité JOIN příkazy, které zmátly mysl a proměnily i nejrychlejší hardware na kal. Nebylo žádným překvapením, že vývojáři NoSQL změnili svůj nedostatek JOIN na funkci: Udržujme adresu zákazníka ve stejné tabulce jako všechno ostatní! Způsob NoSQL spočívá v ukládání párů klíč – hodnota pro každou osobu. Až přijde čas, všechny je získejte.
Bohužel, lidé, kteří chtějí, aby jejich tabulky byly konzistentní, stále potřebují PŘIPOJENÍ. Jakmile začnete ukládat adresy zákazníků se vším ostatním, často v každé tabulce skončíte s více kopiemi těchto adres. A pokud máte více kopií, musíte je aktualizovat všechny najednou. Někdy to funguje, ale když ne, NoSQL není připraven pomoci s transakcemi.
Počkejte, řeknete si, proč nemáte samostatnou tabulku s informacemi o zákazníkovi? Tímto způsobem bude možné změnit pouze jeden záznam. Je to skvělý nápad, ale nyní můžete napsat JOIN sami ve své vlastní logice.
Tvrdá pravda NoSQL č. 2: Choulostivé transakce
Řekněme, že je v pořádku žít bez PŘIPOJOVÁNÍ stolů, protože chcete rychlost. Je to přijatelné kompromis a někdy SQL DBA denormalizují tabulky právě z tohoto důvodu.
Problém je v tom, že NoSQL ztěžuje udržování konzistentních různých položek. Často neexistují žádné transakce, které by zajistily, že se změny ve více tabulkách provedou společně. Za to jste sami a selhání by mohlo zajistit, že se tabulky změní v nekonzistenci.
Nejstarší implementace NoSQL se při těchto transakcích oháněly nosem. Nabídli by výpisy dat, které byly konzistentní, kromě případů, kdy tomu tak nebylo. Jinými slovy, šli po datech s nejnižší hodnotou, kde by chyby nezpůsobily žádný podstatný rozdíl.
Nyní některé implementace NoSQL nabízejí něco blížící se transakci. Například produkt Oracle NoSQL nabízí transakční kontrolu nad daty zapsanými do jednoho uzlu a umožňuje vám zvolit flexibilní míru konzistence mezi více uzly. Pokud chcete dokonalou konzistenci, musíte počkat, až se každý zápis dostane do všech uzlů. Několik dalších úložišť dat NoSQL experimentuje s přidáním další struktury a ochrany, jako je tato.
Pravda NoSQL č. 3: Databáze mohou být chytré
Mnoho programátorů NoSQL se rád chlubí tím, jak jejich lehký kód a jednoduchý mechanismus fungují extrémně rychle. Obvykle mají pravdu, když jsou úkoly stejně jednoduché jako vnitřek NoSQL, ale to se změní, když se problémy zkomplikují.
Zvažte starou výzvu PŘIPOJENÍ. Jakmile programátoři NoSQL začnou generovat své vlastní příkazy JOIN ve své vlastní logice, začnou se o to snažit efektivně. Vývojáři SQL strávili desítky let vývojem sofistikovaných modulů pro co nejefektivnější zpracování příkazů JOIN. Jeden vývojář SQL mi řekl, že se pokouší synchronizovat svůj kód s rotujícím pevným diskem, takže bude požadovat data, pouze když bude hlava těsně nad správným místem. To se může zdát extrémní, ale vývojáři SQL pracují na podobných hackech po celá desetiletí.
Není pochyb o tom, že programátoři tráví dny vytrháváním vlasů tím, že se snaží strukturovat své dotazy SQL, aby využili všechnu tuto latentní inteligenci. Možná to nebude jednoduché poklepat, ale když to programátor zjistí, databáze mohou opravdu zpívat.
Sofistikovaný dotazovací jazyk, jako je SQL, má vždy potenciál zastínit nekomplikovaný dotazovací jazyk, jaký se nachází v NoSQL. Na jednoduchých výsledcích to nemusí vadit, ale když se akce stane složitou, bude se SQL na stroji provádět hned vedle dat. Má malou režii načítání dat a dělá práci. Server NoSQL obvykle musí dodávat data tam, kam směřuje.
Tvrdá pravda NoSQL č. 4: Příliš mnoho přístupových modelů
Teoreticky má být SQL standardní jazyk. Pokud používáte SQL pro jednu databázi, měli byste být schopni spustit stejný dotaz v jiné kompatibilní verzi. Toto tvrzení může fungovat s několika jednoduchými dotazy, ale každý DBA ví, že to může trvat roky, než se naučíte idiosyncrasies SQL pro různé verze stejné databáze. Klíčová slova jsou předefinována a dotazy, které fungovaly na jedné verzi, nebudou fungovat s jinou.
NoSQL je ještě tajemnější. Je to jako Babylonská věž. Od začátku se vývojáři NoSQL snažili představit si nejlepší možný jazyk, ale mají velmi odlišné představy. Toto pole experimentů je dobré - dokud se nepokoušíte skákat mezi nástroji. Dotaz na CouchDB je vyjádřen jako dvojice funkcí JavaScriptu pro mapování a redukci. Dřívější verze Cassandry používaly surové, nízkoúrovňové API zvané Thrift; novější verze nabízejí CQL, dotazovací jazyk podobný SQL, který musí server analyzovat a rozumět mu. Každý je svým způsobem odlišný.
Každý nástroj nemá jen své vlastní výstřednosti, ale má zcela jinou filozofii a způsob jeho vyjádření. Neexistují žádné snadné způsoby, jak přepínat mezi datovými úložišti, a často vám zbývá psát spoustu lepicího kódu, jen abyste si v budoucnu mohli přepnout. To nemusí být příliš obtížné, když do systému vkládáte páry klíčů a hodnot, ale může to čím dál tím více zhoršovat složitost, kterou zavedete.
Tvrdá pravda NoSQL č. 5: Flexibilita schématu je problém čekající na to, až se stane
Jedním ze skvělých nápadů z modelu NoSQL není vyžadování schématu. Jinými slovy, programátoři se nemusí předem rozhodovat, které sloupce budou k dispozici pro každý řádek v tabulce. K jedné položce může být připojeno 20 řetězců, další může mít 12 celých čísel a další může být zcela prázdná. Programátoři se mohou rozhodnout, kdykoli potřebují něco uložit. Nemusí žádat o povolení DBA a nemusí vyplňovat všechny doklady, aby přidali nový sloupec.
Celá ta svoboda zní opojně a ve správných rukou může urychlit vývoj. Ale je to opravdu dobrý nápad pro databázi, která by mohla žít přes tři týmy vývojářů? Je to vůbec proveditelné pro databázi, která může trvat déle než šest měsíců?
Jinými slovy, vývojáři možná chtějí svobodu hodit jakýkoli starý pár do databáze, ale chcete být pátým vývojářem, který přijde poté, co si čtyři vybrali své vlastní klíče? Je snadné si představit různé reprezentace „narozenin“, kdy si každý vývojář jako klíč při výběru narozenin uživatele k záznamu zvolí vlastní reprezentaci. Tým vývojářů si může představit téměř cokoli: „bday“, „b-day“, „birthday“.
Struktura NoSQL nenabízí žádnou podporu pro omezení tohoto problému, protože by to znamenalo reimagining schématu. Nechce to tvrdě mluvit o náladě naprosto skvělých vývojářů. Do cesty by se dostalo schéma.
Faktem je, že přidání sloupce do tabulky není velký problém a disciplína může být pro vývojáře skutečně dobrá. Stejně jako pomáhá přinutit vývojáře k označení typů proměnných, pomáhá také přinutit vývojáře k určení typu dat připojených ke sloupci. Ano, DBA může přinutit vývojáře, aby před připojením tohoto sloupce vyplnil formulář v trojím vyhotovení, ale není to tak špatné jako vypořádat se s půl tuctem různých klíčů vytvořených za běhu programátorem.
Tvrdá pravda NoSQL č. 6: Žádné doplňky
Řekněme, že nechcete všechna data ve všech řádcích a chcete součet jednoho sloupce. Uživatelé SQL mohou provést dotaz pomocí operace SUMA a poslat vám jedno - jen jedno - číslo zpět.
Uživatelé NoSQL získají všechna data odeslaná zpět a mohou si pak sami provést přidání. Přidání není problém, protože sečtení čísel na libovolném stroji trvá přibližně stejně dlouho. Odesílání dat kolem je však pomalé a šířka pásma potřebná k odeslání všech těchto dat může být drahá.
V databázích NoSQL je několik doplňků. Pokud chcete dělat cokoli jiného než ukládat a načítat data, pravděpodobně to uděláte sami. V mnoha případech to uděláte na jiném počítači s kompletní kopií dat. Skutečným problémem je, že může být často užitečné provést veškerý výpočet na stroji, který uchovává data, protože odeslání dat nějakou dobu trvá. Ale pro tebe těžké.
Objevují se řešení NoSQL. Struktura dotazu Map and Reduce z MongoDB vám poskytuje libovolnou strukturu JavaScriptu pro zchlazení dat. Hadoop je výkonný mechanismus pro distribuci výpočtů do celé řady strojů, které také obsahují data. Jedná se o rychle se rozvíjející strukturu, která nabízí rychle se zlepšující nástroje pro vytváření sofistikovaných analýz. Je to velmi cool, ale stále nové. A technicky je Hadoop zcela odlišným módním slovem než NoSQL, i když rozdíl mezi nimi mizí.
Tvrdá pravda NoSQL č. 7: Méně nástrojů
Jistě, můžete na svém serveru spustit a spustit svůj NoSQL stack. Jistě, můžete napsat svůj vlastní vlastní kód, abyste mohli data ze zásobníku odeslat a vytáhnout. Ale co když chcete udělat víc? Co když si chcete koupit jeden z těch efektních balíčků zpráv? Nebo grafický balíček? Nebo si stáhnout nějaké open source nástroje pro vytváření grafů?
Je nám líto, většina nástrojů je napsána pro databáze SQL. Pokud chcete generovat zprávy, vytvářet grafy nebo něco dělat se všemi daty v zásobníku NoSQL, budete muset začít kódovat. Standardní nástroje jsou připraveny zachytit data z Oracle, Microsoft SQL, MySQL a Postgres. Vaše data jsou v NoSQL? Pracují na tom.
A budou na tom trochu pracovat. I když přeskočí všechny obruče, aby se dostali do provozu s jednou z databází NoSQL, budou muset začít znovu od začátku, aby zvládli další systém. Existuje více než 20 různých možností NoSQL, z nichž všechny mají vlastní filozofii a vlastní způsob práce s daty. Pro výrobce nástrojů bylo dost těžké podporovat idiosynkrázy a nekonzistence v SQL, ale je ještě komplikovanější, aby nástroje fungovaly s každým přístupem NoSQL.
To je problém, který pomalu zmizí. Vývojáři cítí vzrušení v NoSQL a budou upravovat své nástroje, aby s těmito systémy pracovali, ale bude to chvíli trvat. Možná pak začnou na MongoDB, což vám nepomůže, protože používáte Cassandru. Standardy pomáhají v takových situacích a NoSQL není na standardech velký.
Stručně řečeno, nedostatky NoSQL
Všechny tyto nedostatky NoSQL lze snížit na jedno jednoduché prohlášení: NoSQL odhodí funkčnost kvůli rychlosti. Pokud tuto funkci nepotřebujete, budete v pořádku, ale pokud ji v budoucnu budete potřebovat, bude vám to líto.
Revoluce jsou endemické pro technologickou kulturu. Přijde nová skupina, která se diví, proč poslední generace postavila něco tak složitého, a vydala se strhnout staré instituce. Po chvíli si začínají uvědomovat, proč byly všechny staré instituce tak složité, a začnou tyto funkce znovu implementovat.
Vidíme to ve světě NoSQL, protože některé projekty začnou přidávat zpět věci, které vypadají jako transakce, schémata a standardy. To je podstata pokroku. Strháváme věci, jen abychom je znovu postavili. NoSQL je u konce s první fází revoluce a nyní je čas na druhou. Král je mrtvý. Ať žije král.
Související články
- Standouts NoSQL: Nové databáze pro nové aplikace
- První pohled: Oracle NoSQL Database
- Flexing NoSQL: MongoDB in review
- 10 základních tipů na výkon pro MySQL
- 10 základních nástrojů MySQL pro správce
- Zvládněte MySQL v cloudu Amazon
- Nastal čas pro standardy NoSQL
Tento příběh, „7 tvrdých pravd o revoluci NoSQL“, byl původně publikován na .com. Sledujte nejnovější vývoj ve správě dat na .com. Nejnovější informace o novinkách v oblasti podnikových technologií najdete na Twitteru na webu .com.
