NoSQL databaze jsou vzasade hashtabulka. Mne u cassandry vadi ze nema atomicke updaty pres vice CF. Atomicke updaty ma jen na urovni radky. Proste je to urcene pro aplikace kde nekonzistence dat nevadi. V pripade ze vadi je potreba nasadit zookeeper. Lepsi by bylo kdyby to bylo zabudovane.

Cassandra je dobra pro aplikace co hodne zapisuji a malo ctou. Cteni z cassandry je opravdu relativne dost pomaly, tam se musi nastavit server side cache u CF aby to nejak rozumne behalo. Efektivita cteni z disku je ale stejna jako u DB2. Kdyz se db2 vypne cache a leze primo na disk tak cte vicemene stejne rychle jako cassandra, takze cassandra nema nejaky obzvlaste pomaly algoritmus pro nacitani z disku, jen ji ale zdrzuje ze cte z vice serveru soucasne a porovnava si co odkud precetla.

Cassandra je shared nothing architektura. Podobnou architekturu ma i DB2 DPF.

Cassandra je opravdu dobra nosql, protoze umi skalovatelnost pres vice stroju a ne jenom replikaci. Dalsi z vyhod je jeji nulova cena oproti resenim typu DB2. Rozhodne je ale lepsi relacni model nez hashtabulka, lepe se s nim pracuje v aplikaci a jsou na to ORM,

Ne, že by NoSQL databáze neměly uplatnění (už jsem o tom psal v blogu), ale ty nevýhody SQL prezentované v tomto článku se mi zdají trochu zvláštní.

Ad „Při vytvoření tabulky se určují typ ukládaných dat v jednotlivých sloupcích a počet sloupců.“

Což je podle mého velký výhoda – člověk ví, co v DB má, jakou strukturu data mají, že tam není zbytečný bordel (např. text tam, kde má být číslo, delší řetězce než očekávám atd.). Navíc relační databáze umožňují mít výhody obojího – co jde strukturovat, to bude ve sloupcích a co má volnou a předem nedefinovanou strukturu bude uložené třeba jako XML nebo blob v jednom sloupečku. Ten nejjednodušší příklad, kdy se to používá: redakční systémy, kde máme autora, datum vydání, kategorie hezky strukturované a vedle toho text článku celý v jednom poli – sice nějakou vnitřní strukturu má (složitou, hierarchickou, předem neznámou), ale to na úrovni relační DB neřešíme.

Ad „V SQL se dají zapsat náročné dotazy, které mnohdy dokáží přetížit databázi.“

A v libovolném programovacím jazyce můžeme napsat nekonečný cyklus, který přetíží počítač…

Ad „Možnosti SQL jsou velmi rozsáhlé. Tato komplexnost ztěžuje optimalizaci enginu databáze na právě ty dotazy, které jsou ve zvoleném způsobu nasazení skutečně potřeba.“ a „Při založení tabulky nemůžeme rovnou omezit množinu přípustných dotazů nad tabulkou a tím umožnit lepší optimalizace omezené množiny použitých dotazů.“

Tahle optimalizace pro konkrétní, předem známé, dotazy se dělá pomocí indexů případně materializovaných pohledů – zároveň nám to ale nebrání databázi pokládat předem neznámé dotazy, na které jsme ji nemuseli nijak připravovat.

Ad „U konkrétních tabulek není možné snížit požadavky na model konzistence dat…“

Jde, ale mimo databázi, na úrovni middlewaru. Tohle je téma na celý článek…

Ad „Předávání textových řetězců vycházejících z přirozeného jazyka rozhodně není nejefektivnějším způsobem komunikace mezi klientem a serverem.“

NoSQL databáze zase často používají pro přenos HTTP protokol a sestavovat kvůli každému dotazu HTTP hlavičky taky není žádná sláva a velká efektivita. Nemluvě o různých binárních dumpech, skrz které se z/do SQL databáze dá protlačit opravdu hodně dat.

Souhlasím s tvojí reakci na "nevýhody SQL" prezentované v tomto článku. Je škoda, že skoro vždy, když se hovoří od NoSQL, tak se autor pokusí očernit SQL. Škoda.

Měl bych jen poznámku k použití HTTP. Ono to má svůj smysl. Je to rozšířený protokol, můžeš na to používat běžné nástroje. Jako třeba cachující proxy. Snadno tak posílíš výkon DB.

