Tajemství kvalitního prasení, část prvá

5.1.2010 00:17 | Přečteno: 4547× | pro temnou strunu | | poslední úprava: 22.2.2010 22:53

V diskusi ke zprávičce Kampaň za záchranu MySQL jsem byl partou zasloužilých profesionálů bryskně odhalen jako prasič a neschopný programátor, a to na základě několika málo příspěvků (které začaly nevinným flamebaitem, jak je v pokleslých diskusích zvykem). Přímo se mi zatočila hlava, když jsem si představil, co by o mně tito pánové dokázali zjistit, kdybych jim nabídl ke studiu trochu víc materiálu – řekněme takový krátký seriálek o bezschémových databázích? Pohodlně se usaďte, zapomeňte vše, co jste si o databázích doteď mysleli, kurz kvalitního prasení právě začíná.

UPDATE: seriál o CouchDB nakonec vyšel na ábíčku, zbaven výpadů vůči SQL. Díky!

Půjdeme na to čistě prakticky, teorii si můžeme nechat na později. Jednou z dneska nejčastějši zmiňovaných "alternativních" databází je CouchDB. Aktuální verze je 0.10.1, kterou najdete kupříkladu v Debianu unstable. V testingu je 0.10.0, což nám postačí, takže aptitude install couchdb a s chutí do toho; uživatelé jiných distribucí si snad poradí sami, případně se obrátí na wiki. Lehký přehled o vnitřnostech získáte třeba v technical overview – pro nás to nebude nutné, ale zájemcům vřele doporučuju. CouchDB se mimochodem používá například jako lokální úložiště dat pro Ubuntu One (viz též desktopcouch), což znamená, že vydáním Ubuntu 9.10 se zvýšil podíl instalací Erlangu na osobních počítačích minimálně o stovky procent

CouchDB má jediné API: JSON přenášený přes HTTP. Jop, je to tak, můžete si pohrát třeba z příkazové řádky, a HTTP klienta najdete snad pro jakýkoliv programovací jazyk. Server poslouchá na portu 5984, takže pro seznámení:

$ curl -X GET http://localhost:5984/
{"couchdb":"Welcome","version":"0.10.1"}
$ curl -X GET http://localhost:5984/_all_dbs
[]

Aha, ještě žádnou databázi nemáme vytvořenou! To snadno napravíme. API je RESTové, vytvořit novou kolekci objektů znamená volat PUT. A když jsme v tom, smazání je pochopitelně DELETE.

$ curl -X PUT http://localhost:5984/pokus
{"ok":true}
$ curl -X GET http://localhost:5984/_all_dbs
["pokus"]
$ curl -X DELETE http://localhost:5984/pokus
{"ok":true}
$ curl -X GET http://localhost:5984/_all_dbs
[]

Poznatek: "systémové" identifikátory začínají podtržítkem.

Na ten DELETE na chvilku zapomeňme, řekněme, že tedy máme databázi pokus. Jen tak na hraní. Mějme dokument… no nějaký pěkný, třeba tenhle:

{"type": "book", "author": "Dan Simmons", "name": "Drood"}

Co s ním?

$ curl -X POST -d '{"type": "book", "author": "Dan Simmons", "name": "Drood"}' http://localhost:5984/pokus
{"ok":true,"id":"c49a19e0c4fefe86bbab6e12e2d3419f","rev":"1-4ffc368db414b81bf524c6d4c421b93f"}

POST volaný na kolekci znamená vytvořit v ní nový objekt a automaticky mu přiřadit ID. Což se také stalo:

$ curl -X GET http://localhost:5984/pokus/c49a19e0c4fefe86bbab6e12e2d3419f
{"_id":"c49a19e0c4fefe86bbab6e12e2d3419f","_rev":"1-4ffc368db414b81bf524c6d4c421b93f",
  "type":"book","author":"Dan Simmons","name":"Drood"}

(Pro snazší čtení odřádkovávám a odsazuji dvěma mezerami.)

Now come on, it can't be that simple, can it? Poznatek: CouchDB patří mezi dokumentové databáze, kterým není nutné předem říkat, jaká bude struktura ukládaných dat. Datové schéma je čistě věcí aplikace.

Řekněme, že bychom chtěli ukládat i žánrové zařazení. Nebo spíš žánrová zařazení, těch může být vždycky víc:

$ curl -X PUT -d '{"_id":"c49a19e0c4fefe86bbab6e12e2d3419f","_rev":"1-4ffc368db414b81bf524c6d4c421b93f",
  "type":"book","author":"Dan Simmons","name":"Drood", "genres": ["fantasy", "thriller", "detektivka"]}'
  http://localhost:5984/pokus/c49a19e0c4fefe86bbab6e12e2d3419f
{"ok":true,"id":"c49a19e0c4fefe86bbab6e12e2d3419f","rev":"2-fa897debf5c1a63193f121798e85b6e3"}

Tak moment: pokud relační bohy pořád ještě netrefil šlak, teď by měl rovnou dvakrát. Vždyť já porušuju první normální formu! Jako jednu z položek jsem uložil seznam (když si tedy odmyslím, že celý dokument je vlastně mapa…). Ostatně většina dnešních relačních databází potichu nabízí datový typ pole, jako nóbl vychovaná dáma, která se v době manželovy nepřítomnosti za pár šupů prodává přístavním dělníkům – akorát tady si můžu do toho seznamu uložit klidně další mapy a tak dál. Tady si na nic nehrajeme, když se ukáže, že je to špatná volba, je to můj problém. Pokud se přenesu přes tohle: k čertu, neměly by ty žánry být někde v číselníku a u knihy jenom odkazy do něj? Hm, člověk nikdy neví, tak prozatím řekněme, že žánry jsou pro nás něco jako tagy na webu, a uvidíme, co dál.

Ostatně, když jsme u toho, co sakra ten autor? Ten by přece určitě měl být uložený samostatně a u knihy by na něj měl být jen odkaz, ne? Wow. V jednom mém oblíbeném webovém knihkupectví například vůbec nemají stránky autorů a umí podle jejich jmen jen vyhledávat.

A protože v tuhle chvíli se ctihodní kmetové chytají za hlavu a formulují moudré věty o tom, že bych se nejdřív měl jít projít a přemýšlet, co vlastně chci programovat, na chvilku zpomalíme a podíváme se na záhadné položky _id a _rev. _id je, inu, ID, čili primární klíč, jak se říkalo za starých dobrých zapomenutých časů. ID si můžu nechat generovat od CouchDB při vytváření nových dokumentů, jako tomu bylo výše (v takovém případě se vyrobí nový GUID, tedy vlastně UUID, ale tohle slovo prostě nejde vyslovit bez zřetelného falického podtextu, takže se uchyluju k termínu z nepřátelského tábora Microsoftu), nebo si ho zadat sám.

$ curl -X PUT -d '{"type": "book", "author": "Orson Scott Card", "name": "Enderova hra",
  "genres": ["sci-fi", "humanismus"]}' http://localhost:5984/pokus/enderova-hra
{"ok":true,"id":"enderova-hra","rev":"1-0b1b7e88639474892f4eb950bf139e27"}
$ curl -X GET http://localhost:5984/pokus/enderova-hra
{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27","type":"book",
  "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"]}

Automatické generování GUIDů je víc než vhodné minimálně v případě, kdy je databáze "distribuovaná" (CouchDB disponuje hezkou funkcí replikace s řešením konfliktů, ale tím se teď zabývat nebudeme). Naopak číselná ID v rostoucí posloupnosti mohou být pro databázi příjemnější kvůli způsobu, jak jsou ukládána a vyhledávána data (už jsem říkal, že základní a vlastně jedinou diskovou strukturou CouchDB je B-strom?).

A co to _rev? Jistě, je to od slova revision, což ovšem neznamená, že by se CouchDB dala použít jako verzovací systém. Číslo revize se používá k řešení současného přístupu k datům: už výše jste viděli, že když chci dokument změnit, musím ho poslat tak, jak jsem ho dostal. CouchDB povolí zápis jen tehdy, pokud se číslo revize v ukládaném dokumentu shoduje s aktuálně platným číslem revize v databázi.

$ curl -X PUT -d '{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27",
  "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars": "5/5"}' http://localhost:5984/pokus/enderova-hra
{"ok":true,"id":"enderova-hra","rev":"2-823eb2f692da425220f17b96b231082b"}
$ curl -X PUT -d '{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27",
  "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars": "6/5"}' http://localhost:5984/pokus/enderova-hra
{"error":"conflict","reason":"Document update conflict."}
$ curl -X PUT -d '{"_id":"enderova-hra","_rev":"2-823eb2f692da425220f17b96b231082b",
  "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars": "6/5"}' http://localhost:5984/pokus/enderova-hra
{"ok":true,"id":"enderova-hra","rev":"3-1be8a2371b004f49b284061433ba9b48"}

Starou revizi je stále možné číst, ovšem pouze tehdy, pokud je v databázi ještě dostupná.

$ curl -X GET http://localhost:5984/pokus/enderova-hra?rev=1-0b1b7e88639474892f4eb950bf139e27
{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27","type":"book",
  "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"]}
$ curl -X POST http://localhost:5984/pokus/_compact
{"ok":true}
$ curl -X GET http://localhost:5984/pokus/enderova-hra?rev=1-0b1b7e88639474892f4eb950bf139e27
{"error":"not_found","reason":"missing"}

Poznatek: CouchDB používá multigenerační architekturu a řešení souběžných přístupů je tedy optimistické (žádné zámky). Garbage collector (compaction) je AFAIK nutné volat ručně (viz též wiki); po dobu jeho běhu lze databázi normálně používat.

Bližší informace o revizích dokumentu získáte použitím parametrů revs=true nebo revs_info=true:

$ curl -X GET http://localhost:5984/pokus/enderova-hra?revs_info=true
{"_id":"enderova-hra","_rev":"3-1be8a2371b004f49b284061433ba9b48","type":"book",
  "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars":"6/5","_revs_info":[
    {"rev":"3-1be8a2371b004f49b284061433ba9b48","status":"available"},
    {"rev":"2-823eb2f692da425220f17b96b231082b","status":"missing"},
    {"rev":"1-0b1b7e88639474892f4eb950bf139e27","status":"missing"}
  ]}

Obdobně funguje mazání: je to vlastně vytvoření nové revize.

$ curl -X DELETE http://localhost:5984/pokus/enderova-hra
{"error":"conflict","reason":"Document update conflict."}
$ curl -X DELETE http://localhost:5984/pokus/enderova-hra?rev=3-1be8a2371b004f49b284061433ba9b48
{"ok":true,"id":"enderova-hra","rev":"4-d71e7ad84ec3801b0504b739e925e8b7"}
$ curl -X GET http://localhost:5984/pokus/enderova-hra
{"error":"not_found","reason":"deleted"}

Nu, takže CRUD máme za sebou, co dál? Ovšem, dotazy. SQL? Ale kdeže, JavaScript! JavaScript a MapReduce. Zkusme do toho skočit po hlavě:

// map
function(doc) {
  if (doc.type == "book" && doc.genres) {
    for (var genre in doc.genres) {
      emit(doc.genres[genre], doc.name);
    }
  }
}

