Přejít k navigační liště

Zdroják » Databáze » Přechod z MySQL na CouchDB, část první

Přechod z MySQL na CouchDB, část první

Články Databáze

Pokud máte databázi postavenou na MySQL, možná jste zvědaví, jestli, a hlavně jak, je možné s vaší databází přejít na CouchDB. Největší překážkou není technická stránka vytvoření CouchDB nebo ukládání informací; nejnáročnější je začít uvažovat o datech jiným způsobem a uvědomit si, jak to změní logiku vaší aplikace.

Nálepky:

Disclaimer: Článek je překladem článku How to move from MySQL to CouchDB z blogu CouchOne. Překlad i s originálními ilustracemi vychází s laskavým svolením společnosti CouchOne. Autor článku pracuje v CouchOne jako člen výboru a viceprezident pro dokumentaci, v minulosti psal dokumentaci k MySQL.

qrcode

K článku není ukázka

K článku není k dispozici zdrojový kód

Začneme tím, že se podíváme, jak lze strukturu databáze v MySQL převést na CouchDB, a jak se dotazy na CouchDB liší od způsobu používaného v MySQL.

Úvodní zamyšlení nad strukturou dat

MySQL (a další SQL databáze a jiné databáze založené na tabulkách) vás nutí uvažovat o datech jako o tabulkách. Všechna vaše data tvoří tabulku a při ukládání složitých struktur může být jedna informace rozložena do více tabulek. Pro některé aplikace a datové typy je to naprosto logická a rozumná forma uložení dat a přístupu k nim. Ale někdy tabulková struktura příliš neodpovídá datům, které chcete ukládat.

Ukažme si to na typickém příkladu, databázi receptů. To je něco, co dobře znám, protože server Cheffy.com je postavený na MySQL. Jádro databáze tvoří tabulka nazvaná recepty (Recipe), která obsahuje název receptu, podtitul, popis a počet porcí. Další údaje vztahující se k receptu, jako je seznam přísad (Ingredients), postup práce (Method), metadata a klíčové slova (Keywords), jsou uložené v dalších tabulkách, navázaných k samotnému receptu pomocí unikátního ID receptu. Velmi zjednodušeně je to vidět na následujícím obrázku.

Tato struktura může mít své výhody – určité operace mohou být například velmi jednoduché a přímočaré. Například: chcete najít všechny recepty, mezi jejichž přísady patří „mrkev“? Můžete nad tabulkou přísad vykonat dotaz na „mrkev“, a z něj získat seznam odpovídajících receptů. Za pomoci spojování tabulek můžete získat seznam receptů, jejich názvů a dalších informací z tabulky recepty tak, že budete hledat v tabulce přísady a přes ID receptu spojíte tuto tabulku s tabulkou recepty.

Zatímco tento způsob vyhledávání je jednoduchý, získání všech údajů o receptu, například pro jeho zobrazení uživateli, může být skutečně složité. Šlo by to jedním dotazem, ale někdy to bývá snazší pomocí více dotazů: jedním k němu získat údaje z tabulky recepty, druhým jeho přísady, dalším metadata atd. To vše je automaticky vykonáno v rámci aplikační vrstvy a výsledkem je objekt, který se pak použije jako základ pro formátované zobrazení receptu uživateli.

Ve většině aplikací je buď pro tento účel vytvořena speciální vrstva, a nebo se použije jeden z mnoha objektově-relačních mapovacích systémů, které mapují data ze struktury tabulek na vrcholový objekt, se kterým pak pracuje aplikace (a uživatel). Recepty jsou jen jedním z příkladů, obdobně je na tom i mnoho jiných různých aplikací, včetně fakturace (faktura, dodavatel, místo určení, položky faktury) a příspěvků na blogu (obsah příspěvku, klíčové slova, autor, komentáře).

Tento přístup založený na tabulkách není z principu špatný, ale v této situaci je zásadní informace rozložena do více tabulek, 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 (buď ručně, nebo pomocí klauzule ON DELETE CASCADE). Obdobně také při načítání údajů jednoho receptu budete muset nakonec provést 5-10 dotazů na data.

CouchDB volí jiný přístup. Namísto více tabulek, do kterých se ukládají různé typy informací, do CouchDB ukládáte jeden typ struktury dat ve formátu JavaScript Object Notation (JSON). Formát JSON umožňuje sloučit jakkoliv složitou strukturu atributů, polí, objektů a skalárních typů do jednoho záznamu. To znamená, že nyní můžete vaši starou entitu, rozprostírající se skrz několik tabulek, vyjádřit jako jeden „dokument“.

{
   "title" : "Carrot and Coriander Soup"
   "servings" : 4,
   "subtitle" : "Delicious with wholemeal bread",
   "ingredients" : [
      {
         "amount" : 250,
         "ingredient" : "Carrots",
         "measure" : "g"
      },
      {
         "amount" : 75,
         "ingredient" : "Coriander",
         "measure" : "g"
      },
      {
         "amount" : 250,
         "ingredient" : "Vegetable Stock",
         "measure" : "ml"
      }
   ],
   "method" : [
      {
         "step" : 1,
         "instruction" : "Chop carrots"
      },
      {
         "step" : 2,
         "instruction" : "Cook all ingredients in pan"
      },
      {
         "step" : 3,
         "instruction" : "Liquidize"
      }
   ],
}

