LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> Diskuze: článek Výběr správné databáze

chybi mi tam SAPDB / MAXDB
(link)
1.3.2007 16:25
Johann von Nepomuk

jako jedina ma poradny support pro ESQL (ESQL pro postgresql je silene buggy), coz je pro rozumnou rychlost nepostradatelne.

Samozrejme, ze je to ale uplne jina liga, nez ty uvedene databaze.

SAPDB nebrat
(link)
3.3.2007 12:43
Radim Kolář
Věk: ( ~44 let) , Bydliště: Louny

SAPDB je strasne bugova, i kdyz se dodavala se sapem tak se pouzivala jen jako docasna db nez se zakoupi oracle a jeji nepouzivani doporucovali (pochopitelne neoficialne) i SAP partneri.

Kdyz byla sapdb uverejnena jako opensource tak taky po ni nestek ani pes. Je fakt, diky masivnimu MySQL marketingu ji nekdo pouzivat asi casem zacne.

Re: SAPDB nebrat
(link)
6.3.2007 12:53
Johann von Nepomuk

... K dnesnimu dni je MaxDB u vice nez 3500 SAP-zakazniku v nasazeni. MaxDB ist optimalizovana pro OLTP provoz s nekolika tisici soucasnymi uzivateli a s velikosti spravovanych dat mezi 100 Gbyte az mnoha Tbyte ...

Tak si rikam, ze to neoficialni "doporucovani" asi moc nepomohlo..

Krome jineho je zajimave, ze SAPDB nepouziva ten MVCC a presto to funguje. Proc?