Co to je? To myslím vážně? Si snad dělám kozy, ne? Tak postupně: CouchDB má pohledy. Ty pohledy jsou definovány jednou nebo dvěma funkcemi v programovacím jazyce (konkrétně v JavaScriptu, ale rozhraní je obecné a existuje podpora pro další jazyky, viz wiki). Názvy těch funkcí pocházejí z funkcionálního světa: map a reduce (resp. fold), a nesou si z něj ještě jednu vlastnost: musí být idempotentní. To zjednodušeně znamená, že nesmí nic změnit (pro jeden dokument musí vždy vrátit tu samou hodnotu), a to zase zjednodušeně vede ke krásným důsledkům: pohledy lze počítat inkrementálně a paralelně. Funkce map je povinná a slouží k filtrování a transformování. Je zavolána pro každý dokument v databázi a sama každým voláním emit generuje jednu položku pohledu: pár klíč -> hodnota (v příkladu výše pár žánr -> název knihy). Funkce reduce je nepovinná, takže ji na chviličku vynecháme. Výsledky se ukládají na disk (takže ten pohled je vlastně materializovaný), a to vždy seřazené podle klíče (takže je to vlastně i index).

Teď jak tedy tu funkci do databáze dostat. Z řádky už mě to nebaví, takže si v prohlížeči otevřu http://localhost:5984/_utils, kde se nachází Futon, standardní GUI ke CouchDB. Futon je z velké části JavaScriptová aplikace, s CouchDB komunikuje AJAXem stejným způsobem, jako jsme si to předvedli výše. Vlezu do databáze pokus a vpravo nahoře zvolím View: Temporary view... Do pole Map Function vložím kód uvedený výše a tlačítkem Run si můžu hned zobrazit výsledky:

To je dočasný pohled, ten ještě není uložený na disku a pokaždé se počítá znovu. Tak tedy Save As..., Design Document: _design/books, View Name: by_genre, a Save. Když pak opět vpravo nahoře zvolím View: All documents, vidím, že v databázi vznikl nový dokument s ID _design/books. Zkuste se podívat na jeho obsah, případně pod záložkou Source se skrývá čistý JSON.

$ curl -X GET http://localhost:5984/pokus/_design/books/_view/by_genre
{"total_rows":3,"offset":0,"rows":[
{"id":"c49a19e0c4fefe86bbab6e12e2d3419f","key":"detektivka","value":"Drood"},
{"id":"c49a19e0c4fefe86bbab6e12e2d3419f","key":"fantasy","value":"Drood"},
{"id":"c49a19e0c4fefe86bbab6e12e2d3419f","key":"thriller","value":"Drood"}
]}
$ curl -X GET 'http://localhost:5984/pokus/_design/books/_view/by_genre?key="thriller"'
{"total_rows":3,"offset":2,"rows":[
{"id":"c49a19e0c4fefe86bbab6e12e2d3419f","key":"thriller","value":"Drood"}
]}
$ curl -X GET 'http://localhost:5984/pokus/_design/books/_view/by_genre?startkey="a"&endkey="n"'
{"total_rows":3,"offset":0,"rows":[
{"id":"c49a19e0c4fefe86bbab6e12e2d3419f","key":"detektivka","value":"Drood"},
{"id":"c49a19e0c4fefe86bbab6e12e2d3419f","key":"fantasy","value":"Drood"}
]}

Parametry key, startkey a endkey musí být platný JSON, proto ty uvozovky. Takže umíme hledat podle hodnoty i podle rozsahu; o dalších možnostech si můžete přečíst na wiki. Tohle vypadá oproti SQL jako pěkná pakárna, pravda? Inu, dynamicky typované programovací jazyky si za svoje služby vybírají jistou daň, bezschémové databáze taktéž. A ve chvíli, kdy se v SQL dostaneme k dotazovatelným procedurám, rozdíly se téměř stírají. Podobně jako materializované pohledy to má výhodu výborného výkonu: není potřeba nic počítat, stačí jen číst.

Dál: co si trochu zaredukovat? Nepovinná funkce reduce slouží k agregování. Řekněme, že chceme pro každý žánr vědět, kolik knih do něj patří. Zkusíme si takový lehký myšlenkový veletoč:

// map
function(doc) {
  if (doc.type == "book" && doc.genres) {
    for (var genre in doc.genres) {
      emit(doc.genres[genre], 1);
    }
  }
}

// reduce
function(keys, values, rereduce) {
  // log({"keys": keys, "values": values, "rereduce": rereduce});
  return sum(values);
}

Tak tohle už je trochu zvláštní – kdo nikdy neslyšel o MapReduce, bude asi pořádně zmatený. Zkusme trochu osvětlit princip: pro každý dokument systém zavolá mapovací funkci, která může emitovat libovolně mnoho dvojic <klíč; hodnota>, to už jsme viděli. Všechny takto vyrobené dvojice se vezmou, vyrobí se z nich množina dvojic <klíč; seznam všech hodnot emitovaných pro tento klíč> a pro každou z těchto dvojic se následně zavolá redukční funkce. Ta musí být komutativní a asociativní, a musí vždy vrátit právě jednu hodnotu (v našem případě je to číslo, ale může to být klidně i seznam apod.), proto se jí říká redukční.

V našem případě funkce map vygeneruje pro každou knihu v každém žánru jednu jedničku, a funkce reduce ty jedničky po jednotlivých žánrech sčítá.

$ curl -X GET http://localhost:5984/pokus/_design/books/_view/genres_count?group=true
{"rows":[
{"key":"detektivka","value":1},
{"key":"fantasy","value":1},
{"key":"thriller","value":1}
]}

Proti SQL vážně směšné, že? Hlavně proto, že výklad výše je ve skutečnosti lež: redukce v CouchDB neprochází prostřední fází (seskupování hodnot podle klíče). Parametr keys obsahuje pole různých emitovaných klíčů (a také ID dokumentů, ze kterých byly klíče emitovány), parametr values pole odpovídajících emitovaných hodnot. Protože pohledy se v CouchDB vyhodnocují inkrementálně, je tu ještě parametr rereduce: je-li jeho hodnota false, platí vše, co bylo dosud řečeno, avšak je-li jeho hodnota true, znamená to, že redukční funkce musí zkombinovat výstupy předchozích volání sebe sama. Tyto výstupy jsou v parametru values, v parametru keys je null. Protože tohle už je poměrně vysoká magie (výše je ukázáno jen základní použití), odkazuji na wiki a přidávám jeden užitečný tip: jak vidno na zakomentovaném řádku v kódu výše, při vyhodnocování javascriptových funkcí v CouchDB lze logovat. (Zkuste si to, log je ve /var/log/couchdb/couch.log).

Každopádně když nic jiného, můžete těchto pár odstavců brát jako ukázku způsobu, kterým se dneska hromadně zpracovávají obrovské objemy dat – na ad hoc dotazování to ovšem stojí za starou belu. Pro tyto účely lze s výhodou využít couchdb-lucene, i když například vývojáři Mozilla Raindropu používají Megaview (mimochodem Raindrop doporučuju k nahlédnutí).

Poznatek: indexované MapReduce pohledy jsou silná zbraň, ale v ad hoc dotazování je CouchDB slabý.

A to by bylo dneska všechno. Příště vyřešíme problém s ukládáním autora, který jsme dnes nechali otevřený, a ukážeme si, že z CouchDB lze přímo servírovat HTML (tak jak to Oracle umí už léta). Použijeme také slovo "join". Kvalitnímu prasení zdar!

P.S.: nejlepším sci-fi seriálem všech dob je vskutku Doctor Who, a to z jednoho prostého důvodu: nikdo jiný nedokázal odpovědět na otázku, kdo je Černá dáma ze Shakespearových sonetů!

       

Komentáře

[AnachronyX]

Trochu OT, ale ten první odstavec mi úplně připomněl tohle:

LISTER: A co potom ta fotka?

KOCOUR ji vytáhne z kapsy a podá ji LISTEROVI.

LISTER: Já nejsem ženich. (Ukazuje na osobu, která stojí po druhém Kristinině boku) Ale tohle je ženich!

KOCOUR: No jo -- není tak hloupá, jak jsme si mysleli!

LISTER: Jak to že mě každá nechá kvůli úplnejm magorům? Jak to že dostanu kopačky kvůli chlapovi, co nosí rolák a kouří fajfku? A baští jenom přírodní jogurt! Je ohleduplnej, cituplnej, duchaplnej a Bůh ví, čeho všeho je ještě plnej. Je posedlej cenou nemovitostí a život tráví ve starožitnictví, kde hledá výhodný koupě a pije víno. Nikdy ne pivo, že jo, vínečko! „Co si dáš k těm cornflakeům, zlato?“ „Dám si trochu vína, pusinko.“ Do pytle!

Udeří hlavou o zeď, rozhořčený a naštvaný. KOCOUR mu položí ruku na rameno.

KOCOUR: To všechno ty poznáš z fotografie?

[thingie]

Nojo, ale ty sebemrskačské poznámky o prasení a tak se zají po prvním přečtení, a přesto se v textu opakují kdovíkolikrát. Jestli to támhle v nějaký diskusi vedle šokuje nějakýho Ponkráce nebo koho tak prosim, ale vždyť to jsou jinak celkem elementární věci.

[Ladicek]

To je právě ono – ale neboj, jsou toho jen tři díly

[thingie]

Ono to zajímavý je, o to nejde. I když doufám, že se objeví nějaký srovnání různých implementací, protože po zkušenostech s ejabberd trpím lehkým nenadšením pro věci v erlangu.

[alblaho]

Můžeš to trochu rozvést? Já měl za to, že Erlang byl stvořen právě pro psaní věcí jako ejabberd.

[thingie]

No, nic velkolepého za tím není. Já jenom, že zkoumat erlangový dump, prezentovaný jako chybová hláška, ze kterého se po 15 minutách vyklube triviální problém, to je… zlý. Možná je to teda chyba ejabberd, já proti Erlangu nic nemám.

[Václav HFechs Švirga]

Souhlasím, když se ejabberd rozbije, tak je to zlo... v gentoo se mi kdysi dokonce stávalo, že začal viset epmd a ejabberd po startu zamrzl. A to i po restartu. Lék byl killall -9 epmd, a potom vše zas pár týdnu běhalo bez problémů (i po restartu). Než jsem na to stylem pokus omyl přišel...

[Ladicek]

Tak na srovnání si vážně netroufám. Ale přemýšlím aspoň o jednom dílu o MongoDB, to je psané v C++ , a má pár vlastností, na které jsou lidi zvyklí (normální indexy a dotazy).

[thingie]

http://www.vineetgupta.com/2010/01/nosql-databases-part-1-landscape.html

Tohle se dneska objevilo na HN, přijde mi to jako pěkný a srozumitelný popis co zhruba všechny ty věci jsou a co od nich čekat.

[Ladicek]

Takových přehledů je víc, ale tenhle vypadá opravdu velmi dobře, díky za link.

[default]

Nojo, ale ty sebemrskačské poznámky o prasení a tak se zají po prvním přečtení

Ony se hlavně zají ty nejapné poznámky hraničící s útoky v každé reakci na tvůj komentář.

[xkucf03]

Dobře ti tak. Kdo chce tenhle bordel, má ho mít :-P Pokud někdo chcete mermomocí zběhnout od SQL, doporučuji se podívat na eXist, to je zajímavá databáze.

[Ladicek]

Jo, to bude taky skvělá prasárna. I když mne teda XML databáze nijak neoslovily. Vůbec nejlepší jsou ti, co ukládají XML do relační databáze :-P

[Michal2]

IIRC presne tohle dela treba ABClinuxu

[Ladicek]

Vím, že tak kdysi byly ukládány diskuse, ale mám pocit, že se to měnilo. Ale jistý si tím nejsem, třeba je to tak pořád.

[xkucf03]

1. Můžeš to nějak rozvést? (eXist)
2. XML v relační databázi není problém, pokud se používá s rozmyslem samozřejmě. Tím, že některá data uložíš jako XML do jednoho sloupečku, místo abys pro jednotlivé jejich části měl samostatné sloupečky a tabulky, něco získáváš a něco ztrácíš.Můžeš ukládat libovolně složité a předem neznámé struktury, aniž by bylo potřeba měnit nebo zesložiťovat DB schéma. Ale zase si s těmi daty (resp. s jejich složkami) nemůžeš pracovat pomocí XML – ale např. pomocí XPath můžeš, pokud ho databáze podporuje. Jako typický příklad si dokážu představit elektronický obchod s hardwarem – většina katalogu bude v relačních strukturách, ale do XML můžeš dát např. podrobnější parametry zboží – takový monitor má jinou sadu parametrů než pevný disk atd. pro ně si můžeš udělat jednotlivá DTD/Schémata (i když to není nutné)… tím získáš flexibilitu, ale zároveň je zachovaný pořádek, věci jsou deklarativní a přehledné.

[podlesh]

Což je ovšem něco, co zde mnoho lidí velmi kategoricky odsoudilo jako prasárnu pro lemply.

[Sinuhet]

Parametry u zbozi jsou hodne spatny priklad, to opravdu neni "neznama struktura", kvuli ktere by bylo potreba neustale "menit nebo zeslozitovat DB schema". Ale na to prijdete sam az vas pozadaji, abyste do vaseho eshopu doplnil napr. hledani a razeni podle parametru...

[xkucf03]

Což ale znamená omezit ty parametry zboží na nějakou sadu záznamů klíč-hodnota a vzdát se složitějších struktur. Jasně může to být řešení a pak není potřeba žádné XML a člověk si vystačí s relační tabulkou.

Nicméně cílem mého příspěvku nebylo říct, že parametry zboží se mají cpát do XML, ale říct, že když už někdo potřebuje ukládat bohatě strukturovaná a předem neznámá data, je lepší použít XML než nějaké chaotické databáze.

[Václav HFechs Švirga]

Vypadá to hodně drsně, i když ke konci jsem se už ztrácel - do té zjednodušené verze count se to dalo. Ale chápu to dobře tak, že místo aby člověk na začátku vymýšlel návrh databáze (ERD model, atd...) a pokud je později potřeba změna (s daty), musel velmi složitě operovat, tak tady to nějak nahází a když později zjistí, že jsou potřeba další udaje, atd, trochu to spřeházet... tak si prostě pohraje s JS a nemusí to pracně předělát.

Taky by mě zajímalo, co duplicita dat? Sice jméno žánru, autora, u každé knížky v pohodě vyhledáme, i pokud by jsme měli obří knihovnu, tak se ten opakující řetězec na velikosti DB projeví (jestli to uvnitř ta databáze nezkouší nějak zoptimalizovat - seskupovat položky a hlídat jejich změny). Jinak je mi jasné, že i tu můžu mít autory zvlášť, kdybych na tom trval.

Sám databázím vůbec nerozumím, jen mě to zaujalo .

[Kopeek]

To mi právě není jasné, jak mít autory zvlášť a udržovat relaci (hehe) "má autora" mezi knihou a autorem.

[Ladicek]

Udržování relace mezi autorem a knihou bude v příštím díle

[Ladicek]

"Nějak to naházet" je jeden z možných přístupů Já jsem tady chtěl skočit rovnou na věc, abych ukázal API, a to co ukládám zase není tak složité, aby se to nedalo pochopit za pochodu.

[Miloslav Ponkrác]

Autor článku trpí utkvělou představou, že snad někomu vadí, když se nepoužívá relační databáze. To vsuktu nikomu, tím méně mně naprosto nevadí. Začínám získávat dojem, že je to přesně naopak: Ládíčkovi vadí, že jiní používají relační databáze.

Nicméně nechť si užije svých 5 minut slávy jako rebel.

Nerelační databáze a úložiště data se sice používají běžně mnoho desítek let. Stejně tak jako relační, které jsou mladší.

[alblaho]

Jo, hlavně když se minule otřel o relační databáze a prohlásil, že dle jeho názoru jsou pro web vhodnější třeba ty dokumentové, tak byl okamžitě "prasič" a "levej jak šavle".

[okbob]

Dovolím si citovat "SQL databáze se pro web nehodí". To je trochu něco jiného než "dle jeho názoru jsou pro web vhodnější třeba ty dokumentové"

Článek jsem si přečetl a mám dvě poznámky: a) k první normální formě - použití strukturovaného typu nemusí jít proti první normální formě. První normální forma vyjadřuje požadavek na nulové dodatečné parsování - což u binárně strukturovaných hodnot nehrozí. Není problém používat pole a vnořené záznamy - vše co předvádá couchdb, zvládá i pg (a v podstatě jakákoliv ANSI SQL db 200x), nicméně občas to býva docela nepraktické (a pokud někdo ukládá cizí klíče do pole, tak i pomalé) - b) myslím si, že je docela dobře vidět, že pracnost čehokoliv jiného než vlož záznam/načti záznam je vyšší než u SQL - což je logické - nemůžeme se spolehnout na obsah věty.

Normální formy nejsou jen teoretické požadavky - pokud se nerespektují, tak psát SQL příkazy je opruz.

[Ladicek]

Normální formy jsou důležité, to bezesporu – ale zase nehoníte všechno až do té páté, skončíte u třetí nebo u Boyce-Codda (nebo ne?). Jinak ano, pracnost je větší, je to na jednu stranu víc high-level a na druhou zase víc low-level (většinu API jsem zvládl popsat v jednom článku) Ale třeba MongoDB má relativně "normální" indexy a dotazy.

A přiznávám, že o SQL 200x nic moc nevím, nedělám jenom databáze. Znám takové to klasické SQL 92 + mám tušení o standardizaci "procedurálního SQL". A wikipedie mluví hlavně o XML věcech.

[okbob]

Z hlavy si vzpomenu na 3NF a víc opravdu v praxi neřeším. Moderní SQL dokáže být hodně dynamické - navíc ve většině komerčních db můžete uložit a indexovat XML, takže můžete vymyslet cokoliv. Není problém do db uložit cokoliv, načíst cokoliv. Problém je s databází inteligentně, a pokud možno bez většího duševního úsilí pracovat.

ANSI SQL 200x obsahuje podporu nested tables, collection. Co tak mám načteno, a odkoukáno tyto speciální datové typy se primárně hodí pro read-only tabulky (logy, audity), a pak jsou opravdu šikovné, když píšete uložené procedury - protože máte k dispozici mnohem pohodlnější nástroje. Pokud se ovšem použijí jako náhrada NF, tak výsledek bývá problematický - částečně přijdete o tu jednoduchost a určitou eleganci dotazovacího jazyka.

[Ladicek]

Letmo na to koukám a ty vnořené tabulky v kombinaci s dotazovatelnými procedurami vypadají hodně podobně jako pohledy v CouchDB Tohle jsem neznal, zajímavé. Musím kouknout, kdo všechno to podporuje.

[okbob]

Poprvé se setkávám s termínem "dotazovatelná procedura". Předpokládám, že je to termín z NoSQL světa. Co to přesně je?

[Ladicek]

No, já ho znám z knihy Pavla Císaře o Firebirdu Je to uložená procedura, nad kterou lze volat select (takový "pohled", ale definovaný procedurálním kódem) – měl jsem dojem, že tohle přece musí mít všichni, takže jsem po tom nepátral.

[okbob]

Bohužel každá databáze má svoje názvosloví a Firebird zvlášť. V ANSI SQL se používá termín "table function" - tabulkové funkce - tj. funkce, které vrací tabulku, s kterou lze pak operovat stejně jako s normální tabulkou/relací. PostgreSQL používá termín SRF - Set Returned Function - případně pokud se jedná pouze o wrap nad pohledem, tak se můžete setkat s termínem "parametrizovaný pohled" - což je ovšem synonymum pro "table function". V terminologii je krapet chaos - stejné nebo podobné funkce se implementovaly na úplně jiných základech, a ve výsledku je pak dost odlišná terminologie.

[Ladicek]

Díky. Myslel jsem si, že to bude normálně existovat, ale pod jiným názvem jsem to ještě neviděl.

[thingie]

Mně teda normální formy nepřijdou jako moc víc než pokus o formalizaci nějakých těch „best practices“ pro relační databáze, žádnou velkou vědu mi za nima ještě nikdo neukázal.

[bezny uzivatel]

pan Stehule to jiste ukazuje na tech skolenich a ja souhlasim, ze kdyz je skladba dat nenormalizovana, ze budou SQL dotazy krkolomnejsi. Musim ovsem priznat, ze me ta normalizace pripadala take vzdy neco jak pisete, ale mam pro to nasledujici vysvetleni. Uz v dobach VSAMu na velkych strojich se musela nejak data strukturovat a 1nf se pouzivala uz tenkrat takrikajic intuitivne bez tohoi, aniz by nekdo rel. technologie znal. Ta predstava, ze kdyz nekdo pouziva isam-databaze a nutne tedy nedokaze strukturovat data je jakasi pohadka.

[okbob]

Bohužel, skutečnost je jiná. Návrh databáze minimálně v 3NF je přirozená až pro trénovaného uživatele. Je to podobné strukturovanému programování nebo neprocedurálnímu programování. Neškolený uživatel tyto nástroje nedokáže dobře použít.

Měl jsem příležitost vidět, jak navrhovali neprogramátoři db např. v MS Accessu, případně v Excelu. Či jakým způsobem psali makra např. ve MSWordu. To jsou všechno nástroje, které se dostanou běžnému uživateli bez varování, a uživatelé je používají intuitivně. Teď je nechci kritizovat. Jejich cílem je použít sw, k tomu co potřebují a víc řešit nemusí. Já, když mi poteče do střechy, tak taky vezmu kus plachty a pokrývače může trefit šlak. Spíš bych chtěl tím argumentovat, že NF nebo strukturované programování není něco na co by typický uživatel přišel sám - koneckonců na obé se přišlo po minimálně dvou dekádách a přišli s tím relativně hodně chytré dámy a chytří pánové.

p.s. není až tak výjimkou vidět jedno tabulkové databáze s padesáti-šedesáti sloupečky.

[Ladicek]

Autorovi článku relační databáze v nejmenším nevadí a sám je používá. Autor článku trpí mnoha utkvělými představami, ale vy jste netrefil ani jednu.

[razor]

Pěkný.

[Senior Database Programmer]

No tak tie knizne zanre by som dal ako pevny ciselnik ulozeny v DB. Ved takto:

a) hocikto moze zadat volny tvar, t.j. niekto zada ako zaner "sci&fi", niekto "sci-fi", niekto "scifi&fantasy", niekto urobi preklep "ci-fiii" a mam v DB bordel. Potom select "vyber vsetky knihy zo zanru sci-fi" nenajde tie ktore su zapisane inak alebo s preklepom....

b) sa o konzistenciu dat musi starat aplikacia, t.j. praca naviac pre programatora s tym ze moze urobit chybu. Ked to mam zadefinovane na urovni DB tak mi to nezbura ani zle napisana aplikacia.

[Ladicek]

B je pravda, to si musí každý rozhodnout sám. Dočasná nekonsistence ovšem často nemusí vadit. Ale v A rozhodně databáze samospásné nejsou a uživatelé to bez problémů dokážou rozbořit. V několika knižních databázích jsem viděl jednoho a toho samého autora zadaného vícekrát a musel se řešit ten samý problém, co popisujete. Holt je to jenom software a používají ho jenom lidi

[bezny uzivatel]

B) nesouhlasim, dokud nekdo nenapise, co to znamena vice prace pro programatora. To jsou jen obycejne kecy, ktere nikam nevedou. Chci ten link, kde se dozvime, kolik hodin, clovekodnu nebo co je jedna varianta narocnejsi nez druha samozrejme s definicemi, co se za kterym nakladem skryva za cinosti. Vsechno ostatni jsou pivni reci.

[thingie]

Představa, že tohle někdo půjde určovat obecně pro všechny možné případy (a ještě se bude ohánět přesností) mě trochu děsí. Na jednom modelovém příkladu snad.

[Ladicek]

No, pokud konsistenci nevynucuje databáze, musí to asi udělat programátor. Na druhou stranu kdyby striktní konsistence dat byla nutná a programátor na jejím zajištění musel trávit významné množství času, pak je taková bezschémová databáze zřejmě špatná volba (pokud pro její použití nejsou jiné důvody). Osobně si myslím, že ve spoustě nekritických aplikací se nějaká nekonsistence dá s klidem přežít (a programovat s vědomím, že může nastat, zase není taková námaha – je to takové dotažené defensivní programování ).

Ale čísla vám tedy nedám, v tom ohledu souhlasím, že to jsou spíš takové pivní řeči, protože máme v oblasti databází nějaké zakořeněné návyky.

[okbob]

Myslím si, že by neměl být problém kombinovat oba typy databází. A to ať už v rámci jedné databáze, nebo v rámci různých databází. Tam, kde to je výhodné. Striktně dbát na relační db je nepraktické, zrovna tak preferovat bezmyšlenkovitě bezschémové db. Je řada programátorů, kteří s oblibou používají EAV, což je snad to nejhorší, co mohou dělat - v devadesátých letech tato technika byla hodně populární a ještě dnes se s ní můžete setkat. Potom jsou databáze jako CouchDB rozhodně výhodnější. Navíc, prostě hromada programátorů nechápe důvod proč by v datech měli řešit nějakou konzistenci - a netuší o co go. Pro ně, tyto databáze mohou být dobrou volbou - napáchají menší zlo.

Bezschémové databáze nelze příliš srovnávat s SQL db - jedny tu jsou 5 let a druhé přes třicet. Nepřišlo by mi až tak nepravděpodobné, kdyby během několika let bezschémovým db uměly kontrolovat validitu záznamu - kdyby záznam bylo možné přeformátovat do XML, tak např. pomocí Relaxu.

[okbob]

sorry spravny link

http://en.wikipedia.org/wiki/Entity-attribute-value_model

[Ladicek]

Validační funkce jsou v CouchDB už dnes. Ve trochu rudimentární podobě, to ano, ale jsou (možná bych mohl do druhého dílu ještě vsunout příklad, původně jsem o nich mluvit ani nechtěl). O schématech v NoSQL databázích obecně se taky mluví.

[xkucf03]

V několika knižních databázích jsem viděl jednoho a toho samého autora zadaného vícekrát

Normální je, že aplikace nabízí uživateli zadání autora z číselníku, může mu i napovídat jeho jméno podle zadání prvních pár písmen, případně se musí nejdřív vytvořit autor a pak teprve se může použít (a tato procedura je trochu uživatelsky nepřívětivá, aby uživatel nezadával spousty nových autorů a radši se nejdřív podíval, jestli už tam ten autor není). Totéž platí pro žánry.

Jenže jak tohle udělat v té nenormalizované „databázi“? Pokud tam má být nějaká nápověda, musí se projet všechny záznamy a z jejich polí vytahat všechny žánry (či jména autorů), pak zahodit duplicity (to se všechno dělá v aplikaci?) a pak je zobrazit uživateli. Zatímco když je databáze aspoň trochu normalizovaná, tak máme číselník žánrů (nebo autorů) a projíždí se vždy jen tahle relativně malá tabulka.

[Ladicek]

Konkrétně v CouchDB se nad těmi žánry dá udělat pohled (index), takže ve výsledku to dopadne podobně.

[okbob]

nakolik je index nad CouchDB dynamický?

Je aktualizace automatická nebo je nutné si aktualizaci vyžádat?

[Ladicek]

Pohled (index) se materializuje při prvním dotazu a následné změny v dokumentech se do něj promítají automaticky při dalších dotazech. Jedním parametrem lze říct, že má databáze vrátit už hotový pohled a nekoukat se, jestli nebyly dokumenty od poslední aktualizace změněny (takže automatickou aktualizaci je možné nepoužívat a pohledy aktualizovat ručně).

[okbob]

Dost mi to připomíná techniku, která se používá v tzv. stream databases. Tady ke každému pohledu musíte mít zaregistrovanou funkci, která se zavolá při něčem, co bych s troškou dobré vůle mohl nazývat COMMITEM. Přijde mi to hodně ideově podobné - realizace je asi dost odlišná - princip je stejný - udržovat obsah agregovaných tabulek aktualizovaný.

[Ladicek]

Jo.

Vybavilo se mi teď, s tím udržováním obsahu agregovaných tabulek, že před pár dny nebo týdny jsem kdesi četl hezké shrnutí: v SQL se informace z dat získávají při čtení, v NoSQL se zjišťují už při zápisu (to pak vede k denormalizaci a tak dál).

[xkucf03]

v NoSQL se zjišťují už při zápisu

Takže musím předem vědět, jaké dotazy na databázi budu klást? Trochu omezující, ne? (ostatně v relačních DB to není nic nového – materializované pohledy nebo triggery a tabulky s denormalizovanými daty)

[Ladicek]

Jasně že se to v relačních databázích taky používá, to není žádné dogma (bezschémovou databázi můžu taky normalizovat, když budu chtít). K ad hoc dotazům už jsem se tu vyjadřoval.

[bezny uzivatel]

prave kvuli takovym 'database programer' to ladicek napsal.

[xkucf03]

Docela by mne zajímal scénář zaškolení nového kolegy nad danou bezschémovou databází (nebo co bude dělat stávající programátor, když na projekt pár měsíců nesáhl a teď v něm má v programu něco předělat). V případě relační databáze dostane nováček ER diagram nebo nějaký jiný pěkný obrázek, pochopí a brzo se může zapojit do pracovního procesu (což je žádoucí – žádná firma nechce platit lidi, kteří se musí dlouho rozkoukávat a neprodukují žádnou hodnotu). V horším případě, pokud model nijak zachycený nemáme, nebo je zastaralý, nováček se podívá na relační databázi v nějakém chytřejším klientovi, zjistí, jaké tam jsou tabulky, z popisů (které by tam měly být) zjistí, co znamenají, z cizích klíčů zjistí vazby mezi nimi… V případě bezschémové databáze bude dělat co? Má si nastudovat zdrojáky a z nich se snažit vydedukovat strukturu databáze? Nebo se podívat přímo na data, kde ale platí, že:

With CouchDB, no schema is enforced, so new document types with new meaning can be safely added alongside the old.

takže tam bude asi pěkný guláš a moc z toho nevykouká. Leda že by si projel všechny dokumenty a zjistil, které jsou „new“ a které „old“ případně nějaké úplně jiné, rozdělil si je ve své hlavě na nějaké skupiny a snažil se zachytit jejich struktury.

Přijde mi, že si tu někdo pod snadností úprav představuje jen úpravy měřené počtem řádků případně absenci nutnosti měnit schéma. Jenže snadnost úprav je něco víc – nejdřív totiž musíme nějak přijít na to, jaké řádky kódu a jak budeme měnit. A tenhle proces může být daleko zdlouhavější, než samotné napsání té pár řádkové úpravy. Je to podobné jako opravování chyb – samotná oprava chyby je často triviální, ale přijít na to, kde ta chyba je, to je skutečná práce.

[Ladicek]

No, já si myslím, že ta doba zaškolení je v obou případech plus mínus stejná (tedy aspoň u mne a jednoho kolegy, kterého jsem zaučoval, to tak bylo), v závislosti na rozsahu projektu samozřejmě. Schéma může pomoct, ale v kódu se musí člověk vyznat tak jako tak. Nad relační databází zase řešíš hned dva jazyky zároveň, u některých projektů máš logiku napůl v aplikaci a napůl v databázi v podobě storprocek a triggerů, fyzickou strukturu před aplikací skrýváš umnými pohledy… ne, nemyslím si, že v tomhle je velký rozdíl.

[okbob]

Tak zde se neshodneme. Explicitně definovaná struktura je velké plus pro počáteční orientaci v projektu - struktura nemusí být definovaná v SQL. Stačí ER schéma - které musí snad přečíst každý.

[Ladicek]

Pokud je to důležité, tak lze samozřejmě udržovat dokumentaci, že jo. Můj osobní dojem je, že pro zaškolení nového člověka je nejdůležitější dát mu dokumentaci klíčových API (třeba API k databázi, pokud máme nějakou vlastní vrstvu, ať už má podobu ORM nebo čehokoli jiného), nechat ho pár dní hrabat se v kódu, aby poznal zvyklosti a zjistil, co je asi tak plus mínus k disposici, a pak ho hodit do vody nějakého jednoduššího reálného úkolu. S nějakým zkušenějším člověkem za zády. Datové schéma se dá poznat za pochodu. Nedělal jsem teda nikdy na projektu, kde by se vývojáři nevešli do jedné místnosti (ve čtyřech lidech se dá napsat poměrně rozsáhlý informační systém), tak možná v jiném prostředí to nefunguje.

[xkucf03]

Pokud je to důležité, tak lze samozřejmě udržovat dokumentaci, že jo.

Jenže u relační databáze tu dokumentaci ani udržovat nemusíš, taková databáze je dokumentovaná sama sebou. Resp. jasně, že je hezčí, když má člověk aktuální (neaktuální je spíš na škodu) model v nějakém CASE nástroji, ale i když takový model nemá (buď se mu s ním nechtělo dělat nebo je zastaralý), máme jasnou představu o struktuře dat – už jen na základě názvů tabulek, sloupečků, jejich popisů a cizích klíčů – dále pak na základě primárních klíčů, datových typů atd. tohle jsou všechno deklarativní věci, které není potřeba dolovat ze zdrojáků, prostě koukneš a vidíš.

[Ladicek]

Ano, když se používá nějaký CASE nástroj, ideálně když se z modelu přímo generuje kód (= model je aktuální), je to rovnou vcelku dobrá forma dokumentace. SQL je specializovaný jazyk, takže jako dokumentace je zřejmě o něco hodnotnější, ale pořád je to zdroják. Programátor musí být schopný orientovat se v kódu, ať je to SQL nebo Java nebo čert ví co. Já osobně na deklarativní programování poslední dobou moc nevěřím.

[xkucf03]

SQL je specializovaný jazyk, takže jako dokumentace je zřejmě o něco hodnotnější, ale pořád je to zdroják.

Právě že ne – nikdo tě nenutí studovat kilometry skriptů obsahující CREATE TABLE bla bla bla. Místo toho se podíváš na jejich výsledek, běžící databázi (třeba testovací, vývojovou) a tam vidíš všechny ty tabulky a vazby, aniž bys musel louskat nějaký zdroják. Existují i nástroje pro analýzu těch DB a jejich vizualizaci, takže má pak člověk podobný pohled jako fyzický model v CASE nástroji. Co uvidím v běžící bezschémové databázi? AFAIK jen data, bez struktur, resp. každý kousek dat bude mít nějakou svoji strukturu. Nebo se z toho dá vydolovat nějaké zobecnění? Např. vyhledat záznamy stejného typu, stejných struktur a udělat z toho pohled na nějaké „třídy“ objektů. V relační DB jsou tyhle „třídy“ explicitně a předem definované – jako tabulky.

[Ladicek]

Na běžící databázi se samozřejmě můžu podívat všude, třeba CouchDB má i to webové klikátko. Odvozovat strukturu by asi nějak šlo (stejně jako se dá ze sady XML dokumentů částečně odvodit jejich schéma), ale nevím o tom, že by to někdo dělal (proč taky). Když to nebude nějaká jednoúčelová aplikace, kde všechna data jsou téhož druhu, pak bude asi každý dokument obsahovat něco jako identifikátor typu. Minimálně získat všechny typy by neměl být problém. Ovšem jak se chovat k dokumentové databázi relačním způsobem a nezbláznit se z toho ti neporadím

Ostatně tohle je mnohem obecnější debata. Čím dál víc se mi zamlouvá ta paralela s dynamicky typovanými jazyky, kterou jsem v textu nadhodil.

[xkucf03]

jak se chovat k dokumentové databázi relačním způsobem

Nejde o to, chovat se k ní relačním způsobem – jde o to získat přehled, jaká data máme. Protože když ten přehled nemáme, tak je to jen hnůj, se kterým se nedá pracovat. A pokud ten přehled musíme získávat čtením zdrojáku, tak je to velice nepříjemné a pracné, byť možné.

Čím dál víc se mi zamlouvá ta paralela s dynamicky typovanými jazyky

Dá se najít i paralela s WWW. Na webu je taky spousta dokumentů, rozházených všude možně po síti. Taky je to hnůj, který může zkoumat člověk (číst si www stránky), ale počítač mu nerozumí – úspěch je, když jsou označené nadpisy a odstavce, ale co představují ty dokumenty obsahově počítač netuší, drtivá většina webu není sémantická.

Na webu to ale jinak nejde, resp. zlepšení (sémantika) přichází pomalu, takže se s tím musíme nějak poprat. Ale nevidím důvod proč si stejný chaos zanášet do své vlastní aplikace, kterou mám pod kontrolou a kde si strukturovanost a sémantiku můžu vynutit (což na webu nemůžu – nemůžu nařídit všem autorům www stránek, ať používají RDF nebo mikroformáty a pečlivě všechno označují).

[Ladicek]

(A teď se začnem hádat, čím to je, že nikdo nepřijal XHTML 2 za své. O tom si zase já myslím, že je to hnůj )

Já to dělám asi takhle: chci přehled, jaká data mám? Podívám se do databáze. Chci vědět, jak se s nimi pracuje? Podívám se do aplikace. Nepříjemné mi to nepřijde, přijde mi to normální, protože ve skutečnosti jediný autoritativní zdroj informací je kód. Už jsem například viděl několik políček v relační databázi, do kterých se ukládala úplně jiná data, než by naznačoval jejich název (a ne, nebyl jsem to já, kdo to takhle udělal). Schéma není samospasitelné. Pro některé aplikace je životně důležité, pro spoustu lidí může být významnou pomocí při orientaci, to nerozporuju. Ale nemusí to tak být vždycky, a kdo ví, jestli to tak je ve většině případů.

[xkucf03]

BTW: „hnůj“ tu nemyslím jako urážku, ale prostě nestrukturovaná nesémantická data – typickým příkladem je webová stránka – může být hezká, může obsahovat užitečné informace, ale nemá předem danou strukturu (z hlediska sémantiky*), resp. každá stránka má nějakou svoji strukturu (to jsou ty různé verze dokumentů, „new“ a „old“ nastrkané v jedné databázi), a strojové zpracování je tak výrazně složitější než nad strukturovanými daty s předem daným schématem.

*) gramatiku na úrovni validního XHTML považuji za samozřejmost, ale to nás v tomhle případě nespasí, protože nevíme, že v <h1> se nachází název státu a ve třetím odstavci je jméno presidenta.

[Radek Miček]

IMO absence pevného schématu rozšiřuje prostor pro chyby, snadno se může stát, že místo "produkt" tam vložím "prdukt", protože té databázi je to šumák.

[Ladicek]

To do jisté míry platí. Lidi od dynamických jazyků postupem času vyvinuli celkem sofistikovaný testovací aparát a je možné, že něco na ten způsob vznikne i pro bezschémové databáze (validační funkce v CouchDB je takový začátek, řekl bych). Na druhou stranu problémy v datech od uživatele hrozí vždycky (už jsme to tu probírali). A "prdukt" je evidentně duplikace konstanty

[Radek Miček]

Lidi od dynamických jazyků postupem času vyvinuli celkem sofistikovaný testovací aparát

Kdyby radši vyvinuli pořádný typový systém, který by mohli používat normální programátoři v normálních aplikacích

[Ladicek]

Jo, a nádavkem by mohli vyřešit problém zastavení

To spouštění uživatelského kódu v rámci typového systému ze zápisku vedle o Perlu 6 je třeba docela pěkný nápad, nemyslíte? No a na hraní s typovými systémy jsou tu haskellisti, že jo. Je teda fakt, že Haskell je dneska asi v trochu lepším stavu než Perl 6

[Radek Miček]

To spouštění uživatelského kódu v rámci typového systému ze zápisku vedle o Perlu 6 je třeba docela pěkný nápad, nemyslíte?

Není to špatné, ale osobně bych preferoval, když by se na místech, kde to jde, místo běhových kontrol používaly kontroly statické -- nejlépe ve formě důkazů.

No a na hraní s typovými systémy jsou tu haskellisti, že jo. Je teda fakt, že Haskell je dneska asi v trochu lepším stavu než Perl 6

Mně by se třeba líbilo, když by se zkombinoval typový systém jazyků Disciple a Idris.

[mkoubik]

Jo, a nádavkem by mohli vyřešit problém zastavení

Myslíš tenhle? Nebo ten, v jehož řešení vystupuje SIGKILL a return true;?

[Ladicek]

To je moc krásný, díky, tenhle jsem neznal!

[xkucf03]

P.S. když tu explicitně danou strukturu (schéma) nemáme, tak je to podobné např., jako kdybys měl psát aplikaci, která zjistí jméno prezidenta daného státu. Vyřešit tenhle úkol nad nestrukturovanými či semistrukturovanými a neznámými daty je úkol hodný WolframAlpha*. Velmi netriviální záležitost. Vyřešit tenhle úkol nad strukturovanými daty je hračka – v případě relační DB je to jeden SELECT s JOINem (název země je v jiné tabulce než jméno osoby) a ORDER BY + LIMIT nebo WHERE, když chceme toho aktuálního presidenta.

Nemá smysl zavrhovat ani jedno ani druhé, každý druh databáze najde nějaké uplatnění. Ale asi by bylo dobré se řídit tím, jaká data máme na vstupu. V aplikaci/databázi by se neměla sémantika a strukturovanost ztrácet (protože pak ji musíme zase pracně obnovovat). Může se ale zvyšovat (indexace, parsování, umělá inteligence nebo ruční zpracování – trvá dlouho, ale zvýší strukturovanost a sémantiku dat, takže i jejich hodnotu, dá se v nich líp hledat atd.). Nebo zůstávat stejná – na vstupu hnůj, tak to tak uložíme a hnůj je taky na výstupu – i takové aplikace někdy mají smysl.

*) za povšimnutí stojí doba, za jakou výsledek přijde – a to se při tom nepracuje nad primárními daty (www), ale nad nějakým indexem.

[thingie]

To je ten vtip. S relační databází je to nepředstavitelné. Pro nijak nestrukturovaná data Googlu je to s masivním paralelismem otázka maličkých zlomků sekundy.

[okbob]

Vy víte, že Vám Google vrátí jméno prezidenta - nevíte - dostanete jen sadu stránek, kde se s vysokou pravděpodobností vyskytují určitá klíčová slova - o samotném obsahu Vy ani Google neví nic - viz např. Google Bombs.

[thingie]

Já to ani vědět nemůžu, s takovými daty. Ale i s Googlem samotným bych řekl, že ta šance je vysoká. Mít Google s algoritmy vyváženými pro hledání prezidentů, už by to mohlo být docela slušné.

I když ten příklad je, při asi tak 150 zemích světa kde takovou funkci mají, docela nic moc, no.

[xkucf03]

To je ten vtip. S relační databází je to nepředstavitelné.

Viz:

Nemá smysl zavrhovat ani jedno ani druhé, každý druh databáze najde nějaké uplatnění. Ale asi by bylo dobré se řídit tím, jaká data máme na vstupu.

Pokud je vstupem internet, resp. nekonečné množství www stránek, které jsou nesourodé, nesémantické atd. tak dá rozum, že si ty stránky nebudeme kopírovat do relační databáze a hledat v nich pomocí WHERE html LIKE '%usa%president%'.

Ale pokud jsou vstupem nějaké formuláře nebo jinak strukturovaná data, je to úplně jiné kafe. Osobně si myslím, že to nadšení kolem „nosql“ je přehnané a spousta lidí se k nim uchyluje jen proto, že se pořádně nikdy SQL nebyli schopní naučit. Trochu se obávám, že v rámci téhle módní vlny se „nosql“ databáze nasadí mnohde i tam, kam se nehodí (hodí jen na specifické případy). Ale to vlastně nevadí, aspoň pak pro nás bude víc práce, až se budou tyhle aplikace zase předělávat

Pro nijak nestrukturovaná data Googlu je to s masivním paralelismem otázka maličkých zlomků sekundy.

Ale výsledek je diametrálně jiný – výsledkem je odkaz na dokument, ve kterém se možná ta informace vyskytuje – nikoli ta informace jako taková, což by nám přišlo z relační DB. A masivní paralelismus a maličké zlomky sekundy? Tady je vidět, jak je zpracování nestrukturovaných dat náročné* – místo datacenter googlu mi na relační databázi stačí obyčejné PCčko, třeba i deset let staré. Jasně, objem zpracovaných dat je jiný, ale pokud by Google nebo WolframAlfa měli k dispozici velmi dobře strukturovaný a sémantický web, spotřebovali by mnohem méně výkonu a jejich výsledky by byly kvalitnější.

*) ještě k tomu se neprohledávají data jako taková, ale jejich index.

[thingie]

No, to je zase interpretace. Já bych řekl, že data obecně bývají nestrukturovaná, a ze strukturovaných dat se relační databáze a SQL zejména taky nehodí pro všechno (grafy, že), takže specifické mi přijde spíš nasazení databází s SQL… A to bychom se takhle mohli snadno dohadovat. Konečně, zase ta otázka, zda většina problémů na světě se skutečně hodí pro SQL, nebo se jenom z problémů světa dělají takové, které pro SQL vhodné jsou. Nebo i nejsou, ale „nějak to funguje“.

Google byl jenom příklad. Uvažte jak hodně obecný stroj to je, jak málo ho lze parametrizovat (textový řetězec hledání, co to je, u skutečné nosql databáze?), a jak i přesto poskytne velmi relevantní výsledky, byť v pro tento účel nevhodné podobě, rychle, a neuvěřitelně škálovatelně.

[xkucf03]

Já bych řekl, že data obecně bývají nestrukturovaná

Což je z velké části tím, že mnoho lidí ještě nepostřehlo, že na stole mají místo psacího stroje počítač – místo aby psali na papír a kopírák, to teď píší do Wordu, místo aby to dávali do šanonů ve skříni to dávají do složek na disku. Takovým lidem počítač prakticky nepomohl a využívají jen zlomek jeho možností. Je to ale jejich problém. Nestrukturovaná data jsou mor a potýká se s ním řada firem.

Ale zpět k té tvorbě webů. Co takový elektronický obchod nebo redakční systém. Kolik dat v takové aplikaci je strukturovaných a kolik nestrukturovaných? Nestrukturovaný je třeba slovní popis výrobku nebo obsah článku. Ale ten zbytek?

[deda.jabko]

Já bych řekl, že data obecně bývají nestrukturovaná

Což je z velké části tím, že mnoho lidí ještě nepostřehlo, že na stole mají místo psacího stroje počítač

a nebude to nahodou tim, ze svet (na urovni naseho rozliseni) je nestrukturovany? je jenom iluzi, ze vsechno se da nacpat do nejake predem znameho formatu...

vzdycky me dokonale dokaze vytocit hlaska nejake urednice: ,,ale ja nevim, jak to zadat do pocitace''.

typicky priklad... nedavno jsem se stehoval z US a musel jsem na nekolika mistech nahlasit zmenu adresy... v bance jsem stravil hodinu jenom proto, ze zenska nemela zpusob, jak zadat ceskou adresu do jejich systemu, ktery mel data hezky strukturovane na americke adresy. a to nebyla jedina situace... v jine DB to po me chtelo at vedle statu (CR) vyplnim jako povinny udaj i ,,provincii''...

evidentne jejich DB mely dobre navrzenou strukturu, ktera ale vubec nevyhovovala realnym potrebam...

[feminista]

...jenom proto, ze zenska nemela zpusob, ...

za vsim hledej zenu ...

[xkucf03]

Hezké příklady, ale neukazují nedostatky relačních databází a předem daných schémat, ale chybu analýzy. Pokud daný „byznys proces“ připouští, že ta osoba může žít i jinde než v USA, takže je to blbě implementovaný (protože schéma v DB, nebo aplikace klade víc omezení než by měla) a pokud už v tom byznys procesu zapomněli na to, že osoba může žít jinde, než v USA, tak je blbě celá ta analýza. Taky jsem se s tím párkrát setkal v nějakých registračních formulářích (najednou po mně chtějí, zda bydlím na Aljašce nebo v Texasu, ale Střední Čechy tam nejsou). Nejedná se o nějaké nečekané změny, to, že existují i jiné země než USA je známý fakt a aplikace by s tím měla počítat. Pokud to ale nějaký Američan nevěděl, tak není problém ani tu databázi dodatečně upravit, aby odpovídala „novým“ skutečnostem.

[deda.jabko]

Hezké příklady, ale neukazují nedostatky relačních databází a předem daných schémat, ale chybu analýzy.

ty priklady nemeli ukazovat nedostatky relacnich databazi... ale ukazat, ze ne vsechno ma predem znamou strukturu...

Nejedná se o nějaké nečekané změny, to, že existují i jiné země než USA je známý fakt a aplikace by s tím měla počítat.

jo, jenomze ruzne zeme maji ruzne konvence, jak popsat adresu a jak ji zobrazit... a je nemozne podchytit vsechny mozne kombinace

[xkucf03]

ale ukazat, ze ne vsechno ma predem znamou strukturu

Ta struktura je předem známá. Resp. pokud v zadání máme, že budeme podporovat adresy různých zemí, nemůžeme klást příliš velká omezení, ty struktury budou volnější.

je nemozne podchytit vsechny mozne kombinace

Možné to je a běžně se i ta data ukládají do relačních databází. Už jsem adresu na pár nečeských webech vyplňoval a téměř vždy bez problémů – státy světa jsou obvykle jako číselník a zbytek nějaký varchar, tam se vejde všechno. Občas mají kraje/provincie své země jako číselník, ale pokud to nepsalo pako, tohle políčko není povinné, pokud nejsi z daného státu.

[deda.jabko]

Ta struktura je předem známá. Resp. pokud v zadání máme, že budeme podporovat adresy různých zemí, nemůžeme klást příliš velká omezení, ty struktury budou volnější. ... státy světa jsou obvykle jako číselník a zbytek nějaký varchar, tam se vejde všechno.

takze s SQL si muzu vybrat, ze adresa bude bud (1) struktura ktere neodpovida presne vsem pozadavkum (US adresa vs. adresy ze vsech statu sveta), (2) nejaky BLOB (varchar). a co kdyz budu v pripade (2) chtet vyhledat vsechny lidi, co bydli treba v texasu? je opravdu tak tezke priznat si, ze jsou situace, kdy SQL a relacni databaze s pevnou strukturou tabulek nejsou uplne nejlepsi reseni?

[xkucf03]

A jak mi s tím nosql pomůže? IMHO nijak, protože zatímco v relační DB budu mít hnůj jen tam, kde je nutný (kraje/provincie u cizích států) v nerelační databázi budu mít hnůj všude (budou tam samé dvojice klíč-hodnota bez pevné struktury).

Pokud budu v relační tabulce řešit kraj nikoli odkazem na číselník krajů, ale jako varchar, tak jsem na úrovni nosql databáze – v tomto ohledu (můžu zadat libovolný kraj/provincii i z jiného státu), jinak jsem samozřejmě nad její úrovní, protože už při prvním pohledu na databázi je jasné, že tady máme nějakou entitu adresa a ta obsahuje atributy stát, město, ulice atd. – a nemusím kvůli tomu zkoumat data nebo zdrojový kód, abych zjistil tyhle základní informace.

[deda.jabko]

IMHO nijak, protože zatímco v relační DB budu mít hnůj jen tam, kde je nutný (kraje/provincie u cizích států) v nerelační databázi budu mít hnůj všude (budou tam samé dvojice klíč-hodnota bez pevné struktury).

bez fantazie to jde tezko... neprogramujes nahodou v jave?

IMHO jedno z reseni je mit entitu adresa, ktera bude mit vic tvaru napr. ,,cz-adresa'' (majici atributy: ulice, cislo popisne/orientacni, mesto, psc, zeme) a pak treba ,,us-adresa: cislo popisne, ulice, apt/suit, mesto, zip, stat, zeme'' a pak treba obecna adresa: ,,radek1, radek2, radek3, zeme'' ... ano jde to udelat i v relacni db, ale neni to zrovna nejhezci...

skutecnost, ze mas vic typu adres, musis resit v DB i v aplikaci... bez schematu ten problem resis jen v aplikaci

Pokud budu v relační tabulce řešit kraj nikoli odkazem na číselník krajů, ale jako varchar, ...

...nechapu k cemu se to vztahuje...

[podlesh]

Hezké příklady, ale neukazují nedostatky relačních databází a předem daných schémat, ale chybu analýzy.

To je právě ono - těch chyb analýzy je v reálné praxi až moc a v podstatě největší problém jaký v oblasti softwarového inženýrství existuje (a se kterým se již alespoň 20 let bojuje). Ne-SQL je prostě jenom jeden z další řady pokusů a zlepšení situace jako bylo OOP, agilní metodiky, dnes třeba funkcionální programování či dynamické jazyky.

Osobně si nemyslím že by to byla nějak zvlášť úspěšná vlna, na většinu stávajících problémů je asi relační databáze lepší. Ale na tom vůbec nezáleží, jediné důležité je co ukáže praxe. A to ať si každý vyřeší sám, zda si pro svůj projekt zvolí správně.

[deda.jabko]

To je právě ono - těch chyb analýzy je v reálné praxi až moc a v podstatě největší problém jaký v oblasti softwarového inženýrství existuje (a se kterým se již alespoň 20 let bojuje)

obavam se, ze moc zpusobu, jak zlepsi kvalitu analyzy neni... a je spis potreba podivat se na zpusob vyvoje, ktery umozni efektivne reagovat na nedostatky (a omezene moznosti analyzy)... viz ony agilni metodiky nebo ,,dynamicke'' jazyky...

Osobně si nemyslím že by to byla nějak zvlášť úspěšná vlna, na většinu stávajících problémů je asi relační databáze lepší.

relacni db jsou na spoustu veci dobre... ale treba u tech webovych aplikaci zacinam pochybovat a myslim, ze veci typu couchdb muzou pomoct prekonat nektere problemy...

par let zpatky jsem byl deprimovany z toho, jak zakaznici neustale meni pozadavky a ovlivnen dynamickymi jazyky a hlavne schemem jsem si napsal hybrid mezi ORM a no-sql db (tehdy jsem ani nevedel, ze neco takoveho existuje)... a prekvapilo me, jak to zrychlilo vyvoj a udrzbu cele aplikace...

[xkucf03]

obavam se, ze moc zpusobu, jak zlepsi kvalitu analyzy neni

A co kdyby analýzu nedělal ten, kdo neumí programovat, ale ten, kdo má analytické myšlení?

[xkucf03]

Nad relační databází zase řešíš hned dva jazyky zároveň

A to je problém? Běžně můžeš mít v aplikaci pět jazyků:

• SQL – práce s daty
• Java – aplikační logika
• JSP a spol. – prezentační logika
• JavaScript – nějaké drobnosti na straně klienta
• XSLT – občas přešukat dokument z jednoho formátu do jiného

Je to moc? Bylo by lepší to psát všechno jedním jazykem? Kterým?

[Senior Database Programmer]

Zas na druhu stranu treba povedat ze aj napriklad IBM Lotus Domino je vlastne dokumentovo orientovana databaza (ktora moze bezat nad DB2) kde dokument nema pevny format a robia sa v tom velke informacne systemy...

[xkucf03]

A není to tak, že si tam naklikáš formuláře a z nich je ta struktura dokumentů odvozená? Takže to nějakou celkem pevnou strukturu má (byť se dá snadno měnit). S několika takovými aplikacemi jsem pracoval (jako uživatel) a nějak moc příjemný zážitek to nebyl. Ale asi se pomocí toho dá vytvořit aplikace velice snadno, což se počítá.

[Ladicek]

Jo, Lotusy. Nikdy jsem se s tím nesetkal, ale za CouchDB stojí Damien Katz

[okbob]

Ano, velké systémy se v tom produkují. Je to docela dobrý příklad na kterém lze ukázat výhody a nevýhody bezschémových db. Na jednu stranu poměrně snadné rozšiřování, na stranu druhou nijak neohromující rychlost.

[dark]

OT: Co používáš v jave pro práci s JSON, já jsem zkusil snad všechny možné knihovny, a moc spokojený nejsem:(

[xkucf03]

Čas přejít na XML

[dark]

To se mi moc nechce, s JSON se mi hodně dobře pracuje v js, ale podpora v javě je podle mě nedostatečná (serializace/deserializace objektů na základě nějakého schéma zůstane asi jen jako sen). Předělávám jednu app z pythonu a tam se s JSON pracovalo mnohem líp (zatím jediné plus pro python:))

[Ladicek]

Upřímně řečeno, nic. JSON-lib docela pěkně funguje s Groovy, kde je syntaktický cukr pro mapy a seznamy, přímo v Javě bych pro nějaké serióznější věci asi zvažoval Jackson.

[dark]

Mám trochu větší nároky, json-lib mi nestačí, ale nevyhověl mi ani ten jackson.

[Ladicek]

To chápu, ale myslím, že konkrétně v Javě nevyhoví asi nic, protože mezi statickým světem Javy a dynamickým světem JavaScriptu (jehož je JSON podmnožinou) asi vždycky bude nepřekonatelná propast. Jackson mi přišel, z těch pár letmých pohledů, filozoficky příbuzný s XStreamem, který bych si vybral pro (de)serializaci XML.

JSON-lib se mi líbí konkrétně pro Groovy, protože jeho třídy implementují Map a List, takže je lze použít se syntakticým cukrem [name: "Ladicek", age: 27] nebo ["sci-fi", "fantasy", "horor"]. Ale v tom mi asi rozumíš, a máš svoje důvody, proč Groovy nepoužít.

[Trained.Monkey]

Diky za pekny uvod do CouchDB. Moc me to ale nenadchlo. Zustanu u nenavideneho SQL + pripadna serializace.

[default]

Jako — serializovat Javí objekty do BLOBů?

[xkucf03]

