Názory k článku
Přechod z MySQL na CouchDB, část první

Pro jednoduchou aplikaci je snad ukládání do podobného clusteru dobré, ale pro složitější datové sklady to bude nejspíš pohroma.

Výhoda tohoto přístupu pravděpodobně skončí s rostoucí složitostí a objemem dat uložených v jednom záznamu. Provázání heterogenních dat z různých záznamů nejspíš nebude nejrychlejší, u komplexních databází se stovkami a tisíci vazeb budou klasické tabulky pravděpodobně rychlejší. Změny struktury uložených dat, či změny vazeb jistě nebudou triviální, v některých případech nemožné bez ztráty dat. Může to svádět k duplicitnímu ukládání dat. Optimalizovat složitější věc v tomhle bude noční můra.

"Může to svádět k duplicitnímu ukládání dat."

To stejné se přeci může stát v běžném SQL a někdy to není na škodu.

Např. mám tabulku/dokument OBJEDNÁVKA v něm jsou specifikované objednané rodukty. Zapíšete produkty jako referenci na tabulku/dokument PRODUKTY nebo do tabulky OBJEDNÁVKA krom ID produktu zduplukujete i základní údaje jako je cena produktu?

Pro případ že se v budoucnu změní nějaký parametr produktu (nebo bude produkt odstraněn) volím raději druhou variantu.

Jo, to je důležitá věc. Jinak by se nemohla měnit cena, vždycky by se musel vytvořit nový produkt (zkopírováním současného).

pokud mam historii parametrů produktu, tak si je můžu vytáhnout podle data objednávky

A když produkt úplně odstraníte?

Asi není dobré produkt natvrdo mazat. Spíše mu nastavit nějaký parametr available=false. Pro zákazníka, který na produkt přijde přes záložku v prohlížeči (např nějaký akční produkt, který má platnost jen týden) je asi lepší, když mu systém řekne, že položka sice existovala, ale už je zrušená a místo toho může zvolit nabídnutou alternativu. Příklad z praxe: http://www.alza.cz/msi-870a-g54-amd-athlon-ii-x4-640-d200137.htm

V tom ale databáze nijak nepomůže. Lepší je v takovém případě definovat integritní omezení, které zabrání smazání záznamu, na který existují reference.

nie je to podobne ako vytvorit si nejaky bigtext v mysql a dat donho json encoded pole? Struktura moze byt pri akomkolvek zazname hocaka, vyhladavat podla stlpca sa tiez nebude dat, ...

V zásadě ano, ale nad takovým bigtext polem těžko uděláte nějaký view (map a reduce záznamů).

Tzn. musel byste si nechat vypsat všechny záznamy a až v aplikaci si vyzovat/vyfiltrovat jen to co potřebujete (při milionu položek ...).

>> nie je to podobne ako ...
> V zásadě ano, ale ...

V zásadě NE. Je to asi stejné jako říci, že HTTP API je „v zásadě podobné“ jako předsadit před *SQL databázi nějakou webovou službu.

Ano, pak máte 100% pravdu.

Ano, tohle jde, dokonce to i někdo provozuje v praxi. Další možnost je místo JSONu použít XML – vyspělejší databáze mají podporu XML, takže nad ním jde provádět dotazy nebo transformace – není potřeba si tahat celá XMLka do aplikace a až tam je filtrovat nebo zpracovávat – databáze má k datům blíž a dělá v podstatě to, co klasická relační databáze (a šetří práci aplikaci a programátorovi).

Docela pěkná přednáška o CouchDB je na adrese http://webexpo.cz/prednaska/couchdb-databaze-pro-web/. Vřele doporučuji shlédnout.

Pohledy jsou definovány v návrhovém dokumentu, pomocí JavaScriptu, prostřednictvím funkce, která bere dokument jako parametr. Při vytváření pohledu je pak této funkci postupně předán každý dokument v databázi, a ta vygeneruje údaje, které budou výstupy pohledu. Z tohoto JavaScriptového kódu není třeba mít obavy, neprovádí se na klientovi, ale na serveru.
Tohle že má být jediný podporovaný způsob, jak vyhledávat pomocí atributů - iterace přes všechny záznamy?? To snad ne...