Re: SAPDB nebrat
(link)
6.3.2007 14:03
Pavel Stěhule
Věk: ( ~44 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Je to drb, ale rozhodne SAP nema nejlepsi povest. A jelikoz SAP dokaze bezet i nad MySQL, tak zrovna asi nejmodernejsi DB featury nepouziva.

Re: SAPDB nebrat
(link)
6.3.2007 15:57
Radim Kolář
Věk: ( ~44 let) , Bydliště: Louny

V prvni rade je potreba upozornit ze pocet instalaci o kvalite software nevypovida, vypovida o oblibenosti. O tom, co se nainstaluje rozhoduje management na zaklade barevnych marketingovych materialu.

V praxi je videt, ze podprumerny produkt s nadprumernym martketingem ma mnohem vic instalaci nez nadprumerny produkt s podprumernym marketingem. Prikladu je okolo nas cela rada.

Neni mne znamo zeby sap behal na mysql. pokud si dobre pamatuju beha na oracle, db2, sapdb, microsoft sql.

Zpet k tematu. Pokud mluvite o tomhle pdf, ja z z nej ctu neco jineho. Pisi tam ze SAP DB se pouziva v 3.5k instalaci SAPu na svete, jelikoz pocet SAP instalaci je cca 100k, tak je videt, ze SAPDB se prakticky nepouziva. Je take jeste soucasti SAP bundlu, ktery maj asi 7k instalaci, ale tech 7k lidi si nemohlo rozhodnout ze chce misto sapdb Oracle.

Re: SAPDB nebrat
(link)
6.3.2007 20:44
Pavel Stěhule
Věk: ( ~44 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Pochybuju, ze by nekdo provozoval SAP nad MySQL, ale nekde jsem narazil na zminku, ze je MySQL certifikovana pro SAP.

Nasazení DB
(link)
2.3.2007 08:17
Petr Zajíc
Věk: ( ~44 let)

Ahoj Marku,

"PgSQL, nebo FbSQL asi nebude příliš rozumné nasadit do míst, kde se často přepisují údaje. " - to jsem moc nepochopil. Znamená to, že vidíš jako nejvhodnější pro taková řešení MySQL? To mi přijde divné, vždyť kvůli multigenerační architektuře (kterou má Fb a víceméně i PgSQL) by to mělo být právě naopak, ne?

Jinak díky za článek, super.

Re: Nasazení DB
(link)
2.3.2007 08:46
MaReK Olšavský
Věk: ( ~43 let) , Pracovní pozice: ?? Asi "holka pro vše" , Praxe v IT let: ( ~ let) , Bydliště: Duchcov

Mno ten zádrhel je v té multigenerační architektuře (MVCC). Ty data prostě rostou rychle, anžto Ti tam všechno zůstává, byť se k tomu nedostaneš. MySQL takto neroste, to snad víš, prostě zamkne řádek, nebo tabulku, uděla změny a odemkne. Samozřejmě, že PgSQL a FbSQL je vynikající volba, ale je třeba udělat pár kroků navíc a ty starý, neplatný data čistit.

Jinak jak koukám na MySQL, tak se z toho stává dospělá databáze. Pavel Stěhule poznamenat, že až nasadí ten nový engine, tak z toho udělají PgSQL :-D.

Re: Nasazení DB
(link)
2.3.2007 10:10
Ondřej Čečák (TEAM)
Věk: ( ~31 let)

Mno ten zádrhel je v té multigenerační architektuře (MVCC). Ty data prostě rostou rychle, anžto Ti tam všechno zůstává, byť se k tomu nedostaneš. MySQL takto neroste, to snad víš, prostě zamkne řádek, nebo tabulku, uděla změny a odemkne

Slo by to trochu exaktneji? Alespon ve me takovahle ex cathedra utrousena moudra moc duvery nevzbuzuji ...

Re: Nasazení DB
(link)
2.3.2007 10:26
Hynek (Pichi) Vychodil
Věk: ( ~42 let) , Pracovní pozice: software architect , Praxe v IT let: ( ~15 let) , Bydliště: Brno

Co je na tom neexaktního? PgSQL a FbSQL všechna UPDATE fyzicky převádí na INSERT, DELETE, kdežto MySQL dělá LOCK, UPDATE. To může vést k problémům se zabraným místem. Od toho je taky v PgSQL třeba to VACUUM, že? Na druhou stranu z toho vyplývají ty performance problémy MySQL při masivním konkurenčním přístupu.

Re: Nasazení DB
(link)
2.3.2007 12:19
Ondřej Čečák (TEAM)
Věk: ( ~31 let)

Co je na tom neexaktního?

OK, tak to asi jenom nevidim. Chapu rozdil mezi UPDATE v MySQL a postgresovym chovanim podobnem "copy-on-write" modelu, ale uz nevidim, ze je PostgreSQL nebo Firebird/Interbase mene vhodne do situaci, ve kterych se casto prepisuji data.

Strucne -- pro srovnani dvou ruznych pristupu mi prijde vhodnejsi to mit zmerene nez neco obecneho tvrdit.

Re: Nasazení DB
(link)
2.3.2007 16:42
Aleš Hakl
Bydliště: Praha

Prakticka zkusenost je asi takova, ze nevadi ani tak moc, ze se meni hodne, ale ze se uvnitr jedne transakce meni hodne, to by i odpovidalo teoretickym predpokladum vychazejicim z me predstavy, jak vlastne to copy-on-write v postgresu funguje (ktere ovsem muzou byt uplne spatne).

Nicmene problem toho narustu objemu nespociva ani tak v tom samotnem narustu (disky jsou levne a tak vubec:)). Ale v tom, ze pokud tabulka tech starych revizi obsahuje mnoho, zacne byt ledasco velice pomale (a mam dojem, ze s timto zpomalenim optimalizator prilis nepocita).

Re: Nasazení DB
(link)
2.3.2007 18:26
Pavel Stěhule
Věk: ( ~44 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Pri opravdu intenzivnim update zaznamu je MyISAM zhruba 10x rychlejsi nez MGA architektura. Jinak rychlost updatu samotne tabulky je vec jedna, zalezi take na rychlosti aktualizace indexu, poctu indexu, atd. atd.

Navic MyISAM zajistuje konstatnti rychlost. MGA architektura trpi, ze po urcite dobe ztraci vykon, a po dalsi dobe totalne odpada. A to jak Firebird tak PostgreSQL. Pak je potreba provest na Postgresu VACUUM a na Firebirdu se delalo kolecko back /restore (a mam pocit, ze na to maji nejaky prikaz). Dlouhou dobu diky tomu byla MGA architektura mimo 24/7. Od 7.4 VACUUM nevyzaduje excluzivni zamky, tak tak nevadi, nicmene jistou zatez predstavuje. Na 8.3 uz bude evidence stranek obsahujicich mrtve verze, takze se to zas o neco zrychli a nebude to tak bolet. Nikdy bych ale MGA databazi nenasadil jako HTTP cache.

Re: Nasazení DB
(link)
3.3.2007 14:56
Jan Seifert
Věk: ( ~41 let)

Firebird se snazi verze radku ukladat do te same stranky (v soucasne dobe muze mit stranka tusim 2 az 16 kB) kde je radek, ale kdyz uz neni ve strance misto, musi se ulozit do jine stranky. Pokud jsou pak verze fragmentovane v ruznych strankach, na rychlosti to urcite neprida. Cisteni starych verzi pak probiha bud prubezne pri pristupu k seznamu verzi pri select, nebo pro kompletni vycisteni slouzi sweep databaze nebo backup/restore (ten to udela asi nejlepe, protoze nejen vycisti nepotrebne verze, ale i srovna radky aby v kazde strance bylo zase volne misto, ale samozrejme to znamena odpojit lidi z databaze).

MVCC v pgsql
(link)
3.3.2007 15:28
Radim Kolář
Věk: ( ~44 let) , Bydliště: Louny

To ze se meni data hodne uvnitr jedne transakce nevadi, mvcc db nemusi narozdil od row-locking db udrzovat seznam zmenenych radek. Optimalizer s mrtvymi radky pocitat umi, pokud ma k dispozici aspon trochu aktualni ANALYZE statistiku.

INFO: "data": scanned 3000 of 9001 pages, containing 354736 live rows and 0 dead rows; 3000 rows in sample, 1064326 estimated total rows

btw: co znamena 3000 rows in sample?

Problemem jsou dlouho bezici transakce, ktere blokuji odmazani starych verzi, ale ty jsou problemem v overwriting DB taky. Tam zase zpusobuji jine problemy.

MVCC architektura je v soucasnosti jasny vitez a nejen relacni, ale i objektove orientovane DB na ni prechazeji, protoze je to jediny zpusob jak solidne zvladat hodne aktivnich uzivatelu.

Dost se bavim, kdyz jeste dnes nekteri povazuji Table-level locking za dostatecny nebo dokonce nejlepsi pokud je tabulka hodne aktualizovana.
To bude fungovat snad jen na velmi malych tabulkach (kde je uplne jedno zda pouzivate rychlou nebo pomalou db, vse dobehne v rozumnem case) nebo pro velmi maly pocet aktualizovanych radek (najdou se relativne rychle pomoci indexu).

Porad tedy nechapu kde vidite problem

1.
pokud je v tabulce maly pocet dead rows, tak se vacuum na ni nevyplati (je nutny full table scan tedy generovat hodne io operaci) a zdrzeni zpusobene par radky navic je zanedbatelne.

2.
Pokud tabulka obsahuje napr. 100 live rows a 50000 dead rows, tak uz ty dead rows provoz znatelne brzdi a vacuum tabulky se vyplati, coz autovacuum zjisti a spusti ho. Pokud to autovacuum zjisti prilis pozde tak ho spoustejte casteji nez defaultnich 60 sec.

Pokud batch importy generuji mnohem vice dead rows oproti bezne zatezi aplikace (a tudiz autovacuum reaguje prilis pozde) tak do nich vlozte cas od casu vacuum na nejupdatovanejsi tabulku nebo se smirte s tim, ze pobezi pomaleji. Pokud se neimportuji gigabajty dat nebo stamiliony radek doba importu nehraje zas takovou roli, kdyz diky MVCC neblokuje ostatni uzivatele.

Provozuji nad pgsql nekolik www vyhledavacich enginu a databaze bez MVCC je nepouzitelna. Nemuzete nechat web uzivatele, ktery neco hleda cekat nez se zpracuje import dat nebo naopak odmazani dat, jedna takova davka muze trvat desitky sekund az desitky minut. Vetsina web uzivatelu chce vysledky od vyhledavace do sekundy nebo priste jde jinam.

Re: MVCC v pgsql
(link)
4.3.2007 22:05
Pavel Stěhule
Věk: ( ~44 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Asi se trochu mijime. Psal jsem o pouziti databaze, jako jednoduche kese. V tomhle pripade mam zpravidla jednu tabulku, kde kazda transakce meni jen jeden zaznam navic pod indexem. Samotna operace je tak rychla, ze se nenarazi na zamky (vetsinou). V Postgresu takovou tabulku musite co pul hodiny vacuovat, navic update bude (co tak mam odkoukano 5-10x pomalejsi nez u MyISAM). V kesi drzim jenom session data. Navic vsechny dotazy jdou na primarni klic.

Jakmile zacnu databazi pouzivat jako databazi, pak by MGA mela s prehledem starsi architektury porazet. Pokud databazi pouzivam jako cache, tak MGA pusobi vic skody nez uzitku.

Re: Nasazení DB
(link)
2.3.2007 18:06
Pavel Stěhule
Věk: ( ~44 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Zhruba, MyISAM pri UPDATE, DELETE zamkne tabulku, a zaznam na disku prepise. PostgreSQL pri UPDATE, DELETE vytvori kopii zaznamu a zaradi ji do linearniho seznamu. Potom az do provedeni operace VACUUM PostgreSQL musi prochazet linearni seznam a hledat platny zaznam. Pokud linearni seznam prilis neroste, tak je MGA vyhodnejsi nez prepisovani zaznamu. Skoro odpada nutnost zamykani. Pokud se provadi intenzivni update, delete tak seznam roste a listovani v seznamu uz ma znatelnou rezii. Resenim je castejsi pouziti operace VACUUM. MGA databaze jsou vhodne pro ukladani deletrvajicich dat, pro ukladani docasnych hodnot s pulhodinovou zivotnosti, jako jsou napr. http cache je naopak MyISAM to prave orechove.

Re: Nasazení DB
(link)
2.3.2007 11:42
Jan Seifert
Věk: ( ~41 let)

Firebird nema transakcni log, ale zmeny uklada primo v DB, kazdy radek v tabulce je vlastne seznam zmen s tim, ze nejaktualnejsi verze je na zacatku seznamu. V seznamu zmen jsou pak nejen samotna data, ale i cislo transakce, ktera zmenu provedla. Pri cteni se pak precte bud nejaktualnejsi potvrzena zmena pri izolaci Read Commited, nebo pri izolaci Repeatable Read nejblizsi potvrzena zmena s mensim cislem transakce nez ta co cte.


Vyhodou je, ze transakce ma snadny a rychly pristup ke sve verzi dat a neblokuje pri tom zmenu dat ostatnim, dobre hlavne pri paralelnim pristupu nekolika transakci a soubeznem zpracovani dat. Dalsi vyhodou je moznost spustit zalohu za plneho provozu, zaloha bezi ve sve transakci a opet podle cisel a stavu jednotlivych transakci pozna, co zalohovat a co uz je novejsi.


Jako nevyhodu vidim asi to, ze zalohuju vzdy celou databazi (FB2 uz ma i inkrementalni backup) a v pripade havarie a obnovy db se dostanu jen do mista zalohy, ale bez transakcniho logu uz se nedostanu do stavu tesne pred havarii db. A dalsi nevyhoda je prave to, ze stare uz nepotrebne verze radku stale zustavaji v databazi, pak je vhodne obcas spoustet sweep databaze, nebo udelat zalohu a obnovu, tim se stranky zase procisti od nepotrebnych verzi.


Jinak pokud jde o zkusenosti, Interbase jsme zacali pouzivat ve spojeni s Delphi 3, tehdy slo o IB 4, pak pres IB 5.5 a 6 jsme presli na Firebird 1 a nyni jedem na 1.5, FB 2 zkousime. Asi hlavni, co nam na tom bezi je system duchodoveho pojisteni, tedy samotny vypocet vyse davek, mesicne vyplaceni cca 45000 duchodu a davek, z toho srazky, obstavky a pohledavky, uctovani dle polozkove skladby a tak. DB ma v soucasne dobe cca 5 GB, server je na Linuxu, klienti jsou v Delphi na Win a beha to velmi pekne (tuk tuk tuk :-). Hlavne ta sprava DB je nenarocna, o vse se stara gbak, tar a scp ve spojeni s cronem - staci mit hohy na stole a kazde rano se podivat na mail, co prijde od cronu :-).

Re: Nasazení DB
(link)
2.3.2007 12:17
Petr Zajíc
Věk: ( ~44 let)

Přesně tak, já Firebirdu dosti fandím a nedám na něj dopustit. Jinak, hezký článek o popisu MGA je na http://www.firebirdsql.org/doc/whitepapers/fb_vs_ibm_vs_oracle.htm

Válka mezi přístupem LOCK - UPDATE - UNLOCK a verzováním je dosti stará a nemá vítěze; samozřejmě by bylo zajímavé podrobit jednotlivé databáze testům kdy několik klientů čte a jiných několik zapisuje. Tam by pak rozdíly byly veliké. Ale pro weby? Většinou bude stačit kterákoli ze tří zmíněných databází úplně v pohodě.

Re: Nasazení DB
(link)
2.3.2007 17:00
Aleš Hakl
Bydliště: Praha

V posledni dobe se mi jevi, ze verzovani zacina pomalu ale jiste vitezit, protoze podobny pristup pouziva mnoho souborovych systemu. Drive spise ve specialnich aplikacich kde to jinak moc nejde (BSD LFS, uloziste ruznych distribuovanych FS, linuxove JFFS, FTL nejruznejsich kusu hardware...) ale v posledni dobe i royumne obecne unixove FS jako je treba solarisi ZFS nebo linuxovy Reiser4.

Zajimave, je ze Rosenblum a Ousterhout v "The Design and Implementation of a Log-Structured Filesystem" uvadeji presne opacne argumenty proc je tento pristup lepsi nez pan Olsavsky, nicmene lze usuzovat, ze u souboroveho systemu (vsechny pristupy prochazeji jednim mistem) lze problem s odstranovanim starych revizi resit vyrazne jednoduseji a efektivneji, nez u databazovych systemu jako je FB ci postgresql (kde je synchronizace mezi uzivateli uloziste minimalni).

Nicmene pravdepodobne lze souhlasit s tim, ze pro jiste aplikace je takovyto pristup nevhodny a jednou z nich bude vetsina verejne pristupnych webu, kde je to cele budto uplne jedno, nebo se zacne projevovat overhead spojeny s hledanim poslednich verzi hodnot.

MVCC v databazich
(link)
4.3.2007 11:36
Radim Kolář
Věk: ( ~44 let) , Bydliště: Louny

V tom dokumentu (zajimave cteni) je nekolik chyb. Oracle7 v zadnem pripade mvcc neni, to umi az devitka. Sedmicka porad blokuje reader, pokud writer stoji s cursorem na zmenenem radku.

Oracle krome ORA-1555 (pomerne rare chyba, na tohleto vypadava kdyz ma jeste misto v rollback segmentu) vypadava mnohem casteji na rollback segment full. DB2 rollback segmenty nepouziva.

Ten pripad s transakcema ukazuje ze v Oracle 9i je MVCC implementovano spravne. Takhle se to ma chovat. Pokud toto chovani je v konkretnim pripade naskodu, aplikace si ma radek zamknout nebo switchnout isolation level.

Jedine co mne zaujalo, je to, ze firebird pravdepodobne odstranuje stare radky prubezne. t.j. kdyz na ne narazi napr. pri tablescanu. Tohleto sice usetri read io potrebne pro vacuum v pgsql, ale pravdepodobne to bude generovat vice zapisu protoze k prepisu stranek bude dochazet tim padem casteji, a zapisy jsou na diskovych polich vyrazne pomalejsi nez ready.

Re: MVCC v databazich
(link)
4.3.2007 22:34
Pavel Stěhule
Věk: ( ~44 let) , Pracovní pozice: programátor , Praxe v IT let: ( ~17 let) , Bydliště: Skalice, Benešov

Je otazkou nakolik to bude efektivni. Cituji z Pavla Cisare "ackoliv jsou nepotrebne verze radku odstranovany prubezne, je vhodne pravidelne provadet vycisteni databaze (sweep)." Navic zalezi na architekture Firebirdu. U Super Serveru jsou mrtve zaznamy oznacene pouze ke zruseni. O samotne zruseni se stara separatni proces. V pripade, ze by na vytizenem serveru automaticky sweep zpusoboval problemy, lze jej potlacit. Krapet mi to pripomina VACUUM v blede modrem baleni.

Pěkné...
(link)
9.3.2007 19:38
Lukáš Zapletal
Věk: ( ~37 let)

Velmi pěkné... Nedávno vyšlel Pavlovi výborný článek o Postgresu na rootu, zhruba ve stejný čas také podobný čánek na linuxexpresu. Jen tak dál...

http://www.root.cz/clanky/zakys-jmenem-flattening
http://www.linuxexpres.cz/software/srovnani-databazovych-serveru

DISKUZE

chybi mi tam SAPDB / MAXDB 1.3.2007 16:25 Johann von Nepomuk
L SAPDB nebrat 3.3.2007 12:43 Radim Kolář
  L Re: SAPDB nebrat 6.3.2007 12:53 Johann von Nepomuk
    |- Re: SAPDB nebrat 6.3.2007 14:03 Pavel Stěhule
    L Re: SAPDB nebrat 6.3.2007 15:57 Radim Kolář
      L Re: SAPDB nebrat 6.3.2007 20:44 Pavel Stěhule
Nasazení DB 2.3.2007 08:17 Petr Zajíc
L Re: Nasazení DB 2.3.2007 08:46 MaReK Olšavský
  L Re: Nasazení DB 2.3.2007 10:10 Ondřej Čečák
    |- Re: Nasazení DB 2.3.2007 10:26 Hynek (Pichi) Vychodil
    | |- Re: Nasazení DB 2.3.2007 12:19 Ondřej Čečák
    | | L Re: Nasazení DB 2.3.2007 16:42 Aleš Hakl
    | |   |- Re: Nasazení DB 2.3.2007 18:26 Pavel Stěhule
    | |   |- Re: Nasazení DB 3.3.2007 14:56 Jan Seifert
    | |   L MVCC v pgsql 3.3.2007 15:28 Radim Kolář
    | |     L Re: MVCC v pgsql 4.3.2007 22:05 Pavel Stěhule
    | L Re: Nasazení DB 2.3.2007 18:06 Pavel Stěhule
    L Re: Nasazení DB 2.3.2007 11:42 Jan Seifert
      L Re: Nasazení DB 2.3.2007 12:17 Petr Zajíc
        |- Re: Nasazení DB 2.3.2007 17:00 Aleš Hakl
        L MVCC v databazich 4.3.2007 11:36 Radim Kolář
          L Re: MVCC v databazich 4.3.2007 22:34 Pavel Stěhule
Pěkné... 9.3.2007 19:38 Lukáš Zapletal




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

13.9.2017 8:00 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tentokrát netradičně v pondělí: 18. září od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

3.9.2017 20:45 /Redakce Linuxsoft.cz
PR: Dne 21. září 2017 proběhne v Praze konference "Mobilní řešení pro business". Hlavní tématy konference budou: nejnovější trendy v oblasti mobilních řešení pro firmy, efektivní využití mobilních zařízení, bezpečnostní rizika a řešení pro jejich omezení, správa mobilních zařízení ve firmách a další.
Přidat komentář

15.5.2017 23:50 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 18. května od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

12.5.2017 16:42 /Honza Javorek
PyCon CZ, česká konference o programovacím jazyce Python, se po dvou úspěšných ročnících v Brně bude letos konat v Praze, a to 8. až 10. června. Na konferenci letos zavítá např. i Armin Ronacher, známý především jako autor frameworku Flask, šablon Jinja2/Twig, a dalších projektů. Těšit se můžete na přednášky o datové analytice, tvorbě webu, testování, tvorbě API, učení a mentorování programování, přednášky o rozvoji komunity, o použití Pythonu ve vědě nebo k ovládání nejrůznějších zařízení (MicroPython). Na vlastní prsty si můžete na workshopech vyzkoušet postavit Pythonem ovládaného robota, naučit se učit šestileté děti programovat, efektivně testovat nebo si v Pythonu pohrát s kartografickým materiálem. Kupujte lístky, dokud jsou.
Přidat komentář

2.5.2017 9:20 /Eva Rázgová
Putovní konference československé Drupal komunity "DrupalCamp Československo" se tentokrát koná 27. 5.2017 na VUT FIT v Brně. Můžete načerpat a vyměnit si zkušenosti z oblasti Drupalu 7 a 8, UX, SEO, managementu týmového vývoje, využití Dockeru pro Drupal a dalších. Vítáni jsou nováčci i experti. Akci pořádají Slovenská Drupal Asociácia a česká Asociace pro Drupal. Registrace na webu .
Přidat komentář

1.5.2017 20:31 /Pavel `Goldenfish' Kysilka
PR: 25.5.2017 proběhne v Praze konference na téma Firemní informační systémy. Hlavními tématy jsou: Informační systémy s vlastní inteligencí, efektivní práce s dokumenty, mobilní přístup k datům nebo využívání cloudu.
Přidat komentář

15.4.2017 15:20 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě IoT a radiokomunikace? Přijď na sraz spolku OpenAlt, který se bude konat ve středu 19. dubna od 18:30 v Šenkovně (Sokolská 60, Praha 2).
Přidat komentář

5.3.2017 19:12 /Redakce Linuxsoft.cz
PR: 23. března proběhne v Praze konferenci na téma Cloud computing v praxi. Hlavními tématy jsou: Nejžhavější trendy v oblasti cloudu a cloudových řešení, Moderní cloudové služby, Infrastruktura současných cloudů, Efektivní využití cloudu, Nástrahy cloudových řešení a jak se jim vyhnout.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

18.9.2017 14:37 / Rojas
high security vault

15.9.2017 7:33 / Wilson
new zealand childcare jobs

31.8.2017 12:11 / Jaromir Obr
Re: ukůládání dat ze souboru

30.7.2017 11:12 / Jaromir Obr
Národní znaky

27.7.2017 12:24 / Jaromir Obr
Cteni/zapis

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2017) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze