Hlavní navigace

Dubnový termín školení PostgreSQL

Sdílet

Petr Krčmář 25. 2. 2008

Pokud jste se nedostali na plné březnové školení PostgreSQL, máme pro vás dobrou zprávu – další kurz týkající se tohoto známého databázového serveru se koná ve čtvrtek 24. dubna. Lektorem je opět známý odborník Pavel Stěhule. Školení pořádá Akademie Root.cz.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 25. 2. 2008 22:49

    LENIN POWER! (neregistrovaný)
    Jaka je cilova skupina? Tezko bude nejaky podnik pouzivat PGSQL misto Oracle, vzdyt na to nejsou zadne aplikace krome tech co si sami napisou. To snad i v nasich koncinach nejsou podniky takovy socky aby neutahli tu Oracle licenci.
  • 26. 2. 2008 7:38

    Pavel Stěhule
    Ted jsou to prevazne lidi z web studii, pripadne provozovatele web shopu - obcas lidi z strojirenskych podniku, ktere maji vlastni vyvojove tymy. Nejde o to usetrit za licence. Oracle je moloch, navic s dost drahym supportem (porovnejte naklady na skoleni pg a Oraclu). PostgreSQL ma support zdarma a jako databaze pro dane ucely postacuje.
  • 26. 2. 2008 19:27

    jurasek (neregistrovaný)
    mel bych dotaz. jsou soucasti skoleni nejake materialy /dokumentace/ ? jedina ceska kniha http://knihy.cpress.cz/knihy/akce-a-balicky/pocitacova-literatura/postgresql-prakticky-pruvodce/ je uz dost stara. zajimaly by me spise otazky kolem administrace DB /zalohovani, nastaveni pristupu, rozmisteni souboru, konfigurace, ladeni vykonu/. v jakem rozsahu je tato oblast v tomto skoleni zastoupena ?

    s pozdravem

    jurasek
  • 27. 2. 2008 11:26

    Pavel Stěhule
    Podklady pro vsechna skoleni, ktere vedu, jsou volne ke stazeni ze stranky http://www.pgsql.cz/index.php/Jednodenn%C3%AD_%C5%A1kolen%C3%AD_PostgreSQL . Temata, ktera Vas zajimaji jsou ve vseobecnem skoleni probirana take - nicmene dukladneji se na administraci zameruje skoleni "PostgreSQL efektivně, administrace".
  • 26. 2. 2008 19:51

    Rejpal (neregistrovaný)
    Oficiální cena licence Oracle EE je v přepočtu z amerických cen asi 650000 kč na procesor, a totéž stojí (dodatečně) maintenance po dobu pěti let. Do osmi jader (na Intelu a AMD) člověku "stačí" Standard Edition za ~230000 Kč za procesor, takže za čtyři Opterony na desce asi tak ten milión. :-) U osmi Opteronů už je to milionů skoro šest. Takže asi tak. :-)

    Já nevím, mně je při pohledu do peněženky fakt sympatičtější Firebird. ;-) Malé, hezké, fungující věci ve mně vzbuzovaly mnohem více sympatií...asi jako jádro vodíku proti jádru uranu. :-D
  • 27. 2. 2008 3:05

    LENIN POWER! (neregistrovaný)
    Presne tak 230k kc za Oracle SE na 1 procesor (na intelu 2 jadra) to nejsou pro podnik zadne podstatne penize. Podelte si to poctem let jak dlouho planujete Oracle pouzivat a poctem uzivatelu co se k nemu budou pripojovat. Pokud by mel podnik malo useru, vzdycky se da koupit licence per user.

    I kdyz si vezmeme maly podnik o rekneme 100 zamestnancich a dame si do souvislosti cenu Oraclu a napriklad mzdove mesicni naklady, tak uvidite ze cena Oraclu je pro podnik kapka v mori, kterou vubec nema cenu resit.

    Krom toho pro pouziti na web shop staci ten free oracle limitovany na 4GB dat. Podle mych zkusenosti se ten free oracle pouziva dost.
  • 27. 2. 2008 4:33

    Rejpal (neregistrovaný)

    A proč bych na web shop měl použít zrovna free Oracle, když můžu použít *skutečně free* Firebird, který je stokrát menší než free Oracle, a současně zvládne stokrát větší databázi? ;-) A navíc je takřka bezúdržbový. Nevím, co si představujete pod pojmem "web shop", ale dokud to není eBay, má většina serverů "jistou rezervu". :o)

    To, že *Vy* trpíte megalomanstvím a dal byste Oracle do každé pračky, ještě neznamená, že začnou všichni honem migrovat. SMB nám nic neříká? Klidně si běžte si masturbovat nad i5/OS, DB/2 a Oracle, ale pořád tu bude prostor pro malé databáze, nebo ještě lépe, pro databáze, co dokážou downscalovat. Firebird má rozpětí od pár megabajtů čisté instalace do několika terabajtů dat (nějaká šílená firma v Brazílii) a od jednoho uživatele zhruba do tisícovky na jednom stroji. PostgreSQL na tom nebude o moc hůř (přestože má - pro některé aplikace - tu nevýhodu, že se nedá použít jako jediná dynamická knihovna).

    Když budu chtít mít na pracovním stroji (včetně notebooku) po ruce databázový engine, který nebude třeba administrovat, nebude překážet v paměti ani spuštěný a neměl by se moc roztahovat po disku, co mi doporučíte? Oracle? Nebo snad Microsoft Access? Smiřte se s tím, že různí lidé mají různé potřeby. My Vám nic nevnucujeme, to jen Vy tu prudíte s tím, že jsme málo světoví a máme používat tohle a tamto. Založte si radši http://www.sysop.cz.

  • 28. 2. 2008 1:09

    LENIN POWER! (neregistrovaný)
    Proc by mel pouzit free Oracle misto free Firebirdu, to je jasne. Kazdy podnik si stejne jednou Oracle ci DB2 poridi ponevadz to podnikove aplikace vyzaduji. Ty nejsou proste nejsou psane pro databaze MySQL, Firebird a spol. Ze stejneho duvodu se nepouziva Linux na desktopech.

    Pokud si Oracle nikdy nekoupite, nebudete mit aplikace a budete si je muset nakodovat inhouse. To je dost draha zalezitost. Nejlevnejsi je si aplikaci koupit jiz hotovou.

    V pripade ze ano, tak pak muset administrovat 2 databazove platformy misto jedne, coz se prodrazi a zbytecne bude zeslozitovat infrastrukturu. Aplikaci lze sice prepsat z databaze X na databazi Y, ale to je pomerne narocne taky. Porad nevidim tu usporu, kterou melo pouziti opensource DB prinest. Kratkodobe jste usetrili za licenci, dlouhodobe ale prodelavate. Zadarmo neznamena nejlevneji.

    Proto doporucuji si vybrat Oracle nebo DB2 a zacat psat aplikace pro free verzi a pak az datove potreby vzrostou, tak si zakoupit plnou licenci. Oracle XE umi 4GB uzivatelskych dat, DB2 EXC dokonce zadny takovy limit nema. Nebudete muset prepisovat aplikaci a pretrenovavat lidi. DB2 ma ovsem tu vyhodu ze poradne bezi i na i5/OS, ktery ma na iseries navic velmi vhodny hw pro provozovani databazi.

    Je tu taky otazka dostupnosti lidi co se zminenou db umi pracovat. Snadneji sezenete cloveka pro Oracle nez pro PostgreSQL ci Firebird. Kdo dela neco pro PGSQL v cechach krome Sunu? Pro Firebird dela taky jen jedna firma. Dostupnost kvalifikovanych lidi je tedy znacne mensi.

    Kdyz chcete miniaturni db engine ktery nebude zabirat moc mista v pameti, tak pouzijte DB2. Windows instalace pouziva defaultne 1MB buffer cache a priblizne 8MB pameti pro db heap. (sort buffery, log buffery, etc). Oracle potrebuje tak 1GB RAM, ale pri soucasnych cenach pameti to nema cenu vubec resit. Vybirat databazi pro podnik podle toho co jede na notebooku s 256MB RAM je neprofesionalni.

    Pouzivat databazi jako dynamickou knihovnu - Oracle i DB2 to ve starych verzich umely, ale jiz se tato funkcionalita nepodporuje. Na i5/OS tam databaze jako dynamicka knihovna (sqllib) je, ale tenhle OS ma jinou architekturu.

    Prave ze prostor pro male databaze v profi sfere proste neni. Male databaze jsou proste pro nekomercni sferu. Ja taky semtam pouzivam MySQL ale jen proto, ze nektere PHP aplikace co jsme koupili to vyzaduji. Kdyby umeli DB2, tak aplikace presunu na mainframe abych usetril. MySQL na i5/OS neumi cesky.

    Proto jsem se ptal jaka je cilova skupina, pokud doporucujete podnikum PGSQL misto Oraclu, delate jim spatnou sluzbu.

    To ze ma nekdo ve firebirdu/pgsql velke databaze jeste neznamena ze tyto produkty umi efektivne zpracovavat velke databaze. Sam jsem testoval DB2 vs PGSQL na Vistach se 50GB databazi a pri stejnem nastaveni byla DB2 vyrazne rychlejsi 3-8x pri vyhodnocovani dlouhotrvajicich BI dotazu. Mluvim o dotazech co bezi radove minuty a pracuji s velkymi result sety.

    Krome toho kdyz jsme u toho postgresu udelejte si nad velkou databazi VACUUM FULL a stopnete si cas, dela se to aby se databaze smrskla kdyz se zejmena u pgsql natahne castymi update/delete na mimoradne velkou velikost a to zejmena u indexu. DB2 narozdil od PGSQL umi online reorganizaci, ktera dokonce ani nezamyka data. Nad 50GB databazi s tabulkou 40GB vam bude vacuum full bezet desitky hodin. Import export je v pgsql pomaly taky, radove 4x pomalejsi nez v DB2 kdyz DB2 bude poctive delat inserty do tabulek a nepouzije direct load. Kazdy den nahravame 20+ mega zaznamu pomoci direct loadu a zvlada se to pod 30 sekund pravda musi se grabnout exclusive lock na tablespace, pokud se pouzije insert tak stejna operace trva priblizne 12 minut, u PGSQL trva tesne pod hodinu.
  • 28. 2. 2008 7:01

    Pavel Stěhule

    To ze ma nekdo ve firebirdu/pgsql velke databaze jeste neznamena ze tyto produkty umi efektivne zpracovavat velke databaze. Sam jsem testoval DB2 vs PGSQL na Vistach se 50GB databazi a pri stejnem nastaveni byla DB2 vyrazne rychlejsi 3-8x pri vyhodnocovani dlouhotrvajicich BI dotazu. Mluvim o dotazech co bezi radove minuty a pracuji s velkymi result sety. Krome toho kdyz jsme u toho postgresu udelejte si nad velkou databazi VACUUM FULL a stopnete si cas, dela se to aby se databaze smrskla kdyz se zejmena u pgsql natahne castymi update/delete na mimoradne velkou velikost a to zejmena u indexu. DB2 narozdil od PGSQL umi online reorganizaci, ktera dokonce ani nezamyka data. Nad 50GB databazi s tabulkou 40GB vam bude vacuum full bezet desitky hodin. Import export je v pgsql pomaly taky, radove 4x pomalejsi nez v DB2 kdyz DB2 bude poctive delat inserty do tabulek a nepouzije direct load. Kazdy den nahravame 20+ mega zaznamu pomoci direct loadu a zvlada se to pod 30 sekund pravda musi se grabnout exclusive lock na tablespace, pokud se pouzije insert tak stejna operace trva priblizne 12 minut, u PGSQL trva tesne pod hodinu.

    DB2 nepoužívá multigenerační architekturu - tudíž lze jen těžko porovnávat pouze dotazy. Je to stejné, jako porovnávat výkon MyISAM a InnoDB MySQL. Navíc dotaz, který je optimání pro DB2 nemusí být optimální pro PostgreSQL. Měl jste akualizované statistiky, provedl jste vacuum, měl jste rozumně nakonfigurovanou databázi? Posoudil jste EXPLAIN? Nevím kolik toho víte o PostgreSQL - doporučil bych Vám své školení, kde byste se dozvěděl, že FULL VACUUM nemusíte spouštět kždý den .. na to stačí lehké VACUUM, které nezamyká. Nevím jak jste přišel k desítkám hodin .. 50G tabulka se co tak mám zkušenost vacuuje cca 2-3 hodiny, a opakuji v novějších verzích FULL VACUUM nemusíte používat. 4x pomalejší import - to je dost možné - víte, že existuje příkaz COPY, který je cca 10x rychlejší než import pomocí INSERTů?

    Pokud už provozujete relativně slušně velké databáze, tak už o databázi musíte mít určité znalosti. Mohu Vám nabídnout svá školení: http://www.pgsql.cz/index.php/Jednodenn%C3%AD_%C5%A1kolen%C3%AD_PostgreSQL , případně školení na rootu, případně audit Vašeho db řešení: http://www.pgsql.cz/index.php/Slu%C5%BEby

  • 4. 3. 2008 0:46

    LENIN POWER! (neregistrovaný)
    pouzivali jsme COPY. My se toho postgresu chceme zbavit, aplikace stejne v 8.3 nejede tak co. Kdyz se to musi predelat, tak uz to predelat pod oracle nebo db2. za 3/4 roku by vysla 8.4 a byly bychom tam kde predtim. Prilis casto vychazeji nove, nekompatibilni verze, ktere navic vyzaduji zdlouhavy export/import dat. Kde je ta uspora? Oracle vychazi jednou za 4 roky.

    Pgsql je jednoducha db a nic poradneho to neumi (OLAP dotazy, Javu, Replikaci, HA, GUI). Kdyz muzu mit za 5*120 USD DB2 Workgroup Edition (5 users) coz se da pro web pouzit pokud nechci rovnou pouzit levnejsi Express nebo komunitni free verzi, tak fakt nevidim duvod proc ji misto postgresu nedoporucovat.
  • 27. 2. 2008 11:31

    Pavel Stěhule
    Teda sorry - ale jeste jsem nenarazil na to, ze by nekdo pouzival orezany express oracle. Obcas se pouziva express edition microsoft SQL, u firem, ktere bezely na accesu. Osekane verze Oraclu nebo DB2 - asi zijes v jinem svete.