Myslím, že nějaké rozšíření SQL o možnost ukládat stromová data jinak než BLOB nebo hafo provázaných tabulek by se hodila, ale tenhle přístup mi přijde špatně. Věci jako SQL, tabulky a indexy by se vyhazovat neměly, díky nim může mít člověk věci pod kontrolou a optimalizovat na míru. Jak v tomhle uděláte relaci m:n ?

Já jsem z textu teda nepochopil, že by se vyhazovaly indexy? Spíše naopak.

"iterace přes všechny záznamy"

asi sa autor zabudol zmienit ze tato iteracia sa vykona iba raz pri inicializacii(zmene alebo vytvoreni) view , nasledne pri zmene(pridanie, zmazanie) dokumentu sa dopocita do view iba ten zmeneny dokument

"m:n"
sa da cez views

Ačkoliv mi na relačních databázích a SQL vadí moře věcí a jejich vývoj za posledních 20 let lze označit za bezradnou stagnaci, tak stále marně čekám na pořádný příklad, ve kterém NoSQL (nebo raději nerelační DB) vyniknou.

Například tento článek: hned na začátku autor přemýšlí nad problémem relačně a dodává, že to má své výhody (resp. říká "může to mít své výhody", výhody uvede, ale nevýhody žádné nezmíní). Jako nevýhodu uvádí nutnost dokument získat více příkazy, což však není argument proti-relační nebo pro-nerelační. To je spíš kritika omezenosti SQL.

Přitom dobré příklady by se určitě daly najít; sám žádný v rukávu nemám, jen vyzývám. Ačkoliv možná snad jeden: existuje na světě nějaký bigotní zastánce relačních databází, který by ukládal HTML dokumenty do tabulek relačně?

Já si myslím, že tady argumenty jsou - primárně je tu mnohem větší kontrola ohledně způsobu přístupu k datům - přístup k datům je přímočařejší a víc odpovídá procedurálnímu myšlení - tudíž když už někdo bastlí, tak to nemusí mít tak hrozivé důsledky jako v SQL. Navíc díky procedurálnímu přístupu k datům je mi jedno, co vlastně záznam obsahuje - v podstatě to zjišťuji adhoc - takže mohu dynamicky rozšiřovat strukturu záznamu. Samozřejmě, že se za to platí - sekvenční scan je pomalejší, v podstatě na všechno potřebuji indexy aby byl přístup rozumně rychlý a to znamená, že potřebuji více místa na disku.

Skutečně NoSQL db do jisté míry negují SQL - v jejich výhodách a nevýhodách. V SQL vím, co mám v db za data. ale platím za to statičností. V NoSQL db sice nevím, co tam mám za data, ale většinou je to stejně jedno a když je potřeba, tak můžu dynamicky rozšiřovat schéma.

Jinak v dávných dobách, kdy db měly problémy s čímkoliv nad 8KB se HTML dokumenty skutečně do db ukládaly relačně.

> stále marně čekám na pořádný příklad, ve kterém NoSQL (...) vyniknou.

Jak myslíš to „pořádný“?

Vždyť kupříkladu jen každý CMS systém pracuje spíše s hierarchií bohatě strukturovaných a navzájem pospojovaných _dokumentů_ a ne s nějakými „relacemi”.

Zrovna tak všechna možná agregovaná data („nejčtenější článek za tento měsíc, jiný měsíc, tento den, tento rok, ...“) je lepší ukládat např. jako množiny do Redisu [viz např. https://gist.github.com/731641] než s nimi trápit databázový stroj.

Nicméně na High Availability před časem vyšel velice rozsáhlý a autoritativní seznam příkladů využití NoSQL: http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html

Jsou tyhle příklady „pořádné“? :)

Doproučuji si naisntalovat Lotus Notes klenta + designera - a uvidíš.
Kdo chce studovat relační - nerelační - prosím, DB2 + domino server a studovat jak je to dělané v DB2 (db domina nad DB2) a jak v lotusácké DB.

Není potřeba přemýšlet nad tím, čím se chlapci inspirovali.