Ještě bych měl poznámku k vybavení NoSQL DB. Na první pohled vypadá krásně, když DB poskytuje API, které nemožní dělat pomalé operace. No jenže..., kde se s těmi daty bude pracovat? V pomalém interpretovaném jazyku a bude to dělat webový programátor.

Výsledek je tedy ten, že operaci nedělá vyspělá vrstva, na které pracovalo mnoho špičkových programátorů, která je široce otestovaná a tak rychlá, jak to jen jde;; ale tuto operaci s těmi daty naprogramuje člověk, který ani neumí navrhnout DB schéma. Nemyslím si, že by to byla nějaká výhra.

Tím nechci nikoho urazit. Distribuovaná hashovací tabulka má své přednosti a své nenahraditelné použití. Takže ano, vyspělý programátorský tým, který si umí navrhnout vlastní strukuru dat a vlastní transformace, testy a všechno, může z NoSQL vytěžit maximum. Ale pro většinu ostatních si myslím, že je mnohem rozumnejší se naučit vytvářet schemata pomocí normálních forem a nad tím psát optimální dotazy. Takhle rychlé ty jejich vlastní produkty nad NoSQL nikdy nebudou.

Souhlasím s tím, že už mě unavuje, když každá neSQL databáze začne tím, že SQL databáze jsou špatné.

Asi je to klasika, že dnes každý autor o něčem píšící musí nejdříve něco pohanět.

Ze s daty z NoSQL pracuje pomaly kod v PHP? A co pracuje s daty ktere se prectou ze SQL databaze? Ten samy kod.

Navrhovat schema pro NoSQL databazi je tezsi nez pro SQL databazi. Musi se navrhovat podle dotazu ktere budou potreba. U SQL se to navrhne podle struktury dat, dotazy jdou nam tim delat vicemene uz libovolne.

NoSQL databaze je proste hastabulka, kde se neresi konzistence dat a relace. Pro vetsinu webovek to nevadi, ty pouzivaji velmi jednoduchy datovy model (max 10 tabulek). Vyhody NoSQL jsou ze je to levnejsi skalovatelne reseni nez za pouziti SQL databazi. Pokud se nepredpoklada ze tech dat bude ale opravdu hodne a rozpocet maly, tak je SQL databaze lepsi - umi toho vic.

NOSQL jsou jednodusi a tak se lepe skaluji pres vice stroju zejmena protoze nezarucuji synchronizaci dat. I kdyz nektere NOSQL databaze synchronizaci dat zarucuji, ale zase za cenu nizsi skalovatelnosti.

Kdo z vas co tohle kritizujete s tim opravdu nekdy delal?

> Ze s daty z NoSQL pracuje pomaly kod v PHP?
> A co pracuje s daty ktere se prectou ze SQL databaze?
> Ten samy kod.

To ale není celá pravda. Zatímto v SQL budu mít (optimálně ;-)) napsaný dotaz jehož výsledkem bude (by měla být ;-)) pouze ta informace, kterou program potřebuje, tak ten s tím dále již nemá práci (všechno zpracovala DB vrstva tak rychle, jak to jen jde). Zatímto pokud si někdo bude hrát s těmi daty sám v PHP, tak rozhodně nejsem přesvědčen, že ty algoritmy bude znát stejně dobře, jako programátoři "velkých" DB.

> Navrhovat schema pro NoSQL databazi je tezsi nez pro SQL databazi.

No právě. Když vidím to bezbřehé nadšení mladých začínající programátorů, kteří po prvním neůspěchu se SQL schématem odcházejí s křikem MongoDB je webscale do světa NoSQL, tak se děsím chvíle, kdy budu muset používat jejich app. Nebudou ani výkonné, ani spolehlivé. A odpovědí bude ono známé, tak přidáme další stovku serverů do clusteru, vždyť to umí škálovat.

> Pro vetsinu webovek...

Jsou aplikace a aplikace ... Tuhle jsem studoval DB wordpressu a tam se ani nesnaží předstírat, že existuje něco jako relace a datové typy. Je potom otázkou, proč používají (pouze jednu, hádejte kterou) relační DB, když jim to musí spíše zavazet (s nepříliš dobrým výkonem). Tam by byla nějaká NoSQL rozhodně přínosem. Naopak, jsou aplikace, kde autoři využívají SQL vrstvu do maxima a bez transakcí a ref. integrity se neobejdou.

> Kdo z vas co tohle kritizujete s tim opravdu nekdy delal?

