přejít na obsah přejít na navigaci

Linux E X P R E S, Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne

Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne

p2d2.png

Ve čtvrtek 9. 2. 2012 proběhl v Praze v prostorách MFF UK na Malostranském náměstí již pátý ročník jednodenní konference Prague PostgreSQL Developers' Day, která se, jak název napovídá, zabývá databází PostgreSQL a která je určená především vývojářům. Ohlédněte se s námi za odpoledními přednáškami.


Tuto reportáž napsali dva autoři: Tomáš Crhonek a Miroslav Hrončok. Pro rozlišení autora textu jsou v úvodu každého bloku o přednášce uvedeny jeho iniciály. Autorem fotografií je Tomáš Crhonek. LinuxEXPRES je mediálním partnerem P2D2.

Magnus Hagander: Data-driven cache invalidation

MH První odpolední přednáška nesla název, který mě příliš nelákal, nedokázal jsem si totiž představit, o čem bude Magnus Hagander vlastně mluvit. O to mileji jsem byl překvapen, když se přednáška ukázala být rozhodně jednou z nejlepších. Magnus nastínil vzorovou situaci: Založíte si blog, a přestože jste to nečekali, za chvíli má ohromnou návštěvnost – milion zobrazení stránky za minutu – a to pochopitelně server a databáze neutáhne. Tehdy přijde na řadu cache.

Magnus Hagander Magnus Hagander

Magnus z mírně předpřipravených komponent sestavil přímo na přednášce jednoduchý blog, který dokázal zobrazit všechny příspěvky pod sebou, nebo každý příspěvek zvlášť. K ukládání dat použil pochopitelně PostgreSQL a k naprogramování blogu použil django. Do patičky generovaných stránek umístil datum a čas, abychom poznali, jestli se stránka generuje, nebo načítá z cache. Magnus nejdříve předvedl variantu bez cache, kde se pochopitelně čas měnil s každým načtením stránky. V tomto režimu Magnus přidal i blogpost, který se hned zobrazil.

V dalším kroku přidal jako mezivrstvu cachovací server Varnish, který nastavil tak, aby vše (kromě administračního rozhraní) cachoval po dobu jedné hodiny. Při prvním načtení stránky se čas v patičce zafixoval a nové načítání stránky čas neměnilo, protože se stále používala verze z cache. Pak Magnus upravil titulek blogpostu, což se, dle očekávání většiny účastníků, na blogu neprojevilo, protože vše bylo stále v cache. Mohli bychom sice hodinu počkat, ale to bychom v čase vyhrazeném na přednášku nestihli.

S Magnusem Haganderem, členem PostgreSQL Core Teamu a prezidentem PostgreSQL Europe, máme připravený rozhovor.

Zde Magnus popisoval, že je nutné nějakým mechanismem zajistit, aby se při změně obsahu uložila do cache nová verze stránky. To můžete udělat v aplikaci (v tomto případě v blogu), ale nese to s sebou nevýhodu: pokud k databázi přistoupíte přímo nebo přes nějakou jinou aplikaci, změna se neprojeví. Proto se vyplatí řešit vše už na úrovni databáze. V PostgreSQL lze vytvořit trigger, který zajistí, že kdykoli dojde ke změně nějakého blogpostu nebo k přidání dalšího, patřičné stránky se v cache smažou.

Vše se dá řešit na úrovni databáze Vše se dá řešit na úrovni databáze

Pokud máte několik cache serverů, třeba v různých částech světa, můžete v triggeru pouze přidávat požadavky na smazání dat z cache do fronty, kterou realizujete pomocí PgQ. Na každém cache serveru pak budete mít komponentu, která bude požadavky na smazání obsluhovat.

Tomáš Vondra: SSD, fsync, úroveň WAL logu a jejich vliv na výkon

TC Tomáš připomenul, že vývojář by si měl umět klást správné otázky a v úvodu přednášky několik z nich položil. Vývojář by měl mít základní povědomost o způsobu uložení dat a v Postgresu bychom si měli klást otázky jako například tyto: Která data (datové soubory, indexy, WAL) umístit na samostatný disk a jaký výkon to přinese? Pokud máme k disposici SSD, na která data jej použít? Jaká je nejrychlejší (a stále bezpečná) metoda synchronizace?