Dále - pokud chcete CouchDB tak nějak posunout do popředí zájmu - pak začněte nerelačně. Neboť rozdíl mezi relační DB a dokumentovou DB poznáte jedině na srovnávacích příkladech. Přičemž relační DB musí udělat klasik a tu nerelační (nejlépe) lotusák.

Jinak to bude o ničem - na úrovni fikiny a teoretických úvah vysokoškoláků. Dělám oboje už hodně dlouho a přesně vím, na co je lepší to a na co to druhé.
Osobně nemám rád svázanost a strohost relačních DB, na druhou stranu - nerelační databáze dávají více svobody při realizaci a hlavně se ten bordel dobře udržuje při rozšiřování byznys modelu.

Protože to je můra každého návrháře - byznys analytik - co vám řekne - tyhle atributy ne - ty nepotřebujem.
A já to kujva dvuát vidím, že je bude potřebovat, ale ne - on je ten chytrej.
A to je pak šrumec - když to celý musíte předělat (sestavit DB podle nového schema).
No a vono je to lidský, že? Když to někdy nejde :D
Asi nějak tak

Přiznám se, že nevím v čem byly dělané Notes aplikace se kterými jsem musel pracovat - ale v každém případu to byla moje noční můra. Zažil jsem jen jednu pomalejší aplikaci, a ta byla fakt děs. Otázkou o které dlouho přemýšlím je, zda-li je lepší technologie, která se dá snadno "znásilnit" nebo naopak horší. NoSQL db se znásilňují poměrně snadno.

Opravdu mam pocit ze veskera argumentace zastancu nosql (nebo obecne nerelacnich) pristupu ve me vzbuzuje pouze tyto dojmy:

A) dotycny neumi poradne SQL
B) dotycny v zivote videl tak maximalne mysql
C) a v te mysql videl databazi zprasenou nejakym hlupakem
D) o ulozenych procedurach nevi nic

Je mi jasne ze mi vsichni date minus, ale jsem presvedcen ze potreba nosql databazi je ve skutecnosti temer nulova.

Je vubec clanku zmineny "problem" ziskani receptu opravdu problem? I autor sam napsal, ze se to DA ve vetsine pripadu vyresit jednim dotazem, opomenul moznost stored procedury a zminil i variantu s aplikacnim serverem.

Nezlobte se, ale prijde mi to jako bych se snazil dokazat ze segway je bezva nahrada za auto, protoze auto je na nic, protoze neumi jezdit pozadu - sice se to da udelat, ale musite se koukat do zrcatka, nebo se otocit hlavu dozadu, coz je VELMI OBTIZNE. Misto toho je lepsi jezdit segwayem, protoze ten se otoci na miste a muzete jet dozadu jako dopredu. A pak zacit vymyslet jak v segwayi odvest novou lednicku, zaridit aby na vas neprselo v desti a jak dojet z brna do prahy za min nez 2 dny.. Jedina spravna odpoved je: i kdyz segway nekdy MUZE byt vyhodnejsi nez auto, 99.99% problemu ktere clovek resi autem segwayem vyresit stejne uspokojive (!) nelze.

Stejne tak mi pride ze nosql pristup je sice rychly a jednoduchy (nemusim se skoro nic ucit, nemusim premyslet.. - na segway taky muze jezdit kazdy hned bez uceni narozdil od auta), ale pro cokoliv jineho nez uplne trivialni a maly projekt je to cesta do pekel.

Uvedomuji si nepresnosti a omezeni uvedene analogie, ale stojim si za tim ze se slusne SQL databazi se da udelat i velmi komplexni struktura, da se udelat rozsiritelne, da se udelat robustne a da se udelat tak ze je prace s ni velmi rychla, snadno optimalizovatelna a snadno rozsiritelna (ve smyslu clusteru db a podobne).
Nerikam ani nahodou ze nemuze existovat nic lepsiho nez SQL, ale rikam ze z toho co zatim vzniklo je SQL nejlepsi.

V zásadě souhlasím, s jednou připomínkou: hodilo by se mi nějaké rozšíření pro stromová data jako v tomto případě. V současném SQL se dají reprezentovat buď jako TEXT nebo jako spousta provázaných tabulek, a ani jedno nepovažuji za optimální.

ja bych spis nez predpokladat neci neznalost bych ocekaval, ze kdokoliv, kdo mel na vysoke skole ty prednasky z datrabazi, tak sem muze dat prehled tech nevyhod.

Urcite ty relacni databze maji nejake nevyhody (kdyby ne, tak pak by se jednalo o prvni vytvor lidsta bz chyb) a vysokoskolaci sem urcite hodi prehled, v jakych situacich relacni databaze nepouzivat. Jiste existuji situace kdy nelze nejakemu zakaznikovi z politickych duvodu rict ze rel. databaze je nevyhovujici, ale pak se jedna o nasazeni, ktere je nucene a ne rozumne.

Já bych polemizoval jen s tou tvojí poslední větou. IT stejně směřuje k masivní unifikaci - když bych použil příměru s automobilovým průmyslem, tak se vyrábí asi víc typů automobilů než kdy jindy asi nejmenším setem součástek. Sdílí se podvozky, motory. Originalita automobilu je už jen v karosérii a kombinaci neoriginálních součástek. Z cca 30 db na kolem roku 2000, tu zbylo 10. Z desítek programovacích jazyků vše válcuje Java, C#, C++ a javascript a PHP možná Python. Zbytek je minoritní - luxusní záležitost.

Docela vtipné je, jak občas se historie opakuje - Dokumentační databáze, kdysi běžely nad souborovým systémem, pak se překopaly do SQL - ale s také tím způsobem, že se do tabulek ukládaly bloby, takže obyčejným selectem se z db nic užitečného nevyrazilo a nakonec se zase píší specializované databáze :). Díky tomu, že CouchDB nebo MongoDB jsou Open Source, tak si myslím, že prorazí - je velká šance, že osloví dost uživatelů.

mssql, mysql, informix, db2, oracle, ingres, postgresql, sybase, progress, firebird, maxdb, adabas-d, interbase

ims, adabas-c, tandem-sql,

cache, db4o

faircom, birdstep, empress, ittia, berkeley, soliddb, sqlite, XY-isam, access, vista-db, foxpro

kolik z nich nepřežije 5 let nebo spíš živoří než aktivně žije?

Zrovna adabas, soliddb, ingres možná informix, určitě foxpro, interbase jsou databáze jejichž uživatelská základna stagnuje. Některé z výše uvedených databází jsou mrtvé, další v podstatě režimu minimálního vývoje - spíš pouze opravy chyb a případně vývoj udržuje a platí pouze několik málo posledních ale velkých uživatelů, pro které je lacinější sponzorovat vývoj než migrovat na jinou db.

Databáze nezanikají ze dne na den - určitě se tu ještě najde firmy, které provozují 602SQL Server, nicméně to neznamená, že 602SQL Server má nějakou budoucnost. Ze Soliddb jsem migroval aplikace v roce 2003, v posledních dvou letech došlo k masivním migracím z informixu. Teď mám informace, že hodně konzervativní vývojářské firmy - Telco opouštějí Adabas.

Je to škoda - život byl pestřejší - třeba soliddb byla hodně dobrá databáze, český 602SQLServer byl na to, kolik ho dělalo lidí úctihodný produkt, který zazdila špatná cenová politika 602, Open Source a cost based planer.

Tady se zastanu NoSQL databází - osobně mám větší pifku na lidi, kteří prosazují ORMka než na ty, kteří propagují NoSQL - resp. znám se s Karlem a on je fakt člověk, který přemýšlí.

Relační databáze jsou navržené a řešené tak aby Vám maximálně využili hw při hromadných operacích, aby garantovaly integritu dat, aby umožňovaly snadné dotazování. Tohle umí relační SQL db perfektně a snesou velkou zátěž. Vnitropodnikové systémy jsou extrémně statická záležitost - struktura dat se mění minimálně, nasazení změn je záležitost v měsících než ve dnech.

Renesance NoSQL databází z loňského roku byla způsobena nasazením relačních db v rozsahu a podmínkách pro které se absolutně nehodí. A ještě se tu bavíme o MySQL, která ty své slabší stránky (vycházející z té relační podstaty) má extrémní. Provozovat MySQL ve stovkách instancí je fakt úlet. Já jsem s NoSQL databázemi pracoval od roku 2001 - byly to dokumentační databáze - a pro určitý způsob nasazení při respektování prošlapaných cest je to perfektní nástroj - ale nesmíte je moc přiohýbat - nesmíte chtít komplexní analýzy dat, nesmíte chtít řešit komplexní vztahy mezi dokumenty, nesmíte chtít řešit hromadné operace. Databáze typu CouchDB tu jsou už relativně dlouho - jelikož data jsou v blobu, tak mohu napsat funkce které pracují s dokumentem verze1, verze2, ... Při malém počtu verzí nemusím řešit ALTER tabulek, což při stovkách ještě navíc replikovaných serverů je noční můra. Zase hromadné operace jsou pomalejší, neboť musím dynamicky zjišťovat, co jakou verzi ten či onen BLOB obsahuje. Navíc vzhledem k izolovanosti záznamu v NoSQL db (vše je v jednom BLOBu) jsou o dost jednodušší pravidla ohledně izolace transakcí, NoSQL db se také snáze replikuje - což je další výhoda při masivní paralelizaci. Jinak řada dokumentačních databází běžela interně nad SQL databází - smyslem bylo dodávat hotová krabicová řešení.

NoSQL je samozřejmě módní záležitost, která SQL vůbec neohrozí - už jen z toho důvodu, že je SQL univerzálnější (až na http komunikaci dokáži v PostgreSQL simulovat CouchDB, což CouchDB nedokáže) Na druhou stranu své místo určitě mají - tím, že vycházejí z trochu jiných paradigmat než relační db, tak umožňují lépe rozkládat zátěž než klasické databáze - ale bavíme se o aplikacích, které, jak si myslím, v ČR nikdo neprovozuje. Jinak každý nový nebo znovuobjevený produkt přitáhne pozornost - a přitáhne lidi, kterým nevyhovuje stávající technologie, z toho či jiného důvodu, a po půl roce jich většina odpadne protože zjistí, že jim nevyhovuje také, z několika se stanou zapálení fandové, z několika evangelisti, někteří u toho produktu zůstanou, protože jim sedne a vyhovuje. Rozhodně NoSQL databáze nejsou těmi databázemi, kde by se nemuselo přemýšlet - pokud chcete mít rozumně rychlou databázi a přehled o datech, tak dobrý návrh musíte mít i v případě NoSQL.

No ja bych minus nedaval databazemi se zabývám tak 10 let a dam vam za pravdu, že když mám ladit MySQL databázi po nějakém odborníkovi.... tak dostávám kopřivku. (Jsem trochu zhýčkán Oracle)

Ale viděl bych v tom článku alternativu XML databázím. Protože čekám, že dotyčný popíše chování dotazů v operační paměti, tak budeme všichi určitě chytřejší.

PUrbino

Neříkám, že noSQL nenajde uplatnění (byť celkem zřídka, psal jsem to i tady: Humbuk kolem „noSQL“ databází), ale opravdu by to chtělo nějaké pádné argumenty – ty v článku jsou celkem úsměvné, např.:

„a to vede k nutnosti synchronizovat spolu tyto tabulky. Například, co se má stát, pokud se smaže záznam? Musíte smazat všechny další záznamy, které se na něj mohly odkazovat“

Celá ta propagace kolem noSQL mi přijde jako volání: pojďme to dělat jinak, uvažovat jinak! Ale nějak chybí ta motivace – bude to v něčem lepší, v něčem horší, ale zásadní důvod pro změnu paradigmatu u většiny aplikací chybí. A spíš si na tom lidi natlučou nos – kromě jiného kvůli chybějícímu schématu (což se projeví hlavně ve chvíli, kdy je aplikaci potřeba dlouhodobě udržovat a rozvíjet – ne jen rychle nakódovat a vypustit do světa).

Mohl bych se zeptat, k čemu je mi neschémovost? Některé výhody těchto databází (např. škálovatelnost) chápu a CAP teorém mi taky něco říká, ale v neschémovosti jsem se výhodu vidět nenaučil. Kde dělám chybu?

Toto všechno si dovedu představit i se schématem. U blíže nespecifikovaných volitelných atributů spíše použiju nějakou speciální datovou strukturu k tomu určenou (mapu, vazba m:n, ...).

Naopak, u neschémovosti bych viděl peklo při změně struktury. Se schématem (a nějakým nástrojem, který promítne schéma do datových typů nebo naopak) mohu změnit strukturu a ve staticky typovaném jazyce hned vidět, co se rozbilo.

Ono to spolu souvisí. S vhodným využitím statického typování (a klidně slabého) mohu dáky schémovosti si být při určitých změnách struktury jist, že nemám ponechaný kód, který by se o starou strukturu opíral. Je teda pravda, že to dost záleží na použitém API, takový SQueryL zde pomůže asi řádově lépe než nějaké JDBC.

Ke statickému typování: on je to spíše formální důkaz (byť rozhodně ne na celý algoritmus - i s tím je k tomu potřeba přistupovat), který takto dostávám prakticky zadarmo (+ lepší podpora IDE).
Zajímavé názory na toto téma, byť to již začíná tím odklonem od tématu zavánět, jsem našel v knize Programming in Scala pod "Scala is statically typed" (začíná na straně 16 dole, i když zajímavž odstavec je až na straně 17) a celkem s tím souhlasím:
http://books.google.com/books?id=MFjNhTjeQKkC&pg=PA17&lpg=PA17&dq=static+type+system+pain&source=bl&ots=FKujTGEMqn&sig=E-v6Ng-pDQrMkjLqhIgt9ymPv3A&hl=eo&ei=vPsxTbrfCMKgOoXkwLYC&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBIQ6AEwAA#v=onepage&q=static%20type%20system%20pain&f=false

Ale k tématu, na straně 18 je uvedeno "Safe refactorings", což je přesně to, co bez schématu nelze poskytnout.

No dobře, to vím, ale záměrně jsem o této možnosti mlčel a měl jsem k tomu důvod: ptal jsem se na výhody neschémovosti a asi nemá smysl se bavit o výhodách neschémovosti, pokud tu neschémovost skryji. (Ta část, která je neschémová, je jen implementačním detailem - podobně jako neschémové soubory jsou implementačním detailem mnoha úložišť v mnoha schémových databázích. Snad jediný rozdíl je zde v umístění této vrstvy.)
Jinak netvrdím, že statické typování dovede kompletně nahradit automatické testy. Naopak to ale taky není. Lepší je mít oboje.

NO clanek je pěkný. Ale z diskuze tady jasně vyplívá, že spousta lidí neumí s SQL pořídně zacházet. Ono také ladit něco pod MySQL je někdy docela pohroma.
V článku mě chybí dvě věci.
1. Jestli je to jenom o dotazování, a nebo, také o struktuře paměti dané instance.
2. Jestli je to učeno pouze pro dokumenty, a nebo opravdu pro data.

P urbino

Myslím, že tyto databáze mají své místo v nově vznikajícím trendu JS aplikací, widgetů a mikro aplikací.
Jejich výhodou je krátká doba k naučení a rychlá na použití.

Na složitější projekty(desítky až stovky tříd) je však nepoužitelná.
Stačí se podívat na to, jak je řešená asociace, respektive agregace (1:N a N:N vazby mezi objekty) a je jasné, že to přidá moře práce, stejně skončíte s IDčkama, které si navíc musíte zajišťovat sami.
http://wiki.apache.org/couchdb/EntityRelationship

Osobně jsem začal pro nové projekty používat objektovou databázi:
db4p protože má i GPL licenci, jde v podstatě o dotáhnuté to, o co se zatím No-SQL databáze snaží - schema free databázi, která ale má vyřešené všechny klasické věci, jako redundanci dat a asociaci objektů.
Škoda jen, že neexistuje nějaká pěkná objektová databáze pro JSON.