Teď je vše, co můžete chtít dělat s vaším receptem, na jednom místě, a můžeme ho načíst z databáze CouchDB v rámci jedné operace.

Databáze nemá žádnou definici dat či obsahu – každý dokument v databázi CouchDB může obsahovat cokoliv v jakékoliv struktuře. Můžete ale při ukládání dokumentu do databáze ověřit jeho strukturu provedením validační procedury. Validace se může týkat jak položek, tak jejich obsahu.

Také si uvědomte, že tato neexistence pevné struktury dat přináší větší volnost v tom, jaké údaje ukládáte, a jak. Pokud chcete do vašeho dokumentu obsahujícího recept přidat nový oddíl pro uchování dat, kdo recept vložil, stačí jen rozšířit strukturu dokumentu.

Neexistuje také představa více tabulek. Existuje jen databáze, a dokumenty obsažené v této databázi. Pokud chcete podporovat různé typy údajů v jedné databázi, pak můžete přidat další položku do dokumentu. Pro identifikaci receptu byste například mohli použít:

{
   "type" : "recipe",
   "title" : "Carrot and Coriander Soup"
   "servings" : 4,
   "subtitle" : "Delicious with wholemeal bread",
...
}

Tato identifikace typu záznamu může být použita v jiných částech databáze pro rozpoznání (a výběr) dat, které se mají nahrát.

Pokud je všechno dokumentem, jak vybrat seznam záznamů?

V první části jsem ukázal, jak sestavit jednoduchý SQL dotaz, který z MySQL databáze vybere seznam všech receptů, mezi jejichž přísady patří mrkev. V MySQL se to udělá tak, že se vyhledává v tabulce přísad a pomocí získaného ID receptů se tato tabulka spojí s tabulkou recepty, z níž lze vyčíst názvy receptů. Kvůli zlepšení rychlosti provádění dotazu byste obvykle použili index, který ušetří postupné procházení jednoho záznamu za druhým.

CouchDB považuje všechno za dokumenty, a neposkytuje způsob, jak hledat podle určitého sloupce tabulky, protože v ní nejsou žádné sloupce ani tabulky. Když ale její záznamy nemají pevnou strukturu (a databázový engine nedokáže identifikovat datové položky v dokumentu bez pevné formy), jak pak provést operace, které normálně pracují nad seznamem nebo tabulkou? Všechny dotazy, počínaje jednoduchým „Vypiš všechny recepty“ až po „Najdi všechny recepty, do kterých patří mrkev“, totiž spoléhají na to, že někde existuje nějaký seznam.

CouchDB podporuje databázový konstrukt nazvaný pohled (anglicky view). Pohledy v CouchDB jsou v principu velmi podobné pohledům v MySQL, jen s tím rozdílem, že v CouchDB nejsou pohledy pouze jednou z více možností, ale jsou jedinou cestou, jak získat z databáze seznam dokumentů. Pohled ve skutečnosti určuje tři věci:

  • strukturu dat obsažených v pohledu. Lze na ni pohlížet stejně jako na definici struktury tabulky, tak jak se zadává v MySQL.
  • sloupce a data, v kterých lze vyhledávat. Výstupem pohledu jsou totiž dvě položky: klíč a seznam hodnot. Klíče tedy určují způsob, jak lze v databázi vyhledávat požadovaný obsah.
  • index struktury a klíčů. Tento index se použije pro zrychlení vyhledávání dat v pohledu.

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.

Když se na chvíli vrátíme k MySQL, dotaz (bez klauzule WHERE) vybere sloupce, které mají být vráceny, a vytvoří seznam odpovídajících řádků, který je jeho výstupem. Ukažme si to na SQL dotazu:

Když je dotaz prováděn MySQL, tak MySQL server z informací v tabulce (popř. tabulkách) vytvoří seznam záznamů (a jejich sloupců), které mají být vráceny, takto:

V CouchDB pohled vytvoří seznam záznamů z jednotlivých dokumentů. Vedlejším produktem tohoto procesu je index. Výsledkem je tedy seznam všech údajů, které byly pomocí pohledu vygenerovány z existujích dokumentů.

V MySQL se při provádění klauzule WHERE index (snad) použije k tomu, aby byly vybrány požadované záznamy:

V CouchDB je vygenerovaný pohled vlastně tabulkou, a když je nad pohledem prováděn dotaz, CouchDB použije hodnoty klíčů (a související index, byl vygenerován jako vedlejší produkt vytvoření pohledu) pro výběr požadovaných záznamů:

Tento způsob určení tabulek, nad kterými budou prováděny dotazy, umožňuje zjednodušit a zoptimalizovat získávání údajů z databáze. Ale zároveň také znamená, že je potřeba více popřemýšlet nad tím, jaké dotazy budou nad databází prováděny.