Po těchto otázkách následovala technická data o SSD a HDD a představení jednotky výkon/cena/GB (klasický poměr výkon/cena vztažený na velikost média). HDD jsou velké a relativně pomalé, ale zase velmi levné, SSD jsou malé a drahé, ale velmi rychlé, alespoň v některých situacích, v jiných jsou jen o málo rychlejší než klasické rotující disky, což jejich cenu neospravedlní.

Po tomto úvodu o způsobu ukládání dat, jednotkách použitých v testu a představení hardwaru následoval popis dvou základních testů, a to OLTP (TPC-B, pgbench, „malé pseudonáhodné dotazy“) a DWH (TPC-H, „dotazy na veliký objem dat“). A situace se rázem zkomplikovala. Alespoň jeden výsledek mohu prozradit: v testu OLTP excelovaly SSD, zatímco v DWD naopak HDD. A ještě je důležité, zda jsou data a indexy umístěny na samostatných discích a jakého typu: čtyři kombinace dvou disků, dva testy, mnoho různých výsledků, a to ještě z pohledu čistého výkonu a potom z pohledu ceny za tento výkon.

Srovnání různých uložení dat a WALu na SSD a HDD Srovnání různých uložení dat a WALu na SSD a HDD

Dalším testem, opět v mnoha různých kombinacích, byl test výkonu databáze při umístění dat a WAL na dvě různá zařízení, opět dvojího typu a opět s přihlédnutím na jejich cenu. Posledním testem byla metoda synchronizace (fsync) WAL logu a jeho vliv na rychlost databáze na různých zařízeních.

Hodnotná přednáška, pro mě jakožto technika, přinesla velmi mnoho cenných výsledků a chtěl bych za to Tomášovi poděkovat. Mohu vám jen doporučit projít si Tomášovy slajdy z přednášky, další testy má na svém webu, vaší pozornosti doporučuji test výkonu Postgresu na mnoha různých systémech souborů v různých konfiguracích.

Tomáš Pospíšil: Indexování XML dat v PostgreSQL (GSoC 2011)

MH Tomáš Pospíšil v rámci Google Summer of Code doprogramoval do PostgreSQL několik věcí, které napomohly k uložení XML dokumentů do databáze. Již předtím to bylo sice možné, ale chyběly některé zásadní funkce, především indexace a validace.

XML v PostgreSQL XML v PostgreSQL