Autor článku (IMHO zbytečně) kritizoval SQL, tak musel očekávat odvetu. Já bych si velmi rád přecetl dobrý článek o nějaké technologii místo toho abych četl o tom, jak je jiná technologie k ničemu.

On problem je v tom, ze NoSQL je relativne siroky pojem, do ktereho padaji moderni ne-SQL databaze delane primarne na skalovatelnost (Cassandra), jednoduche DBM like databaze, "dokumentove" databaze (coz je sam o sobe takovy vtipny pojem) a semtam neco co tam nekdo marketingove tlaci (MUMPS), protoze to vypada jako zpusob jak na tom dalsich 20 let vydelavat.

Diky tomu jsou nejaka pausalni tvrzeni vhodne/nevhodne, jednoduche/slozite dost osemetna.

Osobne si myslim, ze tech "webovych" aplikaci, kde by SQL databaze byla opravdu vhodna je pomerne malo, na druhou stranu jakychkoli aplikaci kde je primo vhodna databaze typu Cassandra je jeste mene. Ovsem pro mnohe webove aplikace je hashtabulka-s-indexama ("dokumentova" databaze) v podstate ten ideal toho co potrebuji (jako priklad si clovek muze vzit treba Linuxsoft jako takovy, datove schema, ktere kdysi zverejnil Leos Literak, take ukazuje na to, ze by se to dost zjednodusilo).

Pokud ma webovka datove schema s relacema maximalne pres 3 tabulky a transakce neresi, tak cassandra je pro ne vhodna, poskytuje presne to co potrebuji a umi to vyridit jednim dotazem do DB namisto vice ktere by byly potreba pro SQL. Proto je o NOSQL v posledni dobe takovy zajem. Podivejte se treba na SimpleCassie, je to vyrazne jednodusi nez se patlat s SQL.

Vetsina LAMP webu ma maximalne 2 tabulky ve FROM a transakce neresi protoze MyISAM u naproste vetsiny hosteru. Navic se cassandra snadneji pouziva protoze neni potreba pouzivat SQL a LAMP aplikace nepouzivaji ORM.

Neni otazka zda je lepsi psat webovky tak aby pracovali s ACID databazi. LAMP Lidi proste na ACID temer vzdy dlabou a mysql pouzivaji jako hashtabulku. Tak proc jim tu hashtabulku nedat primo? Oproti stavajicimu stavu to bude zlepseni - lepe se to skaluje na strane poskytovatele.

> Pokud ma webovka datove schema s relacema maximalne pres 3 tabulky a transakce neresi

Tak otázkou je, jaké webovky. Pokud se podíváme například na Facebook (google plus, twitter, you tube a v podstatě všechny tyto masivní weby); na jejich datové potřeby, tak tam se v podstatě záměrně nějakým relacím vyhýbají. Otázkou je, co bylo dřív. Jestli zadání, "nemůžeme dosáhnout globální časové konzistence dat, tak na to vymyslete gui" nebo naopak. Já nevím. Na každém "normálním webu" je těch relací až až.

Druhou otázkou je, jestli potřebujeme znát informace typu "top ten autorů fotek pro nejčtenější články z kategorie architektura v měsíci lednu alespoň". S tímto si NoSQL poradí těžko, naopak pro sql je to hračka.

U webu prvního typu na nějaké konzistenci dat vlastně ani nezáleží. U druhého typu je to průser.

V Cassandre taky muzete a budete mit relace treba autor -> clanek (viz schema twissandra) ale optimalni je aby nebyly delsi nez 3 stupne na 1 operaci, pak by se muselo pouzit vic zretezenych tabulek a je tu problem s neatomickymi aktualizacemi pres vice tabulek.

Pokud se jedna o dotazy typu 10 nejlepsich autoru tak pokud to aktualizovane nemusi byt moc casto, tak se pouzije map/reduce nekolikrat denne. Pokud to musi byt aktualizovane online tak je potreba si navrhnout odpovidajici strukturu tabulky: klic pocet clanku - hodnota jmeno autora. pro aktualizaci budeme potrebovat shared lock ktery nam zajisti nadstavba cages http://code.google.com/p/cages/

Globalni konzistenci dat zarucit lze, pri cteni se muze cist ze vsech replik, problem je ze bez nadstavby to neumi atomicke updaty pres vice tabulek.

V clanku se pise, ze Cassandra je AC, ale IMHO tam ma byt AP!