Příště nás čeká…

Teď víte, jak MySQL uchovává údaje a jak na ně lze tvořit dotazy, a jak mohou být tyto vědomosti k užitku při přechodu databáze na CouchDB. Příště začneme podle toho, co jsme se dnes dozvěděli, sestavovat dotazy, a podíváme se také na pokročilejší dotazy a na proces změny databáze.

Komentáře

Subscribe
Upozornit na
guest
42 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jan

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.

JakubS

„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.

imploder

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).

jos

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

Čelo

A když produkt úplně odstraníte?

LuKo

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

imploder

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.

lol

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, …

JakubS

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 …).

Karel Minařík

>> 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.

JakubS

Jasně, myslel jsem to spíš tak, že z MySQL lze udělat bezschémová „DB“ která zkousne jakákoliv data serializovaná v JSONu ale přišel bych tím o výhody MySQL a nezískám nic z výhod CouchDb.

Karel Minařík

Ano, pak máte 100% pravdu.

František Kučera

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).

Pavel Křivánek

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.

VM

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 ?

Čelo

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

Balvan

„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

David Grudl

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ě?

okbob

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ě.

Karel Minařík

> 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é“? :)

100% Lenin

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

okbob

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.

belzebub

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.

VM

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í.

jkb

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.

Karel Minařík

A já mám zase pocit, že veškerá argumentace odpůrců NoSQL je založena na tom, že žádnou NoSQL nikdy nepoužili/neviděli.

Důvody, proč vzniklo tolik post-relačních databází jsou _reálné_ a pádné. Některé jsou dané nutností lépe škálovat, některé nutností větší flexibility, atd.

Některé mohou být i „falešné“, tedy vznikající nedostatečnou znalostí pokročilých funkcí relačních databází. To ale neznamená, že nejsou _reálné_. Např. implementace nějakého _counteru_ (počet stažených souborů apod.) bude třeba v MongoDB i pro „lamu“ ve vašem smyslu strašně jednoduchá a brutálně výkonná.

Moc bych se tedy tím svým know-how ohledně SQL neopájel a neoháněl. Svět je pestřejší a bude to čím dál horší.

okbob

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ů.

jkb

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

okbob

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.

okbob

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.

urbino

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

František Kučera

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).

blizzboz

výborný článok… vďaka za odkaz

v6ak

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?

Michal Augustýn

Výhoda neschémovosti je opravdu sporná.

Chci přidat atribut. Ok, v dokumentové databázi nemusím udělat nic, příp. vytvořit index, ale co třeba v MSSQL? I nad tabulkou s 10M záznamy otázka max. desítek sekund. Ano, je to migrace navíc, ale nic, co by mi trhalo žíly.

A změna struktury databáze? To už člověk musí napsat migrační skripty ať se jedná o SQL nebo dokumentovou databázi.

Výhodu neschémovosti vidím v případech, kde je třeba udržovat k nějaké entitě další volitelné atributy, jejichž počet/názvy nejsou předem známy.

Neschémovost v podání sloupcově orientovaných databázích je pak úplně jiná písnička – tam se často přímo názvy sloupců používají jako cizí klíče…

v6ak

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.

Michal Augustýn

Já si to taky všechno dovedu představit se schématem :-)

Tím příkladem s volitelnými atributy jsem chtěl ukázat, že neschémovost může být přirozenější než relační přístup, tj. vytvářet další tabulku, která bude navázána na tu primární (btw. stačí vazba 1:N).
Jasně, pro mě je přidání další tabulky taky do jisté míry přirozenější, protože prakticky celou mou vývojářskou kariéru se na mě hrnuly jen relace…ale když člověk trošku otevře mysl…;-)

V tom druhém odstavci mícháš dvě nesouvisející věci – (ne)schémovost a (ne)silnou netypovost. Není problém používat ve slabě typovaném jazyce SQL et vice versa.
Btw. ještě před pár měsíci jsem byl taky zastáncem silné typovosti za každou cenu. Ale když si člověk uvědomí, že silná typovost je jen test prováděný kompilátorem
Tím chci říct to, že správnou spolupráci aplikace a databáze nemusí ověřit jen kompilátor (s využitím ORM generující silně typový obraz databáze), ale může to dělat dobře napsaný test.

v6ak

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.

Michal Augustýn

Ale k tématu, na straně 18 je uvedeno „Safe refactorings“, což je přesně to, co bez schématu nelze poskytnout.
A to je právě to, co se ti snažím rozporovat :-) Ono totiž to, že databáze je neschémová, neimplikuje to, že přístup k databázi z aplikace bude také neschémový. Není problém mít nad neschémovou databází vytvořen ve staticky typovaném jazyce krásný staticky typovaný model oné databáze!
Jsem C#ista a zároveň Cassandřista, takže vím, o čem mluvím :-)

Btw. ten dokument potvrzuje má slova, že statické typování je sice jistou formu testu, ale ve většině případů nemůže plně nahradit všechny testy.

v6ak

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.

urbino

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

MarekB.

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.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.