Tomáš posluchače nejdříve seznámil se situací v PostgreSQL předtím, než potřebnou funkcionalitu doprogramoval, poté se pochlubil nějakými statistikami, kterým jsem ale bohužel opravdu nerozuměl :(

Nakonec Tomáš vysvětlil projekt Google Summer of Code. Pokud jej neznáte, vězte, že je to v zásadě jednoduché. Student pracuje přes léto na konkrétním vylepšení nějakého open-source projektu a za to dostane zaplaceno od Googlu. Navíc má z daného projektu k dispozici mentora. Není to však příliš snadné, projekty, konkrétní úkoly a studenti, to vše prochází přísnou kontrolou a zájemců je mnoho.

Pavel Stěhule: Column-stores (MonetDB, LucidDB...)

TC Zatímco Tomáš ve své přednášce hovořil o ukládání dat v podobě datových souborů, indexů a WAL, Pavel šel ještě „o patro níže“. Ukázal, jakým způsobem většina současných relačních databází ukládá řádky do stránek, jaké to má výhody a nevýhody pro určitá nasazení. Pokud aplikace potřebuje vytvářet velmi široké tabulky (typické pro OLAP) a poté zpracovávat pouze data z několika málo sloupců, databázový server musí z disku načíst celou stránku, zpracovat celé řádky, ze kterých potřebuje pouze malé procento záznamů. Většina dat se tak pro tento typ zpracování čte zbytečně. Proto byl vymyšlen způsob ukládání po sloupcích, databáze tak může velice efektivně sekvenčně číst tabulku po vybraných sloupcích, což je velmi rychlé.

V databázovém světě jako takovém se od roku 2000 děje hodně věcí, částí přednášky bylo velmi poučné zamyšlení nad úspěchem NoSQL databází a to, který relační databázový produkt za to „může“. Následoval krátký úvod do různých tříd databázových systémů. Hodně užitečný byl také historický exkurz do sedmdesátých let (minulého století) a připomenutí původu dnešních relačních databází (parser, optimalizátor plánu, pipeline exekutor nad stránkami s řádky).

Návštěvníci konference Návštěvníci konference

Na přednášce se diváci dozvěděli o dvou produktech z řady sloupcových databází: MonetDB a LucidDB (obě open-source, i když s Monetem je to nahnuté), a mimo jiné také o tom, že Pavel nemá rád Javu, což část publika ocenila potleskem. Oba produkty jsou SQL databáze, podporující ACID, a jsou optimalizované pro OLAP a star schéma a pro rychlé nahrání většího množství dat (s nevýhodou velmi pomalých změn jednotlivých řádků, tyto produkty by se měly používat pro analytické dotazy, kde se z tabulek pouze čte).

Hodně zajímavé a pro příznivce PostgreSQL (což je stejně jako MySQL databáze s klasickými stránkami obsahujícími řádky) jistě velmi potěšitelné byly testy výkonu LucidDB, MonetDB, PostgreSQL a MySQL, kde první dvě jsou optimalizované na tento typ úloh (OLAP), zatímco druhé dvě nikoliv. Sloupcové databáze Monet a Lucid nepřekvapivě vyhrály (14 a 23 sekund), následovány Postgresem (26 sekund) a někde vzadu MySQL (4 minuty). Asi nejen já jsem se v této chvíli zamyslel nad nutností vývoje dalších produktů, když už tu je jeden, který tyto úlohy (navzdory klasické architektuře) dobře zvládá. Navíc a bohužel, Monet se uzavřel do komerčního světa.

Výsledek testu Výsledek testu

Lightning talks

MH Na úplný konec programu byly zařazeny takzvané lightning talks. Jedná se o krátké prezentace, které může přednést libovolný účastník konference. Ve čtvrtečním případě měly prezentace maximálně sedm minut. Osobně jsem byl na tuto část programu velmi zvědavý, protože minulý ročník byla na konec programu zařazena odlehčující přednáška SQL Puzzlers, která mě hodně pobavila. Lightning talks mě ale jako celek zklamaly. Ne že by jednotliví lidé nebo jejich přednášky nestáli za to, ale celá akce měla příliš malou účast a kromě lidí, kteří již prezentovali na konferenci něco jiného, promluvil pouze jeden člověk navíc.

Jako první vystoupil Magnus Hagander, který mluvil o tom, že je strašně jednoduché hashovat hesla v databázi, a přesto to skoro nikdo nedělá. Nejdříve ukázal nějaké titulky z novin, aby své tvrzení dokázal (např. o deseti tisících uniklých heslech z Hotmailu). Magnus ve svých sedmi minutách také prakticky předvedl, jak vše dělat v PostgreSQL.

Následoval Vašek Frolík, který předvedl PostgreSQL plugin pro Eclipse. Dříve existoval takový plugin pro Oracle, ale nyní jej v Ostravě uzpůsobili i pro PostgreSQL.

PostgreSQL plugin pro Eclipse PostgreSQL plugin pro Eclipse

Předposlední krátkou řeč měl Simon Riggs, který popisoval validaci stránek na základě kontrolního součtu. V některé z příštích verzí Postgresu (pravděpodobně 9.2) bude možné mít v hlavičce stránky místo čísla verze kontrolní součet. Půjde však určitě o volitelnou variantu.

Lightning talks zakončil Tomáš Vondra, který předvedl, jak použít český fulltext a sdílené slovníky. Problém je v tom, že algoritmické převedení slov na první pády a infinitivy nefunguje např. u češtiny a slovenštiny nebo dalších slovanských jazyků, takže se musí použít slovník. Slovník se ale načítá do paměti znovu a znovu při každém připojení k databázi, což není dobré. Při dvaceti pěti připojeních a dvou slovnících (českém a ceskem bez hacku a carek) se dostanete na 500 MB v paměti, což může znamenat například na VPS dost veliký problém. Proto Tomáš vytvořil komponentu shared_ispell, která umožňuje používat společný slovník pro všechna spojení.

Na webu konference můžete najít slajdy z jednotlivých přednášek.

Nahoru

(Jako ve škole)
Průměr: 1.00 | Hodnotilo: 1
 

Příspěvky

Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
rr5 21. 02. 2012, 08:43:11
Odpovědět  Odkaz 
Dobry den
Ten link na Tomášovy slajdy z přednášky - je nefunckny
Tomáš Crhonek Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Tomáš Crhonek 21. 02. 2012, 09:40:22
Odpovědět  Odkaz 
Všechny přednášky, včetně odkazů na slajdy, můžete nalézt také zde (http://www.p2d2.cz/rocnik-2012/prednasky).

Funkční odkaz na přednášku TV: http://www.p2d2.cz/files/vondra-ssd-hdd.pdf

Díky za upozornění, zadám opravu článku.
Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Tomáš Vondra 21. 02. 2012, 19:07:47
Odpovědět  Odkaz 
Chyba je částečně na naší straně - PDF odkazy byly původně umístěny na provizorní doméně, po migraci na správné místo to přestalo fungovat.
Miroslav Hrončok Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Miro Hrončok 21. 02. 2012, 20:58:34
Odpovědět  Odkaz 
Opraveno, díky.
Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
honza 22. 02. 2012, 14:25:24
Odpovědět  Odkaz 
tedy predne, dik za reportaz z konfery, kdyz uz se clovek nemuze ucastnit osobne.
Presto nechci zamlcovat jakysi takovy divny dojem, jakesi prazdnoty, povrchnosti. nema to asi co docineni s pgsql, je to v cele spolecnosti.
Mam takovy pocit, ze se nejaka eliterni skupina lidi zabyva s databazi pro nejake koncerny, ktere budou analyzovat terabyte dat. Jiste, i pro statni organy je to bezva, ze bude mozno i za pomoci open-source analyzovat data obcanu, zjistovat kde byli, co nakupuji, jak casto soulozi a jakou preferuji barvu.
Co my chybi je neco praktickeho pro vetsinu lidi - tedy pro nas programatory - neco variabilniho, maleho, embedded - ale na to reknou vyvojari - my ted souperime s Oracle.
Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
rr5 22. 02. 2012, 16:28:53
Odpovědět  Odkaz 
No a co konkretne sa vam na postgre zda nepraktickeho k vyvoju, praveze mne sa paci preto ze je kompaktna, rychla, spolahliva a lahko implementovatelna.
Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Tomáš Vondra 22. 02. 2012, 18:34:58
Odpovědět  Odkaz 
Eh? Na prázdnotu je dobré pivo, svět vám hned bude připadat veselejší ... a nebo něco tvrdšího, já aplikuji Cuba Libre.

Jinak ale moc nevím co vám odpovědět - těžko vyčítat PostgreSQL že se nejedná o embedded databázi když prostě jako embedded nebyla navržena a není (a ani nebude) na tento typ využití cílena. Pokud chcete databázi pro embedded použití sáhnětě po sqlite, hsql, možná i po Firebirdu a podobně.

Co se týká údajného zneužívání databází k analýze informací - to je jako vyčítat autům že s nimi gangsteři občas vykrádají banky. Databáze za to prostě nemůžou.
Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
honza 22. 02. 2012, 20:31:25
Odpovědět  Odkaz 
viz napr.

http://news.alaska-software.com/readmessage?id=%3C783fef87$68547618$4332@news.alaska-software.com%3E&group=public.announcements

tohle je priklad takove te zoufale snahy jak vyuzit stavajici stav techniky (DB) a mnozstvi jiz overenych aplikaci.

Podobne (rekl bych zoufale volani) viz.

http://archives.postgresql.org/pgsql-novice/2002-06/msg00122.php

Nerikam ze to je jen u pgsql, podobne otazky je mozno najit i v mysql forech, ale to je ta prazdnota kterou citim a pochybuji ze mi pivo pomuze.
Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Pavel Stěhule 22. 02. 2012, 18:46:42
Odpovědět  Odkaz 
PostgreSQL je jenom software - svět naplnit nedokáže - ale jinak jestli něco není cílem - tak je to napsat druhý Oracle. Na úplně malé věci je to SQLite, na něco většího Firebird, a pak PostgreSQL. PostgreSQL se nainstaluje a nakonfiguruje během 5 minut - je snaha, aby v něm bylo minimum chyb a aby se dobře používal, aby se dal bezpečně používat aniž by člověk musel být expert - a např. 9.2 přinese řadu funkcí, která zjednoduší replikace, vývoj nad Pg, zálohování. Jinak ovšem PostgreSQL asi nikdy nebude embedded - je tu SQLite a Firebird - a není cílem je nahradit.
Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
honza 22. 02. 2012, 20:18:22
Odpovědět  Odkaz 
na strance flexibee je navod pro instalaci. Pisi tam:

....Při instalaci FlexiBee na CentOS či RedHat Enterprise Linux narazíte na problém s nedostupností balíčků postgresql-server-8.3 a jre (Java). Stáhněte si je ze stránek postgresql.org ...

A pote jsou tam na dalsich strankach jeste uvedeny odkazy, co je treba delat, kdyz se aplikace bude provozovat s vice jak 5 uzivateli ...

...Tento článek popisuje naše mnoholeté zkušenosti s provozem PostgreSQL pod velkou zátěží a s mnoha uživateli. Pokud chcete mít jistotu, objednejte si od nás instalaci PostgreSQL. ...

Jinak sqlite je 'jednouzivatelska' databaze , mam to vyzkousene. Firebird vidim jako rovnocenou db pro mensi a stredni aplikace. To uz mohu vzot rovnou postgres. Ta je prece jen mnohem vice v nasazeni.
Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
rr5 22. 02. 2012, 20:53:35
Odpovědět  Odkaz 
Prepacte ale ja, a mozno aj ini, stale nechapem o com hovorite.
V com je teda problem?
Mame postgre v prevadzke a zatial sme spokojni...
Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
honza 23. 02. 2012, 13:06:51
Odpovědět  Odkaz 
postgres je velmi dobra databaze. Vsech vyvojaru si vazim a preji jim i komunite vsechno nejlepsi. Nemam ani zadne stiznosti ohledne nejakych konkretnich chyb. Jde spis o jakysi 'spleen', ktery jsem se snazil v jednotlivych prispevcich zde nadhodit.
Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Pavel Stehule 22. 02. 2012, 22:08:40
Odpovědět  Odkaz 
Možná postrádáte něco, co by bylo moderní variací na FoxPro - tedy ISAM 4G databázi, což opravdu není - a asi nebude - jedině, že by Microsoft ještě před uzavřením uvolnil FoxPro a to se asi čekat nedá.

Jinak nemůžete flexibee vyčítat, že na svých stránkách upozorňuje zákazníky, že mohou mít s pg problém - PostgreSQL sice má instaluje poměrně jednoduše, ale není to embedded databáze - a flexibee mohou instalovat uživatelé, kteří netuší, co to je konfigurační soubor. Takže nějaké potenciálně pomocná ruka může přijít vhod. Když chcete jednoduchou instalaci, a chcete aplikaci provozovat pod win, tak Firebird je vhodnější volba. Kdyby se z PostgreSQL měl stát Firebird, tak by to znamenalo několik let přepisování spodku PostgreSQL, což by byla ztráta času, když je tu Firebird.
Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Pavel Stehule 22. 02. 2012, 22:37:28
Odpovědět  Odkaz 
Ještě se doplním. Jednak se omlouvám za překlepy v předchozím příspěvku. Druhak - v PostgreSQL lze poměrně snadno psát ISAM aplikace - Postgres podporuje kurzory (dokonce i scrollable kurzory).
Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
honza 23. 02. 2012, 14:26:13
Odpovědět  Odkaz 
ano, nejake foxpro free by bylo prima. Temi odkazy jsem chtel jen upozornit na to, ze to neni jen nejaky nesmysl z me hlavy, ty tuzby maji i jini. Ono by to chtelo vlastne takovou prednasku na P2D2 konferneci s provokativnim nazvem - 'proc nemohu s postgresql psat ISAM aplikace'. Jenze ja mam pocit, ze by to nikoho vubec nezajimalo - a ze by tomu take nikdo vubec nerozumnel.

A to je vlatne ten muj problem, proc jsem sem postnul ten muj 'vykrik do tmy'. Ten NoSQL hype by byl vlastne dobry ukazatel, ze se neco deje. Ale na programu konfery jsou 'main stream' temata - OLAP, lepsi replikace, optimalizace cache a jine. To je OK a ja nekritizuji ze se stavajici stav postupne vylepsuje. Co mi chybi je to kriticke ohlednuti zpet (priznavam, ze vy jste snad jediny kdo to obcas dela), co ta leta prinesla. Ale k tomu kritickemu ohlednuti by museli byt v plenu lide , kteri si skutecne dovedou predstavit, co vsechno takova databaze musi udelat, nez vybavi jeden pitomy select. To se studuje, kdyz se to dela opravdu, 2 semestry a neodbyde se to nekolika prednaskami, tak jak to maji studenti informatiky dnes. Samozrejme, ze takovi lide jsou nejdrive nadseni z toho, co takova datbaze vlastne vsechno dela a umi, ale ve chvili, kdy se polozi otazka, zda je to vsechno nutne a PROC je to nutne by se mozna nekteri zamysleli. A zjistili by, ze na to PROC je vlastne jednoducha odpoved - protoze jsme pred 30 lety rozhodli, ze se nebudeme ptat kde data jsou a jak se k nim dostaneme, ale jenom rekneme co chceme. A mnozi z tech , kteri takovy pristup povazuji za 'samozrejmy' by se mohli ptat, stoji tech 80% celeho kodu v tech databazich za to a jak by se to dalo delat lepe, jinak. Vzdy jsem si myslel, ze to by melo provazet kazdou konferenci, tak jak to Max Plank od vysokoslokaku a inteligence vzdy pozadoval - neustale se ptat - plati dnes jesto to vsechno, co platilo vcera.

Dovedu si predstavit co to obnasi vubec takovou konferenci usporadat a proto bych prosil o to, aby muj prispevek nebyl skutecne chapan jako kritika tehoz. A zaroven prosim omluvit tu pateticnost meho prispevku, nekdy se clovek dostane halt do raze.
Re: Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Pavel Stehule 23. 02. 2012, 16:01:46
Odpovědět  Odkaz 
Možná by to byla zajímavá polemika - ale jak jste uvedl, většina z přítomných by netušila o čem je řeč. Neviděl bych to ovšem pesimisticky - SQL vyhrálo - primárně asi kvůli tomu, že jej prosazovalo IBM, a že Oracle dokázal na něm vydělat těžké peníze, ale také kvůli tomu, že bylo poměrně dobře vymyšlené. A spíš než 80% tvoří implementace SQL (parser, optimalizer) cca 30-40% - pořád většina kódu se věnuje tomu, co by každá multiuživatelská relační ACID databáze dělala - správě cache, správě transakcí, zabezpečení přístupu, správě metadat, zajištění recovery, zajištění zámků. SQL databáze byly příliš náročné na PC v 80 a 90 letech - což byl asi důvod popularity MyISAM 4G db. Dnes je SQL hrdlem pouze v situacích, že máte db kompletně v paměti - jinak je SQL zadarmo - procesory jsou tak rychlé, že by ISAM databáze nebyla rychlejší. To, že SQL databáze jsou občas monstra není způsobeno SQLkem, ale tím, že většina db má 30 letý kód, který se různě upravuje, dopisuje, přepisuje. Z gruntu se to nikomu nechce přepisovat, bo z toho kouká jen dost práce a málo peněz. A s novým hw se začínají rýsovat nové směry - obloukem zpět k síťovým db (objektové databáze), případně vědecké databáze sloupcové nebo arraydb. Podobně jako teď si pár pamětníků vzpomene na FoxPro z 95, tak za 15 let si pár pamětníků vzpomene na SQL. Možná by to stálo za nějaký seminář :)
Tomáš Crhonek Re: Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Tomáš Crhonek 24. 02. 2012, 21:29:43
Odpovědět  Odkaz 
To se studuje, kdyz se to dela opravdu, 2 semestry a neodbyde se to nekolika prednaskami, tak jak to maji studenti informatiky dnes. Samozrejme, ze takovi lide jsou nejdrive nadseni z toho, co takova datbaze vlastne vsechno dela a umi, ale ve chvili, kdy se polozi otazka, zda je to vsechno nutne a PROC je to nutne by se mozna nekteri zamysleli.

Promiňte, ale o kom hovoříte? V mém studiu matematické informatiky jsme poměrně detailně probírali všechny algoritmy a uložení dat a vím, že i na jiných informatikách mají jako semestrální práce napsat (ještě k tomu v C) uložení dat do souboru a jeho indexaci pro určité operace. A AŽ
Tomáš Crhonek Re: Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Tomáš Crhonek 24. 02. 2012, 21:34:25
Odpovědět  Odkaz 
>> To se studuje, kdyz se to dela opravdu, 2 semestry a neodbyde se to
nekolika prednaskami, tak jak to maji studenti informatiky dnes. Samozrejme, ze takovi lide jsou nejdrive nadseni z toho, co takova databaze vlastne vsechno dela a umi, ale ve chvili, kdy se polozi otazka, zda je to vsechno nutne a PROC je to nutne by se mozna nekteri zamysleli.
Tomáš Crhonek Re: Re: Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Tomáš Crhonek 24. 02. 2012, 21:41:52
Odpovědět  Odkaz 
Aha, ty francouzké uvozovky nebyl ten nejlepší nápad. :-(

Chtěl jsem jen napsat, že spousta studentů informatiky píše jako semestrálky ukládání dat a jejich indexaci pro určité operace, takže ješte než je pustí k SQL, tak mají poměrně detailní znalost, kolik práce za tím získáním stojí. A věřím, že spousta z nich umí odpovědět na vámi položené otázky.

Navíc, pokud je pro daný projekt důležité "kde data jsou a jak se k nim dostat", tak ten projekt nepoužije SQL databázi, ale nejakou jinou, případně vlastní (což je teda často velmi špatné rozhodnutí).
Re: Re: Re: Re: Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
honza 25. 02. 2012, 21:23:19
Odpovědět  Odkaz 
tedy v zadnem pripade nemel muj prispevek vyvolat dojem, ze dnesni informatici nic neumi. Kdyz, tak bych mel snad vyhrady k obsahu studia, protoze vim, ze v zahranici je to trochu jinak (mam ve vzdalenem pribuzenstvu studenta, ktery studoval krome jineho i u prof Ticheho - (W.Tichy - RCS) - v Karlsruhe a tam se zabyvali napr. jeden semestr jen paralelnim programovanim a transakcnim zpracovanim v teto oblasti).

To co uvadite jako priklad je zhruba 1/5 te problematiky, kterou mam na mysli. Momentalne vidim napr. takovou moznost studia v Magdeburgu u prof. Saakeho, kde je mozno si napr. zapsat predmet - 'konstrukce storage engines v databazich'. Jak vidite, jde mi o ta streva a problematiku navrhu databazoveho stroje.

Abych byl trochu konkretni. Jsou zhruba dve moznosti jak ten design te databaze pojmout. Budto to udelat jako Widenius s MySQL, ktery zopakoval tu cestu Informixu a jejich SE-4GL databaze, kdy se vezme nejaky isam a udela se nadstavba s parserem. A nebo se to udela jako Stonebraker s pgsql, nebo Keith Bostic s BerkeleyDB, kdy je cely design orientovan na to, aby 'parser, optimizer' (u pgsql), ulozeni dat v pameti , zamky, transakce , backup a recovery tvorily jeden celek. Velmi, ale velmi zhruba se da rict, ze v prvnim pripade je hlavnim objektem 'record', v druhem pripade 'page'. Ten pripad BerkeleyDB je prave tim zajimavy, ze se jedna vlastne o NONSQL-key/value DB a presto nelze zamknout record, protoze 'fyzikalne' vlastne nic takoveho neexistuje.

Presto existuji databaze, jejichz design odpovida postgresql/oracle/db2/.. a dokazi pres nejake API navigovat pres recordy. (SolidDB, drivejsi SAPDB ..). A nebo databaze, ktere vychazeji spis z isamu a presto dokazi spravovat terabytes dat se vsemi atributy velkych databazi (faircom ACE).

O neco takoveho mi slo v mem prisevku.
Re: Re: Re: Reportáž z Prague PostgreSQL Developers' Day 2012: Odpoledne
Tomáš Vondra 22. 02. 2012, 23:06:00
Odpovědět  Odkaz 
Především mi není jasné jak PostgreSQL může za to že v CentOSu jsou nedostupné instalační balíčky - to si řídí správci distribuce, PostgreSQL za to nemůže. Ostatně 8.3 je několik let stará verze, takže soudit podle toho aktuální stav je poněkud zvláštní.

To samé platí o FlexiBee - je to sice výborné účetnictví ale to že je napsané tak že může vyžadovat 30 spojení na klienta (!!) nebo 512 zámků na transakci je poněkud ... zvláštní. Ale opět nechápu jak z toho vyplývá chyba na straně PostgreSQL. Ono by se to totiž stejně chovalo i s jinými databázemi.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Top články z OpenOffice.cz