Serializovat se dá i do XML. Proč ne? Když už se tu takhle prasí (nosql), tak mi přijde lepší ta serializace – ta aspoň znamená bezbolestné mapování na objekty. A pokud se bude serializovat do XML, tak se v těch datech může člověk hrabat i z jiného jazyka nebo v nich nějak vyhledávat atd.

[mich]

Proč by se človek nemohl hrabat v datech uložených v bezschémové databázi "z jineho jazyka"? Nějak nechápu co je tím myšleno. (Taky mi teda uniká to bezbolestné (vs. bolestné) mapování na objekty)

[xkucf03]

Taky mi teda uniká to bezbolestné (vs. bolestné) mapování na objekty

Serializace a deserializace je velice snadné uložení a načtení objektu, asi to nejsnadnější.

Proč by se človek nemohl hrabat v datech uložených v bezschémové databázi "z jineho jazyka"?

To bylo myšleno jako výhoda serializace do XML oproti serializaci do nějakého blobu.

Ale připomněl jsi mi tím jednu věc, kterou jsem chtěl napsat už dřív. Databáze se schématem IMHO daleko líp podporuje vrstvenou architekturu. Typicky: data → aplikační logika → prezentační logika. Takže když dojdeš k tomu, že aplikace není už dost dobrá a chtěla by přepsat, můžeš si nechat databází a vyměníš jen tu vrstvu nad tím. Když je ale „schéma“ definované ve zdrojovém kódu aplikace…

[mich]

Má jediná zkušenost s NoSQL databázemi je chvilka hraní si s mongodb, takže teď trochu vystřelím od boku (snad to nebude vypadat, jako že se snažím NoSQL hájit za každou cenu). Proč bys nemohl mít tenkou DAO vrstvu pro přístup k databázi a nad ní zbytek?

[xkucf03]

To by šlo, ale pak je člověk vázaný na jednu platformu, programovací jazyk – přechod někam jinam je dost pracný. Nemluvě o tom, že občas potřebuješ k jedné databázi přistupovat z různých jazyků – pak se ta DAO vrstva (která není jen DAO, ale obsahuje v sobě i „schéma“) musí duplikovat.

[Ladicek]

Binární serializace z programovacího jazyka typu Java má jednu zásadní výhodu: vůbec neřeší verzování, takže při pokusu deserializovat stream vyrobený předchozí verzí aplikace může normálně dojít k neřešitelnému problému. Naopak serializace do samostatného formátu, ať už je jím XML nebo JSON, má tu obrovskou nevýhodu, že deserializace zabere přibližně o jeden řádek kódu navíc

Ne, vážně: vrstevnatá architektura je super. Ale jen málokdy je tak dokonalá, že sama od sebe umožní výměnu kterékoli z vrstev. To je argument spíš teoretický, v praxi (aspoň podle mých zkušeností) je mezi jednotlivými vrstvami tolik implicitních vazeb, že prostě nejde bezproblémově vyměnit jednu za druhou.

Naopak když je datové schéma definované aplikací, je tu právě jedna vrstva, ze které lze zjistit všechno. Naopak dnešní obvyklé způsoby vývoje přímo vyžadují duplikaci schématu: jednou je v aplikaci (sada tříd v programovacím jazyce), jednou v databázi (definice tabulek), a konverzní vrstva mezi nimi je často automatická (ORM) a vyžaduje další týdny studia (a obzvláštní psychickou odolnost, pokud jde o Hibernate a podobné molochy ).

[bezny uzivatel]

tady vubec nejde o nenavist, problem je mnohem hlubsi. To uplne vysvetleni podal jiz pred mnoha lety jeden z nejvetsich myslitelu lidstva ve svem pruslulem dile 'Cisarovy nove saty'.

Autor blogu (ladicek) je onim malym chlapcem, ktereho nechava Anderssen volat 'vzdyt on je nahy'. Ale po rade.

Pred 10 lety nebylo mozno vubec vyslovit, ze na SQL je neco v neporadku. Kdyz to nekdo zkusil, tak mu bylo vytceno (treba panem Stehule), ze se nedokazal odpoutat od toho dBase mysleni a ze zaspal dobu. Lide pouzivajici MySQL byli oznaceni za debily a jejich prace byla diskreditovana, protze ta 'spravna' prace s daty je mozna pouze pres referencni integritu. Mladsi rocniky vubec nevi, ze data je mozno ukladat i jinam nez do relacni databaze. Tak by to bylo naveky, kdyby se neobjevil google a Amazon.

Obe zminene firmy si velmi dobre spocitaly, kolik by musely platit jen na licencich za ty servry rozestavene po svete, kdyby ny nich bezela Oracle ci DB2. A to nehledime vubec na tu technickou stranku veci. Az nyni bylo mozno rici, ze relacni databaze se nedaji pouzit na vsechno. A nekolik odvaznych se dokonce rozhodlo volat NoSQL. A nyni nastava zajimava situace.

Predstavme si, ze kriticky pohled na relacni databaze a dotazovaci jazyk SQL zustane jeste nejakou dobu aktualni. Pak se dokonce muze stat, ze se nekdo obecneji poohledne po aplikacich, ktere se bezne pouzivaji. A zjisti se, ze znacne procento (urcite pres 90%) vubec zadnou relacni databazi nepotrebuje. Ze je mozno vse drzet v pameti. Ze programatori dokazou bez velkych skoleni za 5 minut pochopit, jak pracovat s udaji typu klic/hodnota a mohou zrovna tak dobre realizovat zakacnicak prani. Ano, najednou se rozplyna ta mlha a rel. databaze s celou SQL se nam objevi plne nahote.

To by melo samozrejme dalekosahle dusledky. Zejmena pro ty, kteri si nashromazdili SQL znalosti, triky a vychytavky. Najednou nemaji proti 'ladickum' zadnou vyhodu. To nelze samozrejme pripustit. Prece to vidi kazdy, ze zeme je placata.

[Yenda]

Ano, souhlasím. Navrhuji Ladicka, jako každého proroka, ve jménu pokroku ukřižovat.

[Ladicek]

Nemám námitek, pokud to bude bezbolestné. No a pokud si mne pak z hrobu přijdou vyzvednout nějaký hezký holky, tak už vůbec

[Yenda]

Kdepak, zažiješ učiněnou extázi bolesti. No a ty hezký holky? Nevím. Nestačili by ti staré bigotní programátorky COBOLu?

[Ladicek]

Programátorky v COBOLu nebo ve Fortranu by pro mne byly učiněným požehnáním Extáze bolesti? Přinejmenším teoreticky mám nastudováno, Zjizvená noc Alana Campbella je v tomto ohledu velice poučná

[okbob]

Četl jste vůbec tuto diskuzi?

Myslím, že z ní by mělo být jasné, k čemu a jak se hodí/nehodí SQL nebo NoSQL databáze.

Na rozdíl od Vás Ládíček tu argumentuje věcně - a lze s ním argumentovat. Pro Vás je SQL přehmat, omyl, a to je asi tak veškerá Vaše argumentace posledních pět let.

P.B. ví co bude za pět let - osobně si myslím, že nic moc se nezmění, v každém případě ti co mají znalosti, budou mít navrch nad těmi, co znalosti nemají. I kdyby SQL už nefrčelo, tak jenom schopnost jednoznačně definovat problém se hodí. Základy sw inženýrství jsou stejné cca 30 let - vždy na tom budou lépe, ti co vědí před těmi, co bodou tvrdit, že znalost je nedůležitá.

[okbob]

Ukazte mi prosim tech 90% procent aplikaci, ktere nepotrebuji relacni db, prosim. Popiste mi je, vysvetlete mi, proc bude pro ne pouziti relacni db na skodu - mimochodem dbase je take relacni db - a jakou vyhodu ma pouziti nerelecni databaze. Nemuzu si pomoci, mozna to nejste vy, mozna to je nekdo jiny, pod vetsinou mych clanku se objevi osoba, ktera mne osocuje z toho, ze bych predhazoval nevinatka tygrum.

Fakt nemam zadnou averzi k tomu ci onomu na zaklade sw, ktery pouziva. Obcas mam vyhrady, kdyz mam po nekom cistit data, rozhybat databazi - ale to kazdy.

[bezny uzivatel]

zde doslo asi k nejakemu nedorozumneni. Prispevek byl minen jako polemika a vubec nema s nejakymi argumenty co do cineni. A take je jmeno Stehule pouze symbolem pro nekoho, kdo reprezentuje skupinu SQL vyvojaru s mnozstvim znalosti, ktere mohou byt jednoho dne mene hodnotne.

Kdyz si prohledne clovek diskuze na celem svete k teto problematice, tak cte v rade komentaru, ze rel. databaze s SQL resi problemy, ktere by bez nich vubec neexistovaly. A i zde uz zacinaji nekteri uzivatele (deda.jabko) pochybovat, zda se sql pro web hodi. Jinak argumenty zde nepadly vubec zadne, i ladicek predklada pouze sve mineni. Mereni, vyvojove naklady apod - nic.

Jako exemplarni priklad je mozno uvest to ucetnictvi winstrom. Panove z te firmy chteli pro mensi aplikace neco mensiho nez pgsql ale derby nesla, protoze ta sql je rozlisna (jedna z nich nema limit a jinak je to s offsetem ci co). Tak firma nabizi na vyzkouseni balik s pgsql a jenm kvuli tomu instalatoru investovali mesice. A to vsechno, aby si mohl uzivatel zauctovat par desitek faktur, mnozstvi dat, keter se vejde na disketu. Tady se proste drbe nekdo levou nohou za pravym uchem, protoze SQL byt musi.

Moje zkusenosti jsou, ze kazda vyrobni firma do 500 milionu kc (250 lidi, 80 pc) muze jet na systemu bez relacnich databazi (napr. byl nahodne zde pred nedavnem clanek o systemu ABAS odnekud ze zapadu). Takova firma ma cisty objem dat ca 4 GB - 10 let statistiky). Male firmy s 5 pc, obchodem, skladem, nakup, prodej apod maji objemy dat do 500 MB, vetsinou 50-200 MB. To vse je mozno drzet v perlovskych hashich v pameti pres mmap. V zadne z takovych firem se nenjde jediny pracovnik, ktery by byl schopen odsadit jen ten nejjednodussi sql statement. A to je tech 90 % firme, ktere tu relacni technologii nepotrebuji.

Dodam, ze jsem videl radu malych aplikaci, ktere funguji s interbase a to proto, ze borland kdysi tuto technologie na pc udelal popularni. Uzivatele o te databazi vubec nic nevi a 'vyhody' toho sql tedy nemohou vubec vyuzit. A programatori tech aplikaci, ktere jsou uzavrene a letite z toho dnes samozrejme nemaji take zadne vyhody - ty aplikace se proste udrzuji pri zivote.

Ale to vsechno je jen na okraj. Dulezite je, ze se o tom mluvi a dnes kdyz nekdo prijde s resenim bez rel. databaze a sql, tak hned neprohral.

[okbob]

hmm.. tak prosim vysvetlete jak budete v perl hashi resit vypadek - jak v pripade zmeny dodavatele budete resit migraci dat? Jak budete resit monitoring?

Na SQL databaze, obecne na relacni databaze se nepreslo jenom kvuli nejake modni vlne, ale protoze programator nemusi resit konzistenci dat, multiuser pristup, prava. Tohle Vam perl hash neudela - vsimnete si, memcached - to, je presne to, co popisujete - nevsiml jsem si, ze by nekdo psal ucetnictvi v memcached.

