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: ( ~51 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: ( ~51 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: ( ~51 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: ( ~51 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: ( ~51 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: ( ~50 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: ( ~38 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: ( ~49 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: ( ~38 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: ( ~51 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: ( ~48 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: ( ~51 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: ( ~51 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: ( ~51 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: ( ~48 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: ( ~51 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: ( ~51 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: ( ~51 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: ( ~44 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 |
|
|
|
Příspívat do diskuze mohou pouze registrovaní uživatelé.
|
|
![>](img/sipka2.png)
Vyhledávání software
![>](img/sipka2.png)
Vyhledávání článků
28.11.2018 23:56 /František Kučera Prosincový sraz spolku OpenAlt se koná ve středu 5.12.2018 od 16:00 na adrese Zikova 1903/4, Praha 6. Tentokrát navštívíme organizaci CESNET. Na programu jsou dvě přednášky: Distribuované úložiště Ceph (Michal Strnad) a Plně šifrovaný disk na moderním systému (Ondřej Caletka). Následně se přesuneme do některé z nedalekých restaurací, kde budeme pokračovat v diskusi.
Komentářů: 1
12.11.2018 21:28 /Redakce Linuxsoft.cz 22. listopadu 2018 se koná v Praze na Karlově náměstí již pátý ročník konference s tématem Datová centra pro business, která nabídne odpovědi na aktuální a často řešené otázky: Jaké jsou aktuální trendy v oblasti datových center a jak je optimálně využít pro vlastní prospěch? Jak si zajistit odpovídající služby datových center? Podle jakých kritérií vybírat dodavatele služeb? Jak volit vhodné součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně datové centrum spravovat? Jak co nejlépe eliminovat možná rizika? apod. Příznivci LinuxSoftu mohou při registraci uplatnit kód LIN350, který jim přinese zvýhodněné vstupné s 50% slevou.
Přidat komentář
6.11.2018 2:04 /František Kučera Říjnový pražský sraz spolku OpenAlt se koná v listopadu – již tento čtvrtek – 8. 11. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář
4.10.2018 21:30 /Ondřej Čečák LinuxDays 2018 již tento víkend, registrace je otevřená.
Přidat komentář
18.9.2018 23:30 /František Kučera Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář
9.9.2018 14:15 /Redakce Linuxsoft.cz 20.9.2018 proběhne v pražském Kongresovém centru Vavruška konference Mobilní řešení pro business.
Návštěvníci si vyslechnou mimo jiné přednášky na témata: Nejdůležitější aktuální trendy v oblasti mobilních technologií, správa a zabezpečení mobilních zařízení ve firmách, jak mobilně přistupovat k informačnímu systému firmy, kdy se vyplatí používat odolná mobilní zařízení nebo jak zabezpečit mobilní komunikaci.
Přidat komentář
12.8.2018 16:58 /František Kučera Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek – 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.
Přidat komentář
16.7.2018 1:05 /František Kučera Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.
Přidat komentář
Více ...
Přidat zprávičku
![>](img/sipka2.png) Poslední diskuze
31.7.2023 14:13 /
Linda Graham iPhone Services
30.11.2022 9:32 /
Kyle McDermott Hosting download unavailable
13.12.2018 10:57 /
Jan Mareš Re: zavináč
2.12.2018 23:56 /
František Kučera Sraz
5.10.2018 17:12 /
Jakub Kuljovsky Re: Jaký kurz a software by jste doporučili pro začínajcího kodéra?
Více ...
|