Jinak interbase je klasicka relacni SQL db, to ze je zawrapovana do komponent - ok, totez muzete provadet s VB a JET enginem od Microsoftu, pripadne dalsimi db. Ja jsem si vyzkousel vsechny db pocinaje rokem 93, a pouzivani komponent je masochismus, ale je to kazdeho vec. Vas argument o pametovych hashech neberu - pokud ma programator alespon trochu soudnosti, tak je to nepouzitelne - nemate vubec zadne zajisteni v pripade vypadku, havarie.

[xkucf03]

Moje zkusenosti jsou, ze kazda vyrobni firma do 500 milionu kc (250 lidi, 80 pc) muze jet na systemu bez relacnich databazi

A co třeba naše škola? Máme kolem 20 000 studentů + zaměstnanci + všichni bývalí uživatelé. Studijní systém běží samozřejmě nad relační databází, kupoval se na to Oracle za pěkných pár mega (IMHO spíš nepěkných). Systém se stará o veškerou studijní agendu (akorát účetnictví je zvlášť). Na tohle bys taky nasadil NoSQL nebo je to už za tou hranicí, kdy se systém dá ukočírovat bez jasného schématu a SQL?

Kdybych to měl dělat já, tak Oracle bych si asi nevybral, ale bez relační databáze bych si takový systém nedokázal představit (resp. dokázal, ale ta představa by pak byla taková, že projekt dopadne blbě a asi se systém vůbec nespustí).

[Käyttäjä 11133]

A co by si vybral? MS SQL? :)

[Heron]

Access

[default]

Excel

[xm]

Bohatě by stačil PostgreSQL nebo Firebird.

[thingie]

Hm. Tak nějak tipuju, že se mluví o VŠE. Která asi povždy bude ve věci pořizování IS vyvolávat lehké úsměvy.

[Vašek Lorenc]

VŠE používá IS z dílen Mendelovy univerzity v Brně? (jen se ptám, má pocit, že něco takového jsem slyšel..)

[thingie]

Vypadá to, že je tomu tak. Přímo od velikého Šorma.

[xkucf03]

Koukám, že je slavný, no nebo aspoň známý

[thingie]

O drbech o něm lze s určitostí říct, že se nikdy nezastaví.

[Trained.Monkey]

VSE pouziva Oracle nebo MSSql

[xkucf03]

Oracle. MSSQL tu mají snad leda jen nějací MS nadšenci na hraní.

[Trained.Monkey]

> Pred 10 lety nebylo mozno vubec vyslovit, ze na SQL je neco v neporadku.

Nastuduj si historii. 'noSQL' se objevuje velmi pravidelne od zacatku 90tych let. Teprve ted se mu dostalo pozornosti diky clusterum. A pracovat s key/value db je fakt opruz.

[Ladicek]

Abych se vyjádřil: autor blogu se považuje spíše za nosiče ryb, který má pocit, že v .cz by se o tématu mělo mluvit víc, než se děje (pár článků nebo blogů jsem zaznamenal, ale bylo jich dost málo). Nepovažuje se za odborníka na dané téma, vlastně se nepovažuje za odborníka na žádné téma, ačkoliv o spoustě témat s oblibou odborně žvaní, ale tak nějak neviděl jinou možnost

[Ladicek]

Jo a ještě: autor článku moc děkuje všem (až na výjimku) čtenářům za velmi pěknou a přínosnou diskusi.

[Ladicek]

Dostal jsem od Roberta nabídku vydat seriál na ábíčku, takže upozorňuju, že dojde k jedné nepříjemné změně: budu muset vyhodit všechny ty krásné výpady proti relačním databázím a databázistům, na kterých jsem si dal tak záležet. Díky za pochopení

[alblaho]

Směju se, neochuzen, pod fousy

[xsubway]

Rozhodně to nevadí. Ukázalo se, že rýpání má někdy za následek celkem slušnou diskuzi. Takže díky. Já nebudu jak Nárožný křičet: "Je to Rebel!" [1]

[Pavel Křivánek]

Existuje nějaká knihovna pro práci s CouchDb přímo z JavaScriptu? Našel jsem akorát zastaralou JQCOUCH a nějaké rozšíření pro ExtJS. Futon používá svoji malou knihovničku, ale ta např. nedokáže připojení k externí databázi.

[Ladicek]

Já jsem pro účely takového malého bastlení (bude ve třetím díle) vzal tu knihovnu z Futonu (jquery.couch.js) a pár kratičkými zásahy (do 10 řádek kódu) jsem ji rozšířil o možnost připojení k externí databázi (definováním prefixu URL). Problematické je ajaxové volání přes různé domény, protože CouchDB ještě nepodporuje Cross-Origin Resource Sharing (http://www.w3.org/TR/access-control/, http://issues.apache.org/jira/browse/COUCHDB-431) – to jsem řešil použitím proxy ve webovém serveru. To je samozřejmě použitelné jenom z prohlížeče, ale podle knihoven, které jmenujete, vám jde přesně o tohle.

[Pavel Křivánek]

Konkrétně jsem chtěl otestovat použití CouchDB v lokální JavaScriptové aplikaci pro XULRunner (resp. firefox -app). Takže pak by se daly psát celkem jednoduše už poměrně rozsáhlé aplikace s nativním GUI přímo v JavaScriptu bez mezičlánku webového serveru. Dá se tak využívat v aplikacích třeba kombinace XUL/HTML/SVG a přímého přístupu k lokálním souborům či procesům klienta atd.

Určitě si zkuste zaprasit i tímto směrem

[Ladicek]

To je pěkná myšlenka. Zajímalo by mne, jestli XULRunner povolí to AJAXové spojení na databázi (mohl by, aspoň při nějakém nastavení, lokální aplikace je přece jenom důvěryhodnější).

Jinak fakt žeru, kam všude CouchDB přirozeně zapadne!

[Pavel Křivánek]

Určitě, přes AJAX zobrazuju v XULRunneru celé Smalltalkovské IDE i s debuggerem

http://www.youtube.com/watch?v=pkfSh4pAbdM

[Pavel Křivánek]

Dobře a propracovaně vypadá /usr/share/couchdb/www/script/couch.js, která se používá pro unit testy ve Futonu a není ani závislá na dalších knihovnách krom JSONu. Tam stačí pro externí databáze změnit jen metodu CouchDB.request

[Senior Database Programmer]

Dnes vysiel na Roote tento clanok ako pouzivat MySQL ako noscheme databazu: MySQL v roli neschémové databáze

Autor pise ze uvazoval aj nad CouchDB ale nakoniec ju nepouzil lebo si nebol isty ci je pouzitelna aj pre velky objem dat...Nakoniec skoncil tak ze do MySQL uklada bloby (zoserializovane a zkomprimovane pythonovske datove struktury). Aj tak sa da SQL databaza znasilnit a funguje to...

[Ladicek]

Jak používají MySQL ve FriendFeedu je hodně pěkný článek, při objevování světa NoSQL na něj narazí asi každý.

[xm]

Moc pěkný článek! A zároveň moc pěkná případová studie ukazující výhody NoSQL přístupu.

[Heron]

Ten článek (četl jsem překlad) je divnej. Zahodili SQL jen k vůli par nedostatkům jednoho DB serveru přičemž zrovna ty co jim nejvíc vadí jiný server nemá, místo toho jej použili jako skladiště většího množství souborů a pak si vytvářejí vlastní index pomocí tabulky v dané DB, kterou ale nechtějí. Nu což, alespoň se tím vysvětluje, proč některé stránky fungují tak jak fungují.

[xm]

Vývojáře FriendFeedu bych si opravdu netroufal považovat za nějaké "bastliče" Jsou mezi nimi i tací lidé jako třeba Paul Buchheit, autor GMailu. Pokud vím důkladně zvažovali všechna možá řešení a tohle se ukázalo jako pro ně nejvhodnější. SQL prostě nepotřebují, MySQL nadále využívají proto, že s ním mají dobré zkušenosti, do detailů jej znají a jako data storage ho mají velmi dobře prověřený. Ostatně i Google používá právě MySQL.

Zdá se mi že tvůj pohled je silně ovlivněn zkušenostmi s relačními databázemi a nejsi moc otevřen jinému přístupu... což ostatně v diskuzích které jsem na ABCLinuxu k těmto tématům četl platí o spoustě lidí (to jak byl třeba Ládíček označován v předchozí diskuzi za "prasiče" mě vážně rozesmálo ).

[Michal Vyskočil]

Nemělo tam být relační databázi prostě nepotřebují? SQL se v případě MySQL asi těžko vyhnou.

[xm]

Mělo Tak to dopadá když si to po sobě nepřečtu

[Heron]

Zdá se mi že tvůj pohled je silně ovlivněn zkušenostmi s relačními databázemi a nejsi moc otevřen jinému přístupu...

To ani omylem. Já nejsem žádný SQL guru ani fanatik, od obého tu jsou jiní . Naopak bych velmi ocenil článek typu: "máme miliardu záznamů a takhle to děláme efektivněji než to skladovat v relační DB". Tenhle článek je typu, "tu miliardu záznamů máme sice pořád v DB, ale věci které tento konkrétní DB server neumí si děláme bokem".

Zkrátka z toho článku mám pocit, že změnou schématu či db serveru by dosáhli téhož mnohem efektivněji, přičemž nepochybuji o jejich odborných kvalitách.

[xm]

Oni si prostě napsali vlastní dokumentovou databázi s použitím MySQL jako kvalitního backendu. Nevidím na tom nic "nečistého" či nepraktického, oproti tomu kdyby psali vlastní dokumentovou databázi od píky si ušetřili obrovskou spoustu práce s vývojem a oproti tomu kdyby použili nějakou už hotovou dokumentovou databázi si zas ušetřili spoustu práce s předěláváním infrastruktury (tu pro MySQL měli už hotovou) a řešením problémů s jimi neprověřenou databází s kterou nemají žádné zkušenosti.

Já to vidím zkrátka jako win-win situaci

[okbob]

U tohoto článku jsem uchcával smíchy. Místo toho, aby udělali krok kupředu, tak udělali přemet - navíc, kdyby vyhodili MySQL, tak by měli po problémech - slušné db dokáží generovat index za chodu, i alterovat tabulky bez zamykání.

Pořád jsem přemýšlel proč se tu argumentovalo, problémem s modifikací tabulek - to přece problém není. A ejhle je - na MySQL.

[xm]

A proto MySQL používá např. takový Google, že Já zas uchcávám smíchy z příspěvků zarytých "databázistů", kteří mají nezvladatelnou potřebu vždycky v každé diskuzi poukazovat na to jak je MySQL ve všem špatná a vysmívat se všem kteří jí používají. Neuvědomují si, že na spoustu druhů nasazení (troufám si tvrdit, že dokonce na většinu webových aplikací - i když na spoustu z nich by ještě mnohem lépe pasovala dokumentová nebo objektová databáze) je to výborná volba, lepší než spousta tzv. "profesionálních" RDBMS.

Jinak k FriendFeedu viz můj příspěvek Heronovi výše...

[okbob]

Ta databáze je tak super, že na to aby se řešilo něco tak základního jako je refresh indexů se používá konstrukce, nad kterou zůstává rozum stát.

[thingie]

A mě třeba nebaví číst tyhle komentáře, které ničemu nepřidávají, leda k tomu vzájemného výsměchu tady, narozdíl od toho předešlého, kde byla aspoň nějaká myšlenka co se dalo/mělo dělat.

[okbob]

Přečtěte si ten článek ještě pls. Pokud by vývojáři nelpěli na MySQL, tak by nemuseli vytvářet natolik obskurní konstrukce. Vůči jejich řešení je např. CouchDB elegantnost a jednoduchost sama.

[Petr Tomášek]

Co je špatného na E-Tag?