Oracle : dostáváme na prdel (3)

16.7.2018 07:44 | Přečteno: 7195× | plky | poslední úprava: 16.7.2018 07:44

A je to tady, sranda s Oracle pokračuje a má tendenci gradovat. Dosáhli jsme opět rekordní sumy za licence a to není vše.

Úvod

Někdo si jistě bude pamatovat předešlé zápisky, kdo ne, tady jsou :
Oracle : dostáváme na prdel
Oracle : dostáváme na prdel (2)

Situace graduje, cenově se nedostáváme na dvojnásobek předchozího zápisku, ani trojnásobek, ani desetinásobek...
Pro představu, před rokem a půl jsme provedli obnovu celé IT infrastruktury. Nové servery, 10Gbit switche, dva Netappy, licence za Windows Servery Datacenter, za ESXi, vCenter, Veeam Enterprise Plus atd. atd. atd.
Toto vše stálo téměř polovinu toho, co nyní dáváme jen za licenci Oracle Enterprise + RAC + Tuning Pack + ještě pár option kolem a kolem.

To horší ale přijde

Pokud si někdo z vás myslí, že úvod výše je krutý, tak se plete, protože to je už jen třešnička na dortu. Reál je bohužel o něco smutnější. Smutnější je v tom smyslu, že se jedná o licenci pouze na 8x core, 2+2 (dva nody v RAC) pro primární stranu a 2+2 pro zálohu (dva nody v RAC standby). Máme intel CPU, u kterého se počet core násobí dvěma, takže reálně můžeme využít 4+4 na primáru a 4+4 na záloze. Oproti původní databázi Standard Edition si tak procesorově pohoršujeme.

To není konec

Jestli si myslíte, že teď už je to smutný dost, tak vás zklamu. Jelikož hw serverů má více jader (RAC = 2x server + 1x storage), aktuálně to je 2x server, každý 6x core (v dnešní době už se i celkem těžko kupuje něco menšího), tak musíme nasadit pro Oracle virtualizaci. Mno, kdo si pamatuje na první zápisek ohledně Oracle, tak ví, že Oracle uznává jen svá virtualizační řešení. Zkrátím to, musíme nasadit 4x Oracle VM Server + 1x Oracle VM Manager. Naštěstí už ten Manager nepotřebuje OracleDB, používá MySQL, takže aspoň to není tak náročné. Samozřejmě je nutná licence pro toto virtualizační řešení postavené nad XENem. Ale to je jen za pár stovek tisíc, což je nic oproti samotné licenci na Oracle, takže se to v koncové částce ztratí.
Super bude Oracle BI, taktéž za pár stovek tisíc, taktéž se to ve finální částce ztratí, takže proč ne.
Každopádně ještě k Oracle VM, asi o tomto řešení sepíšu nějaký článek, totálně dehonestující, protože horší sračku jsem snad v životě neviděl. Nejdřív vás Oracle dotlačí k nákupu jejich vlajkové lodě, aby vás vzápětí donutil tuto naleštěnou loď provozovat na totálním prohnilém shitu.

Proč nákup?

K nákupu EE verze vedlo několik důvodů.

• Oracle změnil licenční podmínky, takže po upgrade z 11.2 na 12.2 db bychom stejně nemohli využívat tolik core jako doposud, Standard Edition Two umí využít 16x thread (max 8x pro jednu instanci). Docela dost rosteme, takže za chvíli by to asi nemuselo stačit. EE verze toto omezení nemá, jen je ale každý core pěkně mastný. Osobně bych řekl, že s SE2 by se dalo ještě delší dobu vydržet, procesorově.
• Dalším důvodem byl DataGuard, což je řešení, které umožňuje replikaci db na záložní stranu s téměř zanedbatelným rollbackem dat. Doteď jsme využívali k replikaci vlastní skripty, které kopírovaly rsyncem archivační logy do backup lokality, tam se pak pomocí cronu aplikovaly na standby db. Rollback dat byl pak cca 15min. S DataGuardem lze docílit mnohem menšího rollbacku a lze si vybrat možnost přenosu. Lze využít MaximumPerformance, kdy primární strana nečeká na potvrzení od standby (toto používáme my kvůli výkonu). O něco více pomalejší je pak režim, kdy primární strana čeká na potvrzení od standby, takže obě databáze jsou ve stejný čas 1:1. Režimů replikace existuje více druhů. Pak existuje něco jako Active DataGuard, který vylepšuje DataGuard jako takový, ale to je placená option (= pár stovek tisíc).
• Vývojáři silně toužili po tuning packu, což je další option za nemálo peněz. Tato věcička umí v reálném čase shromažďovat data o konkrétních procesech v db, co využívá kolik ram, jaký select generuje jaké IOPs, kolik tahá konkrétní věc z db dat atd. atd. Prostě velmi podrobné statistiky o tom, co se děje a co lze optimalizovat.
• Pokročilé cachování, které SE2 nemá byl další důvod. Dále lze zmínit paralelní zpracovávání selectů. Lze provádět paralelní export/import dat, podpora více jak jedné plugable db (to ale nevyužijeme).
• Dále lze zmínit podporu snapshotování, což v našem případě hlavně využijeme k zálohovací standby, ze které se budou dělat dumpy. Oracle má totiž dva druhy zálohy, jeden je pomocí rmanu a je to binární full dump, který lze použít k duplikaci db, obnově a v kombinaci s archivačními logy se lze dostat do jakéhokoli času atd., ale nejde z tohoto druhu zálohy vytáhnout jednu tabulku. Je to prostě 100% konzistentní dump, který se vytvoří velmi rychle. Pak má data pump (expdp/impdp), což udělá export db, ve které není všechno (např. tam nejsou db uživatelé), ale lze z tohoto druhu zálohy vytáhnout rychle jednu tabulku obnovit jí atd. Problém je, že tento typ dumpu potřebuje mít databázi ve write režimu, čímž se standby poškodí a nelze to vzít zpět. Toto jsem řešil vlastním monstrózním skriptem, který automaticky stopnul db, vytvořil LVM snapshot na vl, kde byl oracle, pak oracle spustil, přepnul do rw, udělal dump, stopnul db, obnovil lvm snapshot, nahodil db, spustil komprimaci zálohy a následně pokračoval v aplikaci transakčních logů z primární db (+ se ošetřuje hafec věcí, zda něco není drženo, zda je dost místa ve vg atd.). S podporou snapshotování se celý proces značně zjednoduší a urychlí.
• block change tracking pro rychlé inkrementální zálohy. Doteď jsem jel 2x denně expdp + 1x týdně rman dump + záloha archivačních logů. Teď bych mohl dělat každý den jednu rozdílovku navíc, kdybych se chtěl dostat do nějakého konkrétního času, bude rychlejší obnovit rozdílovku, než čekat, až se nalijou tisíce archivačních logů za x dní.
• Sice jsme měli licenci na CPU a vše okolo, ale neměli jsme ve smlouvě, že může mít k db přístup i třetí strana. A tou třetí stranou je myšlena i dceřinka, i sestra. Jo, pěkný výjeb. Kdo to nezná a nakoupí bez podobných jakoby textíků, tak má Oracle další páku.

Samozřejmě existuje spousta řešení třetích stran, které fce EE verze částečně nahrazují a celé to pak vyjde relativně za pakatel. Minimálně náhrada za DataGuard je, stejně jako alternativy pro tuning pack.

A jak to šlape?

Původní RAC 11.2 běželo jako dva nody se společným storage připojeným přes FC 8Gbit. Aktuálně byla provedena migrace na 2x node RAC 12.2 a jako backend je NetApp SSD pole připojené přes NFS4.1. My nemáme možnost, jak nasimulovat produkční zatížení, takže jsem se trochu bál regulace ze strany Netappu, kdy reálná rychlost se storage je cca 2,5Gbit, protože další servery připojené k NetAppu na jiná pole. Reálně tedy RAC nejede 2x10Gbit proti NetAppu, ale tak 2x2,5Gbit. Každopádně odhad byl dobrý a vše šlape velmi dobře. Cachování je oproti 11.2 úplně někde jinde a třeba takové generování jedné statistiky trvá místo 2h asi 30min. Vývojáři jsou taktéž nadšený, protože se jim díky tuning packu odkrylo spoustu prasečinek (stovky tisíc zbytečných selectů denně apod.)

Jinak migrace byla připravena dobře a okno jsme stihli s hodinovou rezervou, takže proběhla asi jedna z nejdelších odstávek ve firmě vůbec, kdy jsme celou db a vše okolo migrovali asi 6,5h. Export byl otázkou 70min, import 4,5h + 1h na ruční práce kolem a kolem. Kdybychom takové okno nedostali, museli bychom jít cestou postupných odstávek, během kterých bychom postupně povyšovali verzi Oracle a finální migraci na nový hw bychom pak udělali formou standby.

Předmigrační procesy

Přechod z 11.2 na 12.2 nejde udělat jen tak, spousta věcí nemusí fungovat. Museli jsme tedy všude sjednotit verze Oracle Klienta na instant 12.2, který balím do vlastního instalátoru. Konečně se mi podařil odhalit bug v tomto klientovi, který tam evidentně přetrvává dost dlouho, takže mám konečně asi bezchybný instalátor. Pár věcí se muselo přepsat, protože byly zahnízděný na konkrétní verzi. Problém byl s OracleAS, od kterého jsme migrovali na Weblogic Basic a jako alternativu jsem rozjel i Payara server. Nakonec nám fungují všechny app na obou serverech, ale zatím se jede provoz na Weblogicu (oproti Payara taky pěkný zážitek).

Závěr

Celá věc je mi trochu šumák, resp. pokud je firma ochotna nakoupit licence na Enterprise verzi, tak si rád budu hrát zase s něčím novým. Na celé věci mně sere jen jedna věc, tou je právě nutnost Oracle VM, zbytečně virtualizovat, zbytečně někde musí běžet manager, zbytečná starost navíc, která podle mně celé řešení značně degraduje.

Co dál dodat, no snad jen to, že teď mně čeká migrace další naší Oracle DB, ale tentokrát nemá trapných 500GiB, ale 7TiB.

       

Komentáře

[Heron]

Hele, ty máš od firmy povoleno šířit tyto informace? Nebo ve smlouvě tohle zapomněli ošetřit?

Sice nikde není uvedeno jaká je to firma (nebo jsem si toho jen nevšiml, je mi to jedno), ale už jen z těch indicií za ty roky nebude složité na to přijít.

Jinak ten zápisek a celý ten příběh se mi ani nechce komentovat, nádherná ukázka vendor lock-in.

[Max]

Nemám to zakázáno, pokud vím. Každopádně nezveřejňuji ceny ani jména firem. Ani nevím, co by v tomto případě mělo vadit. Informace, že provozujeme Oracle EE přes NFS proti NetAppu? Nebo info o licenčních podmínkách Oracle? To si nemyslím.
Tak samozřejmě, že aktuální situace je silný vendor-lock a určitě z toho hafec let nepůjde nijak vylézt, pokud někdy.
Navíc Oracle silně tlačí firmy do Cloudu, a to dost krutě. Jsem zvědavý, kdy nastane nějaký brutálnější licenční zlom, který donutí firmy přemigrovat do cloudu.
Zdar Max

[Heron]

Ani nevím, co by v tomto případě mělo vadit.

Nevím, zda to vadí, ale za ty roky jsi tady odkryl poměrně značnou část infrastruktury, její slabiny (potenciální SPOF) a tak. Toho by mohl někdo zneužít.

[Max]

Mno, ono se všechno dost často předělává. Co bylo před pár lety už teď třeba neplatí.
Zdar Max

[Grunt]

Každopádně nezveřejňuji ceny

Proč? To je nějaké tajemství?

[Käyttäjä 11133]

Ano. Když to budeš dělat, osolí ti to při příští poptávce

[Grunt]

Bych jim to reklamoval, Předmět: Rabatt nebo jdu na pivo…

[〹]

Kam by to trhovec přišel, kdyby se rozkřiklo, že Aurora koupila stejné tričko jako Bonifác, ale za osm pětek místo tří stovek? Cecílie i Drusila by pak odmítaly zaplatit víc než nejnižší známou cenu, osm pětek, trhovec by přišel o kšeft, Emil, otec Bonifáce, by mu na to ještě hubu přišel rozbít, a Drusila by křičela, že by ho nejraději u soudu za nekalé obchodní praktiky podusila.

[Grunt]

Co si kdo vyjedná je mi naprosto šumák. Zajímalo mě pouze jak za tuhle "radost" může orientačně vypadat faktura. Nikde nevidím ceníky. Kdo ví proč, že? Drusila nech si řve co chce.

[〹]

Předpokládal bych, že se Oracle snaží zákazníka pumpnout, co to jen jde. Povolit zveřejnění té částky by bylo v rozporu s takovou strategií. Pokud to tak skutečně je, pro někoho to ostatně může být i výhodné, protože to dostane tak levně, aby na to dosáhl. Oracle prodá licenci navíc, kterou by jinak neprodal, a firma dostane produkt, který by si jinak nemohla dovolit. To spekuluji, ale na druhou stranu nevidím důvod, proč jinak tu cenu tajit.

[Grunt]

Předpokládal bych, že se Oracle snaží zákazníka pumpnout, co to jen jde. Povolit zveřejnění té částky by bylo v rozporu s takovou strategií.

Pak by mě zajímalo jak to dělají u veřejných zakázek kde je to zveřejňovaní faktur povinné a ještě se to musí nějak na oko vysoutěžit. Zlatá Veřejná správa, že?

[Käyttäjä 11133]

Proč asi veřejná správá platí (skoro) listové ceny... :)

[Käyttäjä 11133]

Ceník ti pošle na požádání kterýkoli obchodník; to že se nedožiješ kvůli srdeční epizodě toho aby ses zeptal na skutečnou cenu je věc druhá :D

[limit_false]

U cen komercnich produktu je pochopitelne proc se tak chovaji, vytriskat zkousenim max. V momente, kdy se to promitne na zdravotni pojisteni (pripad USA), to zacne byt katastroficke. Nemocnice si zacnou uctovat nekolikrat vic, aby to pak s pojistovnama uhadaly na nejakou "kompromisni cenu" a pokryly i nejake lidi bez pojisteni.

Zvlastni efekt je, ze zakon, ktery po CEO pozadoval zverejeni jejich prijmu naopak misto ocekavaneho snizeni vedl k zvyseni, protoze si pak manageri mohli lepe vybirat.

Zajimalo by me, ktery pripad by nastal, kdyby se hromadne napr. ceny Oracle licenci zverejnili (nejak anonymne treba).

[JS1]

Zvlastni efekt je, ze zakon, ktery po CEO pozadoval zverejeni jejich prijmu naopak misto ocekavaneho snizeni vedl k zvyseni, protoze si pak manageri mohli lepe vybirat.

To je myslim fake news. V Norsku jsou danova priznani verejna (a tudiz je verejna i kompenzace), a zadny takovy efekt tam nepozorujeme.

Navic i teoreticky je celkem jasne, ze po zverejneni cen by se cena snizila. Oracle zna vsechny ceny svych zakazniku, zakaznici ne. Kdyby cena mela vzrust, znamenalo by to, ze Oracle ted neco nekomu prodava pod trzni cenou, cemuz je tezke uverit.

[Max]

Ceny se nezveřejňují, je to vesměs součástí smlouvy. Jinak price list je dostupný veřejně, viz jejich eshop : shop.oracle.com
Dle pricelistu tedy :

• EE za jeden CPU/core : 1 000 000,-Kč, za 8x CPU to je tedy 8 000 000.-Kč (v případě Intel Xeon blabla je multiplikátor 2, takže 16x fyzický core)
• RAC option za jeden CPU : 492 000,- za 8x CPU tedy 3 900 000,-
• Tuning Pack za CPU 100 000,-, tzn. 800 000,-Kč
• Oracle VM cca 77 000,-Kč / server, takže 4x 77 000,-Kč

Dle pricelistu tedy výsledná cena jen za DB : 12 700 000,- Kč + Oracle VM za 300 000,-Kč, celkem tedy dle oficiálního pricelistu 13 000 000,-Kč bez DPH
+ pak každý rok nějakou poměrnou částku za support.
Zdar Max

[pc2005]

Hmm nebylo by levnější koupit nějaký obecný HW a najmout sysadmina, aby řešil systém v OSS?

[Max]

Nerozumím ničemu v té větě, co je to obecný hw? Jaký sysadmin? Systém je linux, nebo myslíš nějaký jiný systém?
A jak by to vyřešilo, že všechno, co se u nás vyvíjí je silně vázáno na Oracle?
Zdar Max

[xkucf03]

Kolik máte řádově vývojářů? Jednotky, desítky, stovky?

[Max]

Asi 3 vyvíjejí starý IS ve VFP (od cca 2004), 3 vyvíjejí nové řešení nad C# (to předělat pod jinou db už není složité), 2 dělají web apps, jeden dělá hlavně věci v Oracle a Apexu, další pendluje někde mezi (občas přidá fce do starého IS, občas udělá nějakou edi komunikaci atd.).
Přepsat tedy starý projekt ve VFP, který je silně vázán na Oracle, je v nějakém rozumném čase nereálné. Obzvláště, když seznam top urgent TODO fcí je docela velký a dále víme, jak to bývá s dokumentací u takto starých projektů.
A další vývojáře sehnat je problém, ale nevím, zda obecně, nebo kvůli ceně. Každopádně současný stav nezaměstnanosti spíše říká, že lidi nejsou, musí se jedině přetahovat z jiných firem.
Jinak nemáme jen starý projekt ve VFP a nový v C#, ještě existuje spousta app bokem. Jsou to malé aplikace pro různé komunikace, ovládání, kioskové systémy, něco běží na java aplikáči atd.
Je to celé opravdu hodně rozsáhlé.

Jinými slovy, spousta lidí na to má hodně zjednodušený pohled, ale řešení je reálně hodně komplikované a časově náročné.
V kombinaci s tím, že je potřeba stále implementovat nové věci, je jasné, že žádný velký převrat se v horizontu dalších 8 let nemůže očekávat.
A ani není v plánu to nějak řešit, všichni jsou s Oracle spokojený.
Zdar Max

[trekker.dk]

A ani není v plánu to nějak řešit, všichni jsou s Oracle spokojený.

A to ani po tomhle účtíčku za tu útratičku?

[Max]

Ne, resp. nevím o tom. Kdyby to tak nebylo, tak by k takové investici ani nedošlo a byla by snaha překlepat nějaké období na Standard edici.
Zdar Max

[Grunt]

Vcelku standard. Prostě se to zahrne do položky „náklady“. Ono třeba vybavit strojírenský kanclík běžným softem + nějakými oborovými nástavbami není o moc levnější a ty podmínky používaní jsou úplně stejně pitomé. Ale holt kdo chce vydělávat, tak musí taky investovat. A na to podobné firmy spoléhají. Oracle není ani první, ani poslední.

[Heron]

To je skoro takový stockholmský syndrom. Zažil jsem to před lety v diskusi na elektrika.cz po té, co Piráti nějak prosadili stavební normy zdarma (ono to moc dlouho nevydrželo). Tak tamější elektrikáři říkali (přičemž normy pro elektrotechniku to nijak nepostihlo), že kdo nemá x tisíc na to, aby si zaplatil přístup (elektronický, pro tisk je potřeba ještě další platba), tak ten ty normy "nepotřebuje". Jinými slovy sami obhajovali stav, který je nutil platit za něco, co má být zdarma pro všechny (protože to všichni musejí - měli by - dodržovat).

Je to prostě "super" stav. Po už 7 letech předsedování SVJ bych mohl vyprávět. V elektrice se vyznám, tam si to ohlídám, ale teď řeším plyn, normy nepřístupné, revizák chce evidentní blbost (už třetí firma se tomu diví), ale já nemám jak oponovat (jednak se v tom nevyznám, ale hlavně nemám ty normy) a jediná možnost je soudní znalec (kteří jsou vytížení až do roku 2500). Takže je možnost utratil 100litrů na kravinu (což si nepochybně vybere většina SVJ) nebo se zkusit jít soudit s tím, že vy taháte za kratší konec provazu.

[trekker.dk]

Takže je možnost utratil 100litrů na kravinu (což si nepochybně vybere většina SVJ) nebo se zkusit jít soudit s tím, že vy taháte za kratší konec provazu.

No kdybyste to dotáhl k Ústavnímu soudu, možná by zabrala argumentace, že zákony vám nařizují dodržování norem, tudíž by se na normy mělo pohlížet jako na zákony a měly by být veřejné.

Piráti nějak prosadili stavební normy zdarma

Skutečně? To by k tomu ÚS mohli jít sami, když mají poslance ve sněmovně...

[Heron]

možná by zabrala argumentace, že zákony vám nařizují dodržování norem

Tato argumentace by právě nezabrala.

Normy jsou pouze doporučení a nikoliv (zákonná) povinnost. Problém je, že pokud něco neodpovídá normě, tak to třeba pojišťovny nepojistí (nebo ještě lépe, pojistí a následně neplní), nedostanete záruku na nějaké zařízení apod. Takže je to takový stav, kdy to všichni dodržují, protože to cítí jako povinnost, má to nesporné výhody (bezpečnostní), ale povinnost daná zákonem to není.

Tento stav mnoha subjektům nepochybně velmi vyhovuje (krom těch, kteří jsou na tom biti, jenže většina z nich si to ani neuvědomuje) a politická vůle to změnit je docela nulová.

[trekker.dk]

A co vyhláška 50? Ta se přímo odkazuje na několik norem.

[Heron]

Zkouška z vyhl. 50 se (pokud se něco nezměnilo) nedělá na fyz. osobu ale je platná jen po dobu, kdy je daný pracovník zaměstnancem určité firmy (jak je to u OSVČ nevím) a normy zajišťuje firma. Snad neříkám kraviny, ale když jsem se (2007, kdy jsem opouštěl tehdejšího zaměstnavalete, u kterého jsem měl §5) zajímal o vyhl. 50 na fyzickou osobu, tak to nebylo možné.

Zaškolení a zkoušku je povinna zajistit organizace. Obsah a délku zaškolení stanoví organizace s ohledem na charakter a rozsah činnosti, kterou mají pracovníci vykonávat. Dále je povinna zajistit nejméně jednou za tři roky jejich přezkoušení.

No, takže se nic nezměnilo. Zajišťuje organizace.

[trekker.dk]

No já našel tohle, ale ve stejné podobě to bylo i na jiných webech: https://www.tzb-info.cz/pravni-predpisy/vyhlaska-c-50-1978-sb-ceskeho-uradu-bezpecnosti-prace-a-ceskeho-banskeho-uradu-o-odborne-zpusobilosti-v-elektrotechnice a třeba u par. 3 odst. 1 se tam odkazují na ČSN 34 3108

Ale jinak - řekněme, že nemám žádné elektrotechnické vzdělání. Je teda někde psáno, že si nemůžu udělat vlastní elektroinstalaci? (Za předpokladu, že jsem ochoten riskovat, že od pojišťovny nic nedostanu, pokud to způsobí požár.)

[Blaazen]

V zásadě asi můžeš, ale třeba v novostavbě budeš nakonec stejně potřebovat štempl od revizního technika, jinak to nezkolauduješ. Ovšem od nového roku byly změny, aby to bylo byrokraticky jednodušší.

[smazáno]

tzn. goto http://www.abclinuxu.cz/blog/Max_Devaine/2018/4/oracle-dostavame-na-prdel-3/diskuse#129

potrebujes stempl od dementa, kteryho navic nastve ze sis to delal sam, takze bez "znamyho" mas smulu

[smazáno]

mimochodem ... kolik necha tak stat sbourat staveb za rok? to by bylo celkem zajimave cislo :)

[ChronicPain]

„Málo“. Dal jsem tomu pár minut a článek v Blesku, který cituje MF DNES (musel jsem dodatečně dohledat pod heslem „idnes 30 tisíc černých staveb“), je nejlepší, co jsem našel.

Díky kvalitní žurnalistické práci jsme se dozvěděli, že ročně přibyde na 30 tisíc černých staveb a nucená demolice čeká jen zlomek z nich. Tedy například polovinu, třeti, čtvrtinu, či devětadevadesát setin. Toto šokující odhalení vyvolalo na sociálních sítích bouři reakcí. „Mně se to nelíbí“, píše facebookový uživatel Josef Novák. Na něj reaguje uživatel Karel Maryňák se slovy: „Ty se mi taky nelíbíš, ty ksichte hnusnej.“. To Antonín Rovný volí slušnější formu a ptá se, jak je možné, že ve 21. první století nefunguje vymahatelnost práva. Zároveň dodává, že při současné rychlosti vydávání stavebních povolení možná mnozí investoři nemají jinou možnost.

Antonín Rovný (@antoninrovny):
Hmm, 21. první století a právo je stále nevymahatelné. Možná při současné rychlosti vydávání stavebních povolení mnozí investoři ale prostě nemají jinou možnost. #černéstavby #čechystán

A nyní infinite scrollem plynule přejděme k dalšímu článku.

Holky, pozor! Plácání na zadek zažívá boom

Kdo si myslí, že nechat si pořádně sešlehat zadek je okrajová úchylka, je na velkém omylu. Podle dostupných statistik, jejichž zdroj redakce nemá k dispozici, se této sexuální úchylce věnuje stále více lidí.

Nechat si pořádně naplácat na sedací partie, ať už rukou, druhou rukou, obouma rukama či něčím ostřejším nikdy nebylo populárnější. Alespoň tak tvrdí statistiky. Naše redaktorka si oblíbenost tohoto trendu zkusila ověřit ve svém okolí.

„Cože? Ne, nikdy.“, říká Alena A. a nechápavě kroutí hlavou. To Beáta B. okázale přiznává, že si nechává naplácat ráda a dobrovolně nejen o Velikonocích, aby jí prý nevyschla, a dodává: „Plácačka na mouchy by neměla chybět v žádné ložnici. Raději dvě, mají totiž tendenci se lámat, chych.“. Oproti tomu Cecílie C. volí zlatou střední cestu: „Vysloveně se tomu nebráním, někdy to může být příjemné zpestření, ale zpravidla tyto praktiky vynecháváme.“ (změnit před publikací první písmeno příjmení, takhle je to moc nápadné! a hlavně vypnout automatickou publikaci!)

A co vy, dámy? Ukájíte se rádi tou samou praktikou, kterou trestáte své děti, nebo volíte konzervativnější přístup plochého prkna?

A nyní infinite scrollem plynule přejděme k dalšímu článku.

Poslanci jednají o černých stavbách

[obecný odstavec]

[jedna nová informace]

[vykopírovat shrnující dva odstavce z předchozích článků... šak ve škole učili obrácenou pyramidu!!!]

A vypněte si, kurva, ten AdBlock. Kdybyste ho měli zaplý, vydělali bychom až dva haléře. Chceme svoje dva haléře! Tak tady si kupte předplatné na měsíc za pár stovek, šulini. Na každém webu, na který se náhodou někdy prokliknete. Jak budeme řešit opisování celých článků, jako to udělal Blesk výše, ještě nevíme. Citace tam je. Bude to chtít prolobbovat nějaký zákon. Ještě, že nás vlastní Andrej. Třeba něco vymyslí. Je potřeba zakleknout tyto adblockerské zmrdy. Šulini.

Vážení čtenáři, reportáž pro dnešek končí. Přejeme Vám příjemný večer. Na černé stavbě a s plácačkou na mouchy.

[Heron]

+1

[smazáno]

diky za analyzu :)

[Heron]

Tak ono nemusí jít jen o kouladaci. Pokud někdo neoprávněně zasahuje do VTZ (vyhrazené technické zařízení), což elektroinstalace nepochybně je, a potom to někoho zabije, tak má problém.

Takže ano, v zásadě nic nikomu nezakazuje si udělat vlastní instalaci, ale současně tím na sebe bere všechna rizika s tím spojená, včetně těch trestně právních.

Už jen ve vlastním zájmu by měl mít výchozí revizi a nechat si od revizáka orazítkovat, že zařízení je schopno bezpečného provozu.

A na to se nabalují další věci. Pokud si někdo dělá instalaci "samo domo" tak od toho nebude mít projekt a dělat výchozí revizi bez projektu se fakt všem hrozně chce, takže to stejně skončí na tom, že dotyčný stejně bude shánět projektanta, který mu zakreslí skutečný stav (což je vždy náročnější úkol, než naopak udělat instalaci dle připraveného projektu).

Takže nakonec se taková samodomo instalace dost prodraží. Navíc pravděpodobnost, že by laik bez elektrotechnického vzdělání udělal vše správně, je prakticky nulová, takže to pravděpodobně skončí rekonstrukcí části instalace. Což opět není levné.

Takže obecná odpověď je že mu to nic explicitně nezakazuje, ale není dobrý nápad to dělat.

[smazáno]

A zpatky do reality, v bytu co si pronajimam nejen ze nikde, ani v koupelne, neni RCD (cesky tusim proudovy chranic), ale v koupelne jsem v zasuvkach ani nemel zapojenou zem (to jsem si teda opravil). Kdyby se neco stalo, tak jsem si jisty, ze domaci z toho problemy nema (mate nekdo odkaz na opravdovy rozsudek v obdobne veci?).

[smazáno]

V tomto kontextu je dobre pripomenout, ze velke mnozstvi soudcu jsou byvalymi cleny ksc. Se soudem (obcanskopravni) mam v CR nastesti jen jednu praktickou zkusenost a presne tomu odpovida.

[trekker.dk]

AFAIK je běžná praxe, že revizák, který to měl zkontrolovat, řekne, že při kontrole to bylo v pořádku a že do toho někdo musel zasáhnout následně. A soud nemůže dokázat nikomu nic.

[smazáno]

Jj, ten produdovy chranic tam byl, kdyz jsem delal revizi (rika revizni technik, co nevi co to je proudovy chranic), soudce "hm, ano ano" ... jmenem republiky "vse bylo v poradku, zabil se sam".

[Heron]

(Pravidelná) Revize existujícího zařízení se vždy dělá dle norem platných v době výchozí revize. A v roce 1970 se RCD nevyžadovaly a běžně se instalovala sít TN-C.

(To, že z dnešního pohledu je všechno špatně je jasné, ale chtít po vlastnících kompletní rekonstrukci je nereálné a náklady astronomické.)

Kdyby se neco stalo, tak jsem si jisty, ze domaci z toho problemy nema.

Zákony vykládá soud a ten určuje míru zavinění konkrétní osoby. Nejsem si jist, zda pronajímatel má povinnost provádět pravidelnou revizi (podle někoho ano, podle někoho ne).

[trekker.dk]

A v roce 1970 se RCD nevyžadovaly a běžně se instalovala sít TN-C.

Já už mám taky dobrou deformaci, čtu "nebyla zapojená zem", chápu "kolík ve vzduchu".

[smazáno]

To chapes spravne.

[Blaazen]

Dřív se od krabice k zásuvce táhly jen dva dráty, černý a modrý. A modrý se zapojil na kolík i na pravou díru. Takhle jsem se to ještě učil na průmce v dílnách. V roce 1995 nebo 1996 přišla změna a musí se táhnout tři dráty už ve zdi. Žlutozelený na kolík a modrý na pravou.

[smazáno]

Tak borec co delal tenhle byt ty zmeny asi pochopil tak, ze se ten zlutozeleny nemusi zapojovat nebo nevim ... proste na to zapomel a nikdo to pak netestoval (az ja poctivym cinskym testerem), stane se.

Mimochodem, pokud nemas zem na tretim dratu, tak ti samozrejme nebude fungovat RCD v jednom (docela dulezitym) pripade.

[Heron]

No já jsem taky neobhajoval nezapojený PEN. To je problém a byl by to i problém v roce 1970. Pokud luv uvádí, že je to po rekonstrukci (předpokládejme max pár let za zpět), tak je to samozřejmě celé špatně (zřejmě tedy i řemeslně odvedené) a myslím, že pan majitel může mít hodně velký problém. Ale vinu určuje soud a to se zase dostáváme někam úplně jinam no. Ostatně rozsudek se dá ovlivnit i výběrem vhodného soudního znalce, revizními posudky apod.

Jak někdo někde napsal, k soudu se nechodí pro spravedlnost ale pro rozsudek.

[smazáno]

byt "po rekonstrukci" :)

[smazáno]

Nejsem si jist, zda pronajímatel má povinnost provádět pravidelnou revizi (podle někoho ano, podle někoho ne).

Kdo myslis ze tam tu elektroinstalaci zbastlit :).

[trekker.dk]

Takže ano, v zásadě nic nikomu nezakazuje si udělat vlastní instalaci, ale současně tím na sebe bere všechna rizika s tím spojená, včetně těch trestně právních.

No jasně, ale to platí ve všem - když nechám špatně zabržděné auto v kopci, tak taky nesu odpovědnost za to, když se rozjede.

[pc2005]

Zkouška z vyhl. 50 se (pokud se něco nezměnilo) nedělá na fyz. osobu ale je platná jen po dobu, kdy je daný pracovník zaměstnancem určité firmy

Divný my jsme dělali na střední nějakou vyhlášku (asi 50 co jinýho) jako celý ročník (maník nám prakticky diktoval odpovědi ). Ještě jsem si dělal srandu, že je jen do 1000V přitom jsem si už tak rok předtím hrál s teslákem na >100kV (myslím že až 6cm blesky).

[Heron]

A tu zkoušku jste dělali na konci studia nebo v průběhu např. před tím, než vás pustili do dílen, kde jste pracovali na zařízení pod napětím? (A zřejmě tedy pod dozorem.) Jestli ono to spíš není pro ochranu té školy s tím, že papír na to máte a škola je (v případě nehody) chráněná.

maník nám prakticky diktoval odpovědi

Njn. To stejné je třeba "školení" BOZP a PO ve firmách. Pro forma. Veškeré školení se sestává ze závěrečné zkoušky a předání certifikátu o školení.

jsem si už tak rok předtím hrál s teslákem na >100kV (myslím že až 6cm blesky)

Tak na to snad ani žádná norma neexistuje . Teslák žádnou zkušebnou nikdy neprojde už jen z hlediska elmag rušení na všech pásmech. Takže tady je to vyloženě jen na vlastní pěst.

Pochopitelně kdyby se chtělo, tak to jde udělat i legálně (tj Faradayova klec, vyhrazený prostor, vyškolený personál, zajištění osobní bezpečnosti apod.) ale afaik to má jen jedna škola v Česku.

[pc2005]

To bylo někde v třeťáku možná čtvrťaku. Dílny jsme měli už od prváku a tam to bylo na základě poučení (stejně jsem si šáhnul mezi fáze, když jsem demontoval filtr z 3f měniče ).

Takže tady je to vyloženě jen na vlastní pěst.

Ja ho přinesl i do školy, jednička zadarmo .

[smazáno]

maník nám prakticky diktoval odpovědi

Ty se tomu smejes, ale ty dementi by to jinak nedali ... a od tehle dementu pak musis mit ten stempl.

[tutanchamoon]

revizny technik a absolvent vyhlasky je rozdiel v skuskaxh ...

[smazáno]

... ale praxe stejna

[VSi]

Ono se tam nic nezměnilo už desítky let (poslední změna 1982!), takže podle platného změní např.:

§ 14 (2) Ke zkouškám nebo přezkoušení pracovníků přizve organizace zástupce základní organizace Revolučního odborového hnutí, který má při zkouškách nebo přezkoušení podle § 6 až 8, 10 a 11 oprávnění člena zkušební komise.

A celkově ten koncept vůbec neodpovídá dnešní realitě fungování firem a zejména OSVČ, se kterými se moc nepočítá, ač to je dnes možná většina elektrikářů. Takže se ustanovení vyhlášky použijí "přiměřeně", podle úvahy komise. Vyhláška např. počítá s tím, že osvědčení vydává organizace, kde je pracovník zaměstnán, což neodpovídá dnešní realitě. Zkoušky taky dnes organizuje kde kdo a podmínky jsou velmi výrazně odlišné. Takže je to celé takové na vodě, ale dnešní stav vyhovuje tolika lidem a je tak usazený a vlastně ničemu nevadí, že jakékoliv pokusy o novelizaci zkrachovaly.

[miro]

ÚS už na dostupnost norem názor má. Musel by se změnit zákon.

[Grunt]

No já ty prachy neplatím, ale vedoucí pracovníci to holt tak berou. Primární motivace pro stavbu vlastního rackového serveru krom ceny bylo právě taky to že bych znal každý šroub, mohl si to přizpůsobit a nešlo by o žádné proprietární řešení. Ostatně Maxovi to tu bylo navrhnuto (i když jde o něco jiného) několikrát. Ale bohužel já jsem malý pán a předpokládám že Max je v pozici docela nejiné.

[Max]

Nějak nerozumím, co to znamená postavit vlastní rackový server? To jako z nějakých desktop komponent? Nebo něco poskládanýho od Supermicra? Nebo tu panuje nějaké přesvědčení, že používáme nějaký speciální hw? My jedeme vesměs HP servery, skoro všechno máme nad DL380G8/9/10. A to i pro ten Oracle.
Zdar Max

[pc2005]

Nebo tu panuje nějaké přesvědčení, že používáme nějaký speciální hw?

V serverech se nevyznám, ale bral jsem to pesimisticky, že se určitě nasáčkujou i do HW. Jinak Oracle koupil Sun a ten si vlastní HW vyráběl.

[Max]

Asi myslíš servery se SPARC cpu? Jinak Oracle Exadata je včetně hw, dodají kompletně out-of-box funkční rack s Oraclem.
Zdar Max

[pc2005]

Obecný hw = HW co není vendor locknutý na oracle nebo jinou korporaci, u které hrozí vendor lock-in.

Sysadmin = obecně lidi co nahradí vývoj, support apod. OSS

OSS = něco z čeho se nemusí platit licence na jádro.

A jak by to vyřešilo, že všechno, co se u nás vyvíjí je silně vázáno na Oracle?

Proto se ptám, zda nebude levnější se z Oracle vyvázat?

[Max]

HW máme obyč, OSS je nasazen na cca 50% serverech. Půlka serverů je OSS, půlka Windows, případně mix (Oracle Linux + OracleDB apod.)
Zdar Max

[Grunt]

No tak nějak. Já kdysi dávno v historii dostal nějakou potvoru do racku a když jsem viděl cenu, tak jsem se na to díval, zkoumal to ze všech stran kde to má zabudované to zlaté vejce (HW byl vcelku standardní akorát to prostě bylo 1U nebo 2U což ani nevím jestli jde taková bedna vůbec standardně koupit). Přišel jsem na to že, nemá. Prostě takhle se prodávají „hotová řešení“. No měl jsem chuť to tak za desetinové náklady implementovat celé jakožto „garážové řešení“ abych dokázal že tolik to nemůže stát. Za tu dobu jsem samozřejmě zomoudřel a vykašlal se na to, ale jak se tak dívám…no prostě kdyby se někomu někde válel přebytečný plonkovní meloun (nebo radši rovnou dva) pro který by se jaksi nenašlo využití, kontakt znáte. Na blbosti mě vždy užije a zajímavý HW si vždy rád osahám.

[Grunt]

Dík, tak nějak jsem si to představoval.

[bigBRAMBOR]

tak tohle neznám

Sice jsme měli licenci na CPU a vše okolo, ale neměli jsme ve smlouvě, že může mít k db přístup i třetí strana. A tou třetí stranou je myšlena i dceřinka, i sestra. Jo, pěkný výjeb. Kdo to nezná a nakoupí bez podobných jakoby textíků, tak má Oracle další páku.

[Vantomas]

Tady u toho by mě zajímalo, zda je ošetřeno jen pokud se dceřinka připojuje přímo do DB nebo je to i ošetřeno tak, že se připojuje jen do vaši aplikace, která v pozadí používá onu DB.

[Max]

Co jsem se zatím potkal s licenčníma politikama, tak v tomto rozdíl nikdy nebyl (zda se něco připojuje napřímo do db, nebo přes nějakou app).
Zdar Max

[〹]

Pokud komunikuji s web serverem, který využívá Oracle Database, znamená to, že si musím koupit licensi?

[Max]

Ano, takto to má každý vendor. Schování více uživatelů za jeden jakoby účet/server nejde, nějak se tomuto říká, ale teď si na ten termín nemohu vzpomenout. Licencují se vždy úplně ti koncoví klienti. Když máš tedy db, před ním aplikační server pro hafec uživatelů a spojení mezi aplikáčem a db je jen přes jednoho uživatele, tak si opravdu s licencí pro jednoho usera nevystačíš.
Zdar Max

[Heron]

Svět komerčních produktů mě nikdy nepřestane fascinovat. Takže pokud by někdo udělal na Oracle DB webovou stránku, na kterou se potenciálně může připojit kdokoliv ze světa, tak bude potřebovat miliardy licencí?

To, že se na db připojuje jeden uživatel (aplikační), je přece naprosto normální a standardní.

[Max]

Ne, bude potřebovat licenci na CPU (+ možná něco, nevím). Některé produkty podporují licence pojmenované jako external connector for web. Kdy si člověk koupí base licenci + k ní tohle a smí používat db jen pro ten web. Případně kombinovat a co já vím.
Netuším, jak moc to má Oracle rozkouskované, resp. nemá to moc přehledné, blíží se s tím k tomu MS.
Existují třeba integrátoři, kteří využívají OracleDB, Oracle pak dává licenci na tuto db za malý peníz + k tomu další benefity, ale zase, db je vázána k tomu sw toho integrátora, takže nelze použít k něčemu jinému.
Takto máme OracleDB k DMS systému a další k SAPu, obě jsou vázána pro ty konkrétní aplikace a k ničemu jinému se použít nesmějí.
Zdar Max

[xvasek]

U Microsoftu je k tomu speciální balík "web connector" za nepěknou cenu, pak už další licence pro jednotlivé anonymní webové uživatele nepotřebuješ. Celkem vtipné je, že toto musíš řešit i pro OS pod tím serverem, tzn. i když máš licence "per processor", tak pro uživatele potřebuješ pořád "aspoň" licenci OS. Jak je to teď s MSSQL na linuxu netuším, ale v podstatě to vypadalo jako zajímavý licenční hack - provozovat MSSQL pod linuxem bych z toho důvodu doporučil i firmám, které jinak linuxové servery nemají.

Oracle tuším politiku "per processor" s nekonečným počtem uživatelů vůbec nemá.

[Heron]

Fascinující. O kolik věcí jsme v OSS světě ochuzeni.

Fakt nechápu, že na toto někdo dobrovolně přistoupí.

[ehm]

Třeba si představí, že někdo ty programátory a další IT experty živit musí a ti jsou ohodnoceni jinak než uklízečka

[xvasek]

Ono je to v praxi ještě horší, protože pokud přijdeš s nějakým open source systémem "zdarma", tak budíš dojem garážníka, který netuší, kde je sever. Je lepší nakouřit tam aspoň RedHat server, protože jinak je to trapné.

[Heron]

Kdysi to tak bylo, že zakoši vyžadovali RHEL, ale dneska už není nikomu divné, že je tam centos nebo debian. Dokonce několik zákazníků, kteří původně chtěli RHEL a dostali jej, potom požádalo o přechod na CentOS, protože se jim nechtělo platit licence. Jsem to kdysi dělal i na dálku, změna yum.repos.d na centosácký repa, update, reboot, v pohodě.

[xvasek]

Tak to máš dobrý, je to migruju z RedHatu na Debian až při prvním upgrade, kdy se mimochodem zjistí, že by se za ten RH měla platit ročně podpora. Debian samozřejmě tlačím kde to jde, u malých a soukromě vlastněných firem existuje většinou nějaká rozumná diskuse, u velkých ne, ti většinou přímo vyžadují komerční řešení.

[Max]

Debian má nevýhodu v délce supportu. Začínám z toho důvodu upřednostňovat CentOS.
Zdar Max

[Heron]

Otázkou je, zda je to nevýhoda. Jeden zakoš provozuje server z roku 2009 (CentOS 5), už několik let se mu říká, že by to fakt chtělo vyměnit, CentOS 5 už je mezitím EOL a letos si zákazník stěžuje, že na tom serveru nefunguje TLS 1.2. No, nefunguje a fungovat nebude.

Navíc Debian officiálně podporuje upgrade na vyšší verzi a většinou s tím nebývá problém (a pokud ano, je dobré jej vyřešit a do budoucna se tomu vyhnout). Na dobře připraveném serveru není update z old-stable na stable problém.

[Max]

Samozřejmě souhlasím, že ta délka má i své stinné stránky. Na něco se to ale hodí dobře.
Zdar Max

[xvasek]

Mně zase v centosu/RH vždycky naštve, jak mi z něj vyhážou nějaké balíky, nebo že tam toho spousta chybí. Freetds, perl-xml-simple, dokonce myslím i joe (!), perl konvertor z excelu, co nevím jak se jmenuje, atd. (Nemusíte to hledat, možná si to pletu nebo mi to vyházeli ze SUSE - oproti tomu nevidím v tomto moc rozdíl.)

[Michal Kubeček]

Dokonce několik zákazníků, kteří původně chtěli RHEL a dostali jej, potom požádalo o přechod na CentOS, protože se jim nechtělo platit licence.

U RHEL se platí za licence?

[Max]

To je dáno historickým vývojem. V roce 1993 znáš jen Windows. V České Republice se rozmáhá používání FoxPro, protože je to na db práci easy. Po pár letech má Česká Republika přezdívku Foxland. V roce 2004 už jsou dbf soubory opravdu velké a práce s nimi silně nepohodlná a dochází k lockům. MS nemá co se týče stability dobrou pověst. Oracle vypadá jako dobrá volba. MS usnadňuje přechod z DOSu na windows pomocí Visual FoxPro. Jako dobrá volba vypadá přechod z FP na VFP a z dbf na Oracle.
Všechno šlape na mnohem lepší úrovni, vypadá to dobře. Jako hlavní FS slouží Netware.
A takto začíná éra tlustého klienta proti Oracle db.
Změnit takto rozjetý vlak je pak už dost těžké.
Zdar Max

[trekker.dk]

Změnit takto rozjetý vlak je pak už dost těžké.

Já asi nemám to správné obchodní myšlení. V téhle situaci, kdyby přede mě Oracle předhodil tenhle drahý bastl, k tomu podmínky, jak to smím provozovat, to všechno s jejich customer-unfriendly přístupem, tak bych se na ně vysral už jenom proto, abych si nepřipadal jako debil.

[Max]

Mno, z hlediska podpory(obecně) si nemohu s porovnáním s OSS stěžovat. Člověk si toho hodně dogooglí a hodně toho má Oracle popsáno v jejich uzavřené KB pro platící zákazníky. Vesměs všechno ohledně správy, instalací, rozcházení na nepodporovaných OS apod., to všechno mám z netu. Školeních mám za sebou dvě, ale to v podobě předání řešení/instalace, tzn. v rámci předávací dokumentace + hodinky/dvou na vysvětlení základních věcí.
Zdar Max

[xkucf03]

hodně toho má Oracle popsáno v jejich uzavřené KB pro platící zákazníky

Připomnělo mi: Master Foo and the MCSE

[Heron]

Je to váš boj. Já bych v tomhle dělat nechtěl. Já mám štěstí na to, že na produkci máme jen OSS, o to, na čem běží vmka (vmware) už se nestarám. Licence a podobný kraviny (subscriptions nebo jak se to na RH jmenuje), jsem řešil naposledy před 5 lety a nikdy více.

Pokaždé, když jsme sáhli na komerční soft, tak jsme se spálili. Pokaždé. Veeam, Zimbra, Yosemite, ostatně v určitém čase i ten VMware. Našlo by se toho víc. V určité chvíli své drápky natahovalo i Cisco. O MS nemluvě. V podstatě furt ta stejná parta. Oracle jsme se nějakým zázrakem vyhnuli.

[xkucf03]

V roce 2004 už jsou dbf soubory opravdu velké a práce s nimi silně nepohodlná a dochází k lockům. MS nemá co se týče stability dobrou pověst. Oracle vypadá jako dobrá volba. MS usnadňuje přechod z DOSu na windows pomocí Visual FoxPro. Jako dobrá volba vypadá přechod z FP na VFP a z dbf na Oracle

Když přejdeš z extáze na herák, tak ti taky chvíli bude dobře. S proprietárním softwarem je to podobné.

[〹]

Nespojoval bych proprietární software a vendor lock-in. Kdyby bylo možné přemigrovat data do jiné (levnější/FOSS) databáze implementující stejné rozhraní, byť třeba za cenu nějakého výkonnostního propadu, ten problém by nebyl ani zdaleka tak palčivý.

Ale co. Osobně jsem rád, že Oracle má takto šikovně pořešené dojné krávy a bude mít z čeho financovat vývoj Javy.

[xkucf03]

Ano, je třeba se na to dívat z té lepší stránky :-)

Ostatně psal jsem tu už před lety… A vlastně není moc důvod se nervovat s tím, jak mají dvě cizí firmy mezi sebou nastavené vztahy a že jedna obírá druhou.

[snajpa]

Protoze ten je tak strasne drahej, ze je potreba, aby Larrymu zbyvalo na nejaky ten ostrov. Jojo, urcite to dela kvuli tomu, aby mohl investovat miliardy do Javy, do jazyka, ktery se da urcite rozvinout uz jenom silenymi investicemi. Osobne jsem rad, ze nemusim delat v prostredi, kde lidi premysli, jak Ty, nakoho reaguju.

[limit_false]

Když přejdeš z extáze na herák, tak ti taky chvíli bude dobře. S proprietárním softwarem je to podobné

Prvne, tohle prirovnani je neuveritelne hloupe. Caste brani MDMA neni dobry napad, ma napr. za nasledek "vycerpani" serotoninu (a efekty podobne depresi), mozny serotoninovy syndrom (v kombinaci napr. s SSRI), ne fyzickou zavislost. Vetsina lidi, co prejde na heroin, presla z opioidu na predpis (protoze je to levnejsi/jednodussi nez ziskavat dalsi predpis na "legalni" opioidy). Mechanismus akce je taky velmi rozdilny, MDMA cili na serotonin, opioidy (ty ktere, vyvolavaji zavislost), na mju a delta opioid receptor (ty zpusobuji "feel good" efekt; co se moc nevi verejne, je, ze agonisti mju receptoru taky "docasne leci depresi", coz je duvod, proc se na to lidi namotaji - ze si "samoleci depresi"). Z opioidu ziskate fyzickou zavislost velmi, rychle, i po 3 tydnech uzivani nekolikrat denne. Abstinencni priznaky od opiatu vam aktivuji vsechny receptory bolesti, takze zjistite, ze vas boli i veci, ktere jste netusili, ze vas muzou bolet, napr. pocit, ze se vam delaji diry v kostni dreni.

Technicky lze brat heroin dlouhodobe "bez vytvoreni fyzicke zavislosti", pokud si ho dat dejme tomu 1x po 4 dny a pak si dejme tomu 4 dny nechate na to, aby se "zresetovala tolerance" (to je duvod, proc ze zacatku se lidem zda, ze nejsou zavisli a pak to zjisti az pozde). Stejne budete citit slabe abstinencni priznaky (podobne chripce, hot/cold flashes, prujem, nechutenstvi...) ale to je nic oproti plnym abstinencnim priznakum. (Proto i prekupnici "bileho masa" a ve veznicich s "teroristy" se lidi snazi(li) udelat sve vezne zavisle na opioidech).

Jeden z velmi znamych bezne volne prodejnych leku proti hnacce - Imodium (Loperamid) - je taky opioid. Duvod, proc se nezneuziva, je, ze neprochazi barierou mezi mozkem a krvi - tj. nezpusobuje "feel good efekty" (ale zrejme dlouhym uzivanim byste si zpusobili zavislost, ma vsechny ostatni znaky opioidu, coz je vlastne duvod, proc se pouziva proti hnacce). Jsou opioidy, ktere nevytvari zavislost, naopak ji potlacuji, nebo lze nimi odvratit predavkovani opioidy, a taky se pouzivaji pri alkoholizmu (Naloxon, Naltrexon; mju a delta opioid receptor antagonisti)

Zpatky k databazim

A zpatky k databazim - jaky je duvod kupovat Oracle misto treba Postgresu se supportem (nebo jine DB), pokud jiz nejste zasazeni vendor-lock-inem? Vykon (kdyz tak nejaka studie)? Nebo nejaka featura, ktere jine DB nemaji?

[limit_false]

Kdyz uz chcete Oracle prirovanat k opioidum, tak k buprenorfinu: pouziva se jako substitucni lecba, ale je to sam opioid. Nezpusobuje "high", je to mju a delta agonista, kappa antagnostista (proto ma antidepresivni ucinky), ale jeho efekt je dlouhotrvajici, coz znamena, ze i abstak je dlouhotrvajici (muze byt mesic i vic).

Buprenorfin se samidorfanem (mju a delta antagonista) se zkousel jako antidepresivum kvuli kappa antagonismu s myslenkou, ze buprenorfin bude pusobit jako antidepresivum a samidorfan bude blokovat navykovost. Dostalo se to do phase 3 clinical trials, ale kdyz se zacnou mixovat ruzny agonisti/antagonisti opioid receptoru, nema to tak jednoduche a jednoznacne vysledky: https://en.wikipedia.org/wiki/Buprenorphine/samidorphan

Tj. mate Oracle jako substitucni lecbu, z ktere je jeste horsi abstak :)

[xkucf03]

Díky za přednášku :-) Radši se nebudu ptát, proč nosíš tyhle znalosti v hlavě.

Tj. mate Oracle jako substitucni lecbu, z ktere je jeste horsi abstak :)

Ano, to jsem se tím snažil říct, i když příklady konkrétních drog asi nebyly nejvhodněji zvolené.

[limit_false]

Kdybych nebyl programator, asi bych delal farmakologii :) Clovek se po cteni stovek paperu spoustu nauci. Napr. 2018 unorove cislo Psychopharmacology bylo venovano efektu psychedelik na choroby jako deprese (cele clanky jsou kdyz tak na sci-hub). Jedna vzacna shoda vyzkumu poslednich let je, ze ketamin funguje jako lek na treatment-resistent depression, ted se jenom dohaduji, jak dlouho to funguje, jak podavat a jak prodlouzit ucinek.

Krome tradicnich zahad - jak skutecne funguje LSD a treba salvinorin A mi prijdou opioidy jako strasne zaujimava trida latek - kdyby nemeli ten extremne vysoky potencial navykovosti, tak by dokazali lecit spoustu veci. Jedna slibna vec byl taky opioid, mju, delta a kappa antagonista (CERC-501), ktery mel mit antidepresivni efekt a zaroven nemit navykovost, ale zda se, ze to nedopadlo (kdesi jsem cetl - neovereno - ze se tak zprisnil vyzkum novych latek na mentalni choroby, ze se to uz farmaceutickym firmam nevyplaci, a davaji se penize na ruzne karcinomy, protoze je to momentalne popularni (a tudiz ziskove).

Zrovna treba ten divny salvinorin A, kde trvalo desitky let, nez zjistili jak to vubec funguje a na jake receptory v tak malych mnozstvich, tak se zjistilo, ze je to taky agonista kappa opioid receptoru (coz se prisuzuje neprijemnym ucinkum, i kdyz vetsina lidi to kouri, misto zvykani, jak byla ta puvodni Mazatecka metoda, ktera ma za efekt, ze to nema raketovy start a raketovy stop). Tramadol jako dalsi divny opioid funguje i jako SSRI. Tianeptin - antidepresivum - neni opioid, ale po 50 letech se zjistil jeho agonizmus na mju receptor (paradoxne je to serotonin reuptake enhancer, opak SSRI - coz ukazuje na fakt, ze jednoduche cileni na serotonin a dopamin je velmi zjednodusujici). Kappa receptor samotny ma svoji vlastni konferenci (ilustrace jak slozity je jeden receptor). Kdysi jsem si o opioidech a a(nta)gonistech oopiod receptoru myslel, ze je to vsechno jako heroin, pritom ta trida ma asi nejrozmanitejsi ucinky.

[jmeno]

oracle neznam, ale ketamin doporucuju ;)
da se uzivat spatne, ale to koneckoncu i voda, kdyz ji vypijes 8l naraz...
dik za tip na papery, mrknu

[smazáno]

a ja dekuju za odkaz na sci hub :)

[smazáno]

A postgres k mdma sedi? :P

Ze zacatku poradny "high" (jake je postgres super)... ale pak prijde vystrizliveni, kdyz objevis, ze vlastne ani jednoduchy pg_dump nefunguje spravne (s extensions)

[limit_false]

Ja sem Postgres neprirovnaval nikdy k zadnym drogam :) Pouzival jsem Postgres i na obrovske databazy (radove stovky GB), i s vecmi jako procedury, ale nikdy jsem od nej nepozadoval okamzity vykon. Z hlediska featur i rychlosti mi postacoval, ale vetsinou jsem nemusel resit okamzity vykon (ladit na milisekundy, i kdyz doted mi prijde cteni execution plan Postgresu ne vzdy jednoduche).

S jakymi extensions ma pg_dump problem?

[smazáno]

https://dba.stackexchange.com/questions/84798/how-to-make-pg-dump-skip-extension

[Max]

Já postgres neměl nikdy v plné produkci, jen občas na hraní. Heron zná Postgres, ale nezná Oracle. Chtělo by to někoho, kdo zná obě strany a mohl by nám to objektivně vysvětlit.
Další věcí je, že ti třeba Heron může říci, že tyhle fce prostě nepotřebuje, protože je správné to řešit v rámci aplikace, né v rámci db. S tím se dá souhlasit, ale pokud už je někdo ve špatně rozjetém vlaku, je každá změna těžká. Případně mohou existovat scénáře, které nikoho nenapadnou a je to použitelné.

Každopádně za Oracle, co vím, mohu zmínit :

• RAC (více serverů se stejným úložištěm / jednou db), to postgress neumí, takže kdo potřebuje extrémně škálovat výkon v rámci jedné db, tak Oracle RAC je na tom podstatně líp
• nevím, zda má postgres možnost inkrementálních záloh / podporu CBT pro zálohy
• paralelní export / import db + možnost právě binárního export/importu (mnohem rychlejší)
• oracle má podporu snapshotů, kdy lze díky dostatečně velké flash recovery area vytvářet snapshoty a vracet se v čase bez šachování s obnovou/restore/transakčními logy, vhodné na nějaké backup /standby db, nebo třeba před upgradem struktury db kvůli nějaké nové app, co jí používá (aplikace nefunguje/něco selže, vrátíme se zpět).
• flashback na úrovni db, tabulky i transakcí
• In-memory cachování
• virtualizace databází díky Plugable DB featurce / multitenant
• pak nevím, na jaké úrovni je Postgres s šifrováním, ACL na úrovni sloupečků, nebo i řádků
• taktéž nevím, jak je na tom Postgres s úrovní auditování přístupů do konkrétní části db
• taktéž nevím, jak je na tom podpora komprese
• Podpora NFS (dNFS) 4.1 přímo v OracleDB
• featurky v rámci ASM (replikace/online move datafile a další věci v režii/pod kontrolou db), možnost mít i transakční soubory v ASM a další věci

Nějaký feature list Oracle je zde : Feature Availability by Edition

Jenomže to jsou všechno featurky z admin pohledu, pohled ze strany vývojáře a výkonu mám nulový.
Každopádně z admin pohledu mohu říci, že Oracle má šíleně možností z hlediska správy a jde nastavit na milion způsobů / něco na styl "umí uvařit i kávu".
Zdar Max

[limit_false]

Diky za prehled.

[Heron]

ale pokud už je někdo ve špatně rozjetém vlaku

Tak by měl pracovat na tom ten vlak co nejdřív bezpečně zastavit a nikoliv ještě přikládat pod kotlem.

RAC (více serverů se stejným úložištěm / jednou db)

Ano a jak skvěle to může dopadnout jsme viděli u Alzy a nejen tam. Tohle řešení jsem nikdy nepochopil (tváříme se, že jsme vyřešili SPOF na straně DB, protože jich máme víc a nevidíme SPOF na straně toho jednoho úložiště).

Navíc z mé zkušenosti (která nic neznamená), úzké hrdlo je vždy na straně rychlosti úložiště a nikoliv CPU. Takže pokud jeden DB server nestačí, tak dva DB servery nad stejnými disky už tuplem nestačí.

Pochopitelně pokud někdo do DB nastrká hromadů CPU náročných procedur (nic proti tomu), tak více serverů může pomoci.

nevím, zda má postgres možnost inkrementálních záloh / podporu CBT pro zálohy

Klasické binární logy, když se to dobře nastaví, tak failover může být v řádu sekund.

paralelní export / import db + možnost právě binárního export/importu (mnohem rychlejší)

Nevím co tím konkrétně myslíš, ale PG se umí uvést do stavu, kdy můžeš standardními nástroji vzít ten datový adresář a překopírovat jinam. DB mezitím běží dál. Existuje i nástroj pg_basebackup, který tohle umí i po síti, (pokud se někdo nechce zabývat rsyncem). Ten dotáhne i binární logy a replika je na světě. Je to tak rychlé, jak jen disky a sít dovolí.

oracle má podporu snapshotů, kdy lze díky dostatečně velké flash recovery area vytvářet snapshoty a vracet se v čase bez šachování s obnovou/restore/transakčními logy, vhodné na nějaké backup /standby db, nebo třeba před upgradem struktury db kvůli nějaké nové app, co jí používá (aplikace nefunguje/něco selže, vrátíme se zpět).

PG má transakace i na změnu schématu, takže před vytvořením nové table si lze udělat savepoint.

In-memory cachování

Řeší OS.

virtualizace databází díky Plugable DB featurce / multitenant

Co to je?

pak nevím, na jaké úrovni je Postgres s šifrováním, ACL na úrovni sloupečků, nebo i řádků

Mluví se o tom, ale tohle jde mimo mě, nesleduji to.

taktéž nevím, jak je na tom Postgres s úrovní auditování přístupů do konkrétní části db

Nevím co to je "konkrétní část db", ale nezní to jako něco z konceptu normálních forem. PG může logovat kde co všechno, klidně úplně každý dotaz, ale nevím, zda je to odpověď na dotaz.

taktéž nevím, jak je na tom podpora komprese

Obecně řeší FS. PG transparentně komprimuje rychlou kompresí (LZ4) všechny fieldy s velikostí nad určitý limit (tuším 2kB, ale nechci kecat).

Podpora NFS (dNFS) 4.1 přímo v OracleDB

Super Řeší OS.

---

Hele, jako fakt tady porovnáváme OSS produkt s produktem v cenách začínajících na milionu za jednu instanci*? Jinak, návrh PostgreSQL je úplně jiný. PG je (podle mého názoru) skvělou ukázkou unixového návrhu appky. Neřeší cachování (mimo shared_buffers), protože se spoléhá na to, že funguje iocache v OS. Proč cache implementovat dvakrát? Neřeší NFS ani žádné CBT, protože se spoléhá na to, že FS na kterém běží, je dostatečně příčetný. Uživatelé DB dokonce mohou být přímo systémoví uživatelé a pg je ověří přes vlastníka procesu. Jedno připojení je jeden proces (tj neřeší to žádný vlastní thread pool), spoléhá se na funkční implementaci scheduleru v OS. Komunikace mezi procesy pomocí standardního IPC (shared memory). Atd. Mě se tento přístup velmi líbí, protože pg řeší jen to, co řešit má (tj. starost o data) a všechno ostatní už je naimplementované v OS.

*) Tohle je totiž dost podstatné. On ten OSS produkt nemusí umět totéž co nějaký komerční, ale pokud vezmu ty peníze za licence a použiji je na něco jiného (třeba HW), tak se v určitých parametrech a vlastnostech mohu dostat nad ten komerční produkt. Tohle jsem viděl několikrát. Někdo obhajoval nákup komerčního produktu za určitou cenu ale moc se nezamýšlel nad tím, že kdyby se ty peníze strčili jinam (hw, čas na implementaci něčeho, čas na otestování jiných produktů), tak by z toho vyšlo lepší řešení.

[Max]

RAC - my jsme příkladem těch náročnějších procedur, takže CPU na db je dost vytížený. Existují přímo i produkty, které se skoro tváří jako db only. Buď to tak firmy navrhují a staví, nebo to sám dělá i Oracle, viz Oracle APEX prostředí.
Každopádně není to jen o výkonu, ale i o odstávkách, kdy v případě RAC lze dělat běžnou údržbu OS/hardware s žádnou, nebo minimální odstávkou (pokud se nepodaří přepojit všechny sessions na druhý node, tak je to vykopne a musí se app/klient znovu přihlásit, čas nula nula nic).

nevím, zda má postgres možnost inkrementálních záloh / podporu CBT pro zálohy
- Klasické binární logy, když se to dobře nastaví, tak failover může být v řádu sekund.
mluvím o zálohách db jako takových, né o transakčních logách. Tzn. udělá se full binární dump db a poté se jede inkrementální dump. Transakční logy se zálohují samozřejmě také, ale inkrementální dump db má výhodu, že je rychlejší pro obnovu, než dělat obnovu z tisíců transakčních souborů. Tzn. postup je pak takový, že se obnový db dump s nějakou inkrementální zálohou a pak už se dohraje jen hrstka transakčních logů do požadovaného času. V tomto bodě tedy neřeším failover, ale zálohu jako takovou a případnou obnovu (pokud se chci dostat k datům z nějakého času).

Paralelní import/export znamená, že export/import běží paralelně v několika vláknech, což v jistých situacích může značně urychlit celý proces.
Rozdíl mezi zálohou formou rmanu a expdp je ten, že rman dělá full binární dump, který je rychlý, ale lze obnovit jen do stejné verze db a nelze z něj vycucnout třeba jednu tabulku, ale dokáže se na něj navázat transakčníma logama. expdp dělá pak dump na úrovni db, kdy lze vytáhnout během chvilky jakoukoli tabulku, či něco jiného + lze obnovit do rozdílné verze db, nelze použít pro standby apod., protože nenavážeš s transakčníma logama. A právě expd/impdp podporuje export/import ve více vláknech.

In-memory cachování
Řeší OS.

Nemůže řešit OS, se na tu fci podívej.

NFS - samozřejmě máš u Oracle na výběr, zda použiješ implementaci NFS v systému, nebo implementaci NFS v db. Ta v DB má v určitých případech výkonnostní výhody (je to optimalizováno pro konkrétní účel a s tím spojené i cachování). Jedná se o optimalizaci, která nějaký výkon může přinést, ale někdo opět může namítnout, že je to zbytečné a stačí ta, co je součástí OS.

Plugable databáze jsou db v kontejnerech. Výhodou je menší nárok na hw, protože některé věci sdílejí. Má to i pár dalších výhod, pro některá nasazení celkem zajímavé.

Jinak samozřejmě absolutně netuším, jaký performance dokáže třeba Oracle proti Postgresu vytočit. A jak už jsem řekl, je to jen pár věcí z admin pohledu, spíš bych řekl kapka v moři toho, co asi Oracle umí.
Zdar Max

[Heron]

Existují přímo i produkty,

Jo, to jde v PG taky, kdysi jsem napsal reportáž z P2D2, kde někdo představoval appku napsanou v podstatě jen z uložených procedur a na to se rovnou připojoval relativně lehký klient. Veškerá logika v DB.

Každopádně není to jen o výkonu, ale i o odstávkách

To jistě, pokud má někdo dobře nastavený failover a dokáže přepnout dostatečně rychle master, lze to i v PG.

mluvím o zálohách db jako takových

Jenže záloha DB se dá dělat mnoha způsoby. Udělat snapshot toho block device a zálohovat ten. Udělat logickou zálohu (do SQL), udělat zálohu base + binární logy. Nebo kombinace toho všeho.

PG jako takový neumí (pokud vím) oznámit, které bloky se mu od minula změnily (CBT). Na druhou stranu existují nástroje (pgbarman), které umí dělat inkrementální zálohy (rsync) a není nutné dělat recovery všech binlogů za minulé období. Ale jako jasně, je to prostě rsync a cbt to nemá. Na druhou stranu, pokud tohle umí FS, tak proč by to měla umět db.

Paralelní import/export znamená, že export/import běží paralelně v několika vláknech, což v jistých situacích může značně urychlit celý proces.

pg_dump a pg_restore paralelní dump a import umí též. Docela to pomáhá zejména při vytváření indexů po importu.

Nemůže řešit OS, se na tu fci podívej.

Aha, fakt nemám čas studovat 44 stránkový manuál, reagoval jsem pouze na tvůj text. Takže se jedná o in memory db, to pg sice nemá, ale má unlogged tables, které se nelogují () tj. mají značně vyšší výkon (prostě se nečeká na fsync po každém commitu) ale za cenu toho, že se jejich obsah ztratí v případě nekorektního ukončení db.

protože některé věci sdílejí

Opět, tu funkci jsem nestudoval, ale netuším, co by se mohlo u DB sdílet. Už jen dvě oddělené databáze toho příliš ke sdílení nenabízejí. PG jako takový má tak malé nároky na prostředky, že nasadit do 20 kontejnerů 20 různých pg celkem žádnou zátěž navíc neznamená (otázkou je, jak je to s plánováním IO, netuším, do jaké míry jeden pg server plánuje IO napříč různými db (minimálně binlogy jsou sdílené)).

Jinak samozřejmě absolutně netuším, jaký performance dokáže třeba Oracle proti Postgresu vytočit.

Taky ne. Stejně to většinou stojí a padá na diskách. I kdyby byl Oracle o pár procent výkonnější, tak je otázkou, zda za tu ušetřenou cenu nejde pro PG postavit lepší server a tím ten výkonnostní rozdíl smazat.

[snajpa]

Umi PG vsechny replikace a HAcka, jako Oracle tak, jak to Maxovo prostredi potrebuje? Presne tyhle HA featury jsou duvody, proc se plati za komercni reseni, protoze u tech open-source to vetsinou funguje az do ty doby, nez je to realne potreba (a pak je stejne potreba nekomu zaplatit za support...).

[smazáno]

protoze u tech open-source to vetsinou funguje az do ty doby, nez je to realne potreba (a pak je stejne potreba nekomu zaplatit za support...)

Takze stejne jak ten Oracle.

[snajpa]

Ja myslel, ze tem se plati pro jistotu dopredu a kdyz je problem, uz mas predplaceny reseni nejakych par incidentu... to se musi taky dokoupit, nebo co?

[trekker.dk]

PG něco málo umí, ale aby se to dalo prohlásit za HA, tak tomu dost chybí. V podstatě tam máš jeden master server a nějaké hot-standby read-only repliky. Když master spadne, musí nastoupit admin nebo nějaký naskriptovaný automatismus, který z jedné repliky udělá nový master. Data všech ostatních replik se pak musí zahodit a stáhnout z nového masteru, to je opět na adminovi nebo skriptech.

Jsou nějaké zlepšující patche oproti upstreamu, ale všechny, které jsem našel, mají svoje vlastní nevýhody.

[Heron]

Umi PG vsechny replikace a HAcka, jako Oracle

Nejsem expert na Oracle, ale řekl bych, že neumí.

jak to Maxovo prostredi potrebuje

Netuším.

Presne tyhle HA featury jsou duvody, proc se plati za komercni reseni, protoze u tech open-source to vetsinou funguje az do ty doby, nez je to realne potreba (a pak je stejne potreba nekomu zaplatit za support...).

Jenže HA (pokud je to tedy vůbec potřeba) se dá dělat mnoha různými způsoby. A způsob, kdy se koupí black box s nálepkou HA mě osobně přijde jako ten nejhorší možný. Pokud je někde vyžadováno HA, musí se s tím počítat už při návrhu a ten systém navrhnout s ohledem na možný výpadek libovolného uzlu.

[snajpa]

Jenže HA (pokud je to tedy vůbec potřeba) se dá dělat mnoha různými způsoby. A způsob, kdy se koupí black box s nálepkou HA mě osobně přijde jako ten nejhorší možný. Pokud je někde vyžadováno HA, musí se s tím počítat už při návrhu a ten systém navrhnout s ohledem na možný výpadek libovolného uzlu.

Jakoze aplikaci, ktera je napsana proti centralni DB, nejak zazracne naucis chodit s vicero instancemi? Myslim, ze tak snadny to nebude, leda ze bys mel cas prepsat vsechny byznysovy softy sveta na rozumnejsi navrh

[Heron]

Jakoze aplikaci, ktera je napsana proti centralni DB, nejak zazracne naucis chodit s vicero instancemi?

Ne. Ovšem pokud ta aplikace není mrtvá a je stále ve vývoji, tak tohoto lze dosáhnout postupnými změnami. Ostatně slušní vývojáři tohle dělají tak nějak sami od sebe, postupným refaktoringem tu appku dostanou do stavu, kdy se jim lépe přidávají nové funkce a současně to směřují někam kam chtějí.

[trekker.dk]

Vývojáři dělají to, za co jim někdo zaplatí - to platí i u opensource a rozhodně to platí u byznys aplikací. Za úpravu aplikace tak, aby se tvářila, že běží nad HA databází, i když ve skutečnosti běží nad třemi normálními databázemi, nezaplatí nikdo. Což je pochopitelné, je to pakárna - v podstatě si v případě výpadku DB serveru potřebujete udržovat log DB operací a pak ho tam přehrát, čímž z té aplikace de facto děláte databázi, akorát bez zkušeností a znalostí lidí, které se vývojem databázových systémů živí.

IMO nedává smysl reimplementovat něco, co už udělal někdo jiný a dost možná lépe. Bouhžel s PG tohle musíte oželet, protože tohle ještě určitě pár let umět nebude.

[dementni.lojzik]

Jakoze aplikaci, ktera je napsana proti centralni DB, nejak zazracne naucis chodit s vicero instancemi? Myslim, ze tak snadny to nebude

ne, ze bych nekdy nejakou velkou aplikaci migroval na nejakou distribuovanou nebo HA databazi, ale s tim, ze to bude nejaka hruza nebo nemozne bych asi byl opatrny, nektere distribuovane databaze jsou napr. komaptibilni s MySQL (napr. TiDB nebo memSQL), takze v aplikaci (teoreticky) nemusis menit vubec nic.

[snajpa]

No a ted prijdou Postgristi a vysvetlej ti, ze vec “kompatibilni s MySQL” nemuze bejt moc databaze... Obzvlast milovnici aplikacni logiky v serveru ukladajicim data...

[trekker.dk]

Mám zkušenosti s MySQL i PG, jak se správou, tak s vývojem (i když tam většinou nepřímo.) Můj názor: MySQL je pytel sraček. Občas se to prostě nějak rozpadne a data jsou v prdeli. Občas něco nějak nejde nebo to funguje divně - třeba tabulka, která má unikátní index nad několika sloupci, ale přesto mi optimize table tvrdí, že jsou v ní duplicitní záznamy. A nikdy se nedá zjistit proč. Informace o tom, že IP adresa klienta se nedá zresolvovat, je pro vývojřáe tak podstatná, že se loguje jako warning. Naopak informace o tom, že databázi nejde smazat, protože v adresáři zůstal nějaký dočasný soubor, takže neprošel rmdir, je nadbytečná a neloguje se. Pokud chci zjistit, jak se bude provádět nějaký dotaz, dokáže mi MySQL vyplivnout nesrozumitelný a nepřehledný výpis, ve kterém se lze vyznat pouze s manuálem v ruce, a ani tak to není moc slavné.

Když v PG něco nefunguje, tak je v logu napsáno proč. Když chci zjistit, jak se zpracuje dotaz, dostanu podrobný výpis včetně odhadu časové náročnosti jednotlivých kroků; pokud ten dotaz nechám provést, bude to i s informací o tom, jak dlouho to skutečně trvalo. A nikdy jsem ještě nezažil, že by se mi z PG ztratila data.

Aplikační logika v DB je už jenom taková třešnička na dortu. Třešnička, která mi třeba nedávno umožnila napojit existující databázi e-mailových účtů na Dovecotí ACL, které umí poslat jenom striktně dané SQL dotazy a mezi jinými třeba vůbec nepočítá s tím, že uživatelské účty se taky občas ruší.

[snajpa]

No vidis, ja bych misto trouseni logiky vsude sel a patchnul Dovecot. Asi si ty "systemovy" reseni predstavujem jinak (ale teda ja se na to divam z pohledu, kdy fakt nemam problem mit v kazdym dulezitym baliku nalepeny patche a mit to v produkci).

[Michal Kubeček]

No vidis, ja bych misto trouseni logiky vsude sel a patchnul Dovecot.

Téhle úvaze moc nerozumím. Pod "trousením logiky všude" bych si naopak představil právě přístup, kdy se logika musí implementovat v každém klientovi zvlášť, než to, že základní logika bude součástí databáze, takže bude automaticky fungovat pro všechny klienty stejně.

[trekker.dk]

No vidis, ja bych misto trouseni logiky vsude sel a patchnul Dovecot.

Jo? Tak hele - Dovecot tady funguje tak, že dostane přihlašovací údaje do DB, jméno tabulky a jména tří sloupců: kdo, komu a jednička. Když uživatel "kdo" nasdílí uživateli "komu" něco přes IMAP, zapíše se odpovídající řádek. Je to kvůli tomu, aby šlo snadno zjistit, když se uživatel "komu" přihlašuje, "kdo" mu něco nasdílel. No a já potřebuju:

- Ta tabulka nemá žádné vazby na ostatní data, tj. na tabulku uživatelů. Když nějakého uživatele vymažu - což jde zcela mimo Dovecot, tažke nemůže uklidit - zůstanou v ní nesmyslná data. Potřebuju tudíž dva další sloupce obsahující cizí klíč do tabulky uživatelů s "on delete cascade"

- Ale pozor - Dovecot může získávat seznam uživatelů z různých zdrojů, takže to nemůže být povinné. Musíš brát do úvahy, odkud ten uživatel přišel a jestli pro něj nějaký cizí klíč existuje. A taky jestli tohle celé dělat, protože někdo to tak chtít nemusí. Jinak ti to v upstreamu nezačlení

- Uživatelé jsou ve tvaru uzivatel@domena, ale v DB je tabulka domén (o které Dovecot normálně neví vůbec nic) a tabulka uživatelů, ve které je ta část před @ a ID domény. Tj. potřebuješ buď Dovecot nějak globálně seznámit s tím, že tabulka domén existuje, nebo při vkládání toho záznamu nejdřív uživatelské jméno rozdělit a udělat select navíc. To vše samozřejmě s tím, že s DB se komunikuje přes proxy/slovník rozhraní, protože nechceš, aby se k DB připojovaly jednotlivé procesy uživatelů každý za sebe. A opět volitelně, někdo to ve své DB může mít jinak

- To celé dvakrát - je tam jedna tabulka kdo - komu, a pak ještě jedna, kde se eviduje, kdo sdílí všem.

Schválně si zkus odhadnout, kolik práce a tedy kolik času - a peněz - to bude stát. Podle mě fakt hodně.

Samozřejmě si lze dost práce ušetřit tím, že se to do toho Dovecotu prostě nějak doprasí a do upstreamu se to posílat nebude. To bych považoval za trochu špatný způsob práce, rozhodně ne za systémové řešení a hlavně si sice ušetříš práci teď, ale přiděláš si jí do budoucna: na každém serveru musíš vypnout automatické aktualizace toho balíku - když vyjde aktualizace, musíš stáhnout zdrojáky, aplikovat patch (opravit patch, aby to šlo, a pak znovu aplikovat), přeložit, dát do vlastního repa a nainstalovat.

No a nebo se napíšou dvě DB funkce: jedna vezme uživatele "kdo", rozdělí jej na dvě části podle zavináče uprostřed, udělá select a získané ID uživatele přidá do vstupních dat. Druhá udělá totéž pro uživatele "komu". Přidá se trigger, aby se tyhle funkce spouštěly před provedením insert dotazu. To celé bylo tak na 5 hodin práce (která sestávala zejména z čtení manuálu a částečně taky z čekání na pakety z mobilního internetu.) Je to takhle hotové - nebude to vyžadovat další čas, mailservery podporují IMAP ACL a já se můžu jít věnovat něčemu dalšímu.

Krom toho, z Postgre jsem nikdy nevidel vymlatit takovou propustnost na queries, jako s (podotykam spravene nastavenou, coz rozhodne neni default) MySQL - s tou jsem z toho HW vzdycky vytah vic v pomeru na spaleny CPU cas a prozranou RAM.

No jo, já tohle, že bych se rozhodoval podle číslíček, nemám. MySQL možná dá větší propustnost, ale řešení čehokoliv je mnohem náročnější a zabere to víc času. Takže pro sebe jednoznačně preferuju Postgres a za ušetřený čas si koupím lepší hardware, což pořeší tu propustnost a já - opět - se můžu jít věnovat něčemu jinému.

Data jsem s tim jeste neztratil a to jsme tomu delali hodne zle.

Gratuluju. Já ztracená data z MySQL zažil několikrát, vždycky kvůli rozbitému InnoDB. A zle jsme tomu ani nedělali - co si vzpomínám, tak jednou za to mohl výpadek elektriky a ten zbytek byl OOM killer. Kromě toho jsme na jenom serveru měli chybu, která čas od času způsobila desetiminutové zatuhnutí na nějakém interním zámku, načež se ta DB odstřelila sama, což pak vždycky vedlo na poškozenou tabulku mysql.proc (to je taky pěkně nesystémová pakárna, procedury uložené mimo DB, do které patří) a nutnost ručního zásahu.

[xkucf03]

Taky jsem řešil napojení Dovecotu (a Postfixu) na PostgreSQL. A mít možnost napsat si v DB nějaký ten pohled nebo funkci je fakt k nezaplacení.

Ono se sice snadno řekne, že by se měl vylepšit Dovecot, ale vylepšit ho tak, aby to vyhovovalo všem, to prakticky nelze. Spíš by šel napsat modul v céčku (dynamická knihovna), který by se do toho Dovecotu načetl, a dělal, co potřebuješ. Jenže proč to dělat složitě v céčku, když na to stačí pár řádků SQL v databázi, které vytvoří ten potřebný adaptér mezi poštovním serverem a stávající databází uživatelů?

[snajpa]

Pekne prosim, ktera z tech queries nejde nastavit, ze mluvis neco o nejakych fixnich tabulkach? Vsak si muzes primo vypsat queries, kteryma se budes ty DB dotazovat. A ze Dovecot sam neni actionable, ale libovolnej kod v DB za tebe ty adresare taky nesmaze, at se muzes snazit, jak chces, stejne potrebujes backend, co to poresi. A ten si to muze vybrat bez toho, aby se v DB neco menilo samo.

No a co se tyce odhadu, hmm let me see. Tak, kdyz z uvahy vyhodim lidi, co jim tohle jejich distro snadno neumoznuje - myslim, ze normalni praktika 21. stoleti je mit QA - a pak je to o tom, jestli mas distro, co ti tohle umoznuje. Mluvim o NixOSu - odklonuju si stable nixpkgs, dohodit do kterekoliv casti systemu patch je otazkou na chvilku a cele to otestovat ve virtualnim setupu pod Hydrou... Neni problem. Teda, za predpokladu, ze zvladnu vlastne vyspecifikovat, co od tech systemu chci - pokud ma projit mail od uzivatelu z treba 500 login seznamu, je to proste potreba testovat. Takze pravidelne sync nixpkgs s upstreamem + automatizovane test prostredi a fakt neni problem resit veci, jak davaji smysl pro vsechny - ne ze takhle ma kazdej po svym vyreseny na planete over 9000x ten samej problem, ale pokazdy jinak. Kdyz mas moznost do toho takhle sahat, vyhlidky na ty patche prijatelny upstreamem vypadaji absolutne jinak.

[trekker.dk]

Pekne prosim, ktera z tech queries nejde nastavit, ze mluvis neco o nejakych fixnich tabulkach?

Jakákoliv pro slovník - konfigurace vypadá takhle:

map {
  pattern = shared/shared-boxes/user/$to/$from
  table = mailroot.mailbox_user_shares
  value_field = dummy

  fields {
    from_user = $from
    to_user = $to
  }
}

Proces obsluhující IMAP klienta nemá přístup k přihlašovacím údajům do DB a nepřihlašuje se do ní sám. To je záměr, nechci takovému neprivilegovanému procesu ty údaje dát a ani nechci, aby se mi do DB přihlašovalo 4k procesů současně. Dovecot na to má slovníky obsluhované samostatným procesem, kterého se pracovní procesy ptají stylem klíč-hodnota. To rozhraní je obecné, protože slovník neznamená nutně SQL. To znamená, že tvůj patch musí opatchovat tenhle slovník.

No a co se tyce odhadu, hmm let me see.

No, tak za první jsi napsal hodně textu, ale chybí tam ten odhad

Za druhé tady popisuješ, jak si naklonuješ něco na lokál a necháš ten patch aplikovat samomaticky - fajn, to šetří práci. A následně to pochválíš, že je to takhle lepší a ne že "takhle ma kazdej po svym vyreseny na planete over 9000x ten samej problem, ale pokazdy jinak." Ale přitom popisuješ stav, kdy tvůj patch není v upstreamu, tudíž jsi po 9001. vyřešil ten samej problém po svým.

A tím se vracíme zpátky na začátek - bez ohledu na to, jak moc ti distro ušetří práci a bude samopatchovat a testovat, furt je to buď investovat málo času na prasopatch, který do upstreamu nedostaneš, nebo hafo času na patch, který upstream přijme. ("Hafo času" je ten odhad, který jsem chtěl.)

A btw. - když to dostaneš do upstreamu, tak nemusíš z úvahy vyhazovat lidi, kteří zrovna nepoužívají tvé oblíbené distro. On jim ten patch z upstreamu přijde.

[snajpa]

Sem a sem je potreba dostat neco v tomhle duchu. Kdyby to clovek chtel udelat turbociste, mel by se ten DB kod dostat na jedno misto a pak se z obou techhle sites zavolat, odhadem cca 3-4 dny a k tomu komunikace s upstreamem po vyrobeni pull requestu.

[trekker.dk]

To mi přijde trochu optimistické, jestli to dobře chápu, tak v tom dict-sql.c dostáváš jako parametry uživatelská jména (řetězce), protože klient (IMAP proces) posílá vyhledávací klíč taky jako řetězec. Ty ale potřebuješ i metadata, tj. jestli ten uživatel byl načten z DB, do které zapisuješ tenhle záznam (tj. jestli existuje něco, co lze použít jako cizí klíč.) Auth proces ale neví, se kterou DB pracuješ ty, takže potřebuješ způsob, jak ty DB otestovat na shodu.

Prostě mi tam přijde dost prostoru pro to, aby se někomu (myslím core vývojáře Dovecotu) nelíbilo, co děláš

[snajpa]

Ale vzdyt v tom dict-sql.c neni potreba resit nic vic, nez tam pridat moznost custom query, nebo potrebujes neco vic? Asi jsem to spatne pochopil. S tim prsknutim do jednoho souboru jsem to myslel tak, aby se treba ta templejtovaci logika a to, jak se obskakuji volitelny promenny v queries neduplikovalo, kdyby tam melo jit casem delat vetsi kouzla.

[trekker.dk]

Ale vzdyt v tom dict-sql.c neni potreba resit nic vic, nez tam pridat moznost custom query, nebo potrebujes neco vic?

No, ta custom query by vypadala asi takhle (připomínám, že nejsem žádnej velkej vývojář, takže lidi, co umí s databázemi, prominou )

  user_var := split_part(NEW.from_user, '@', 1);
  domain_var := split_part(NEW.from_user, '@', 2);

  if domain_var = '' then
    raise exception 'Domain part must not be empty';
  end if;
  if user_var = '' then
    raise exception 'User part must not be empty';
  end if;

  select mailboxes.id into mailbox_id from mailroot.mailboxes
    left join mailroot.domains on mailboxes.domains_id = domains.id
    where uzivatel = user_var and domena = domain_var and
      uzivatel || '@' || domena = NEW.from_user;

    NEW.from_user_id = mailbox_id;
    return NEW;

Je to vyseknuté z toho triggeru, takže výsledné SQL by pak vypadalo ještě jinak. Bylo by to něco jako

insert into tabulka (sloupce) values (hodnoty,od,db, select (ten kód z triggeru), select(ten kód z triggeru))

Nemám tušení, jestli takový dotaz vůbec jde pustit, ale rozhodně to vypadá hnusně

[snajpa]

@ kdyz to dostanu do upstreamu... No, je to o tom vubec sebrat odvahu a jit a ten patch uvarit a nasadit, pak az ho cpat up. To se mi s infrou na RHELu blbe predstavuje. Nasetupovat prostredi, kdy bych byl schopnej si prebuildit celej RHEL, protoze chci zmenit neco v zakladnich libkach, to je na palici, at se panove z RH nezlobi; ale myslim, ze jsou sami radi, kdyz nemusi Koji deployovat kazdy den. Prave proto tak silna reference na NixOS, uplne jiny svet je to.

[snajpa]

Ale vis, jak se nejlip dohodnem? Ja ted prestanu delat chytryho a az budem mit infru celou prekopnutou na NixOSu, tak to vyvalime ven v podobe nejakych navodu, at se aj dalsi muzou inspirovat Zatim jsme na zacatku a klasicky jako kazda migrace "vseho" to vypada na hromadu prace hlavne prave s tim rozlustenim, co jak kde historicky je.

[snajpa]

Krom toho, z Postgre jsem nikdy nevidel vymlatit takovou propustnost na queries, jako s (podotykam spravene nastavenou, coz rozhodne neni default) MySQL - s tou jsem z toho HW vzdycky vytah vic v pomeru na spaleny CPU cas a prozranou RAM. Jak to ma PG 10 netusim, s tim jsem si poradne jeste nehral, nastesti uz nemusim high-perf application hosting resit vubec, uz se v klidu soustredim jenom na ten podvozek pod temahle aplikacema. Takze pokud appka podporuje oboje, je jasne, co vyberu, i kdyz si muzou "znalci" povidat o nedatabazi, co chteji. Data jsem s tim jeste neztratil a to jsme tomu delali hodne zle. Co teda nefunguje dobre a rozbiji se, je replikace.

Ciste podle myho osobniho nazoru (na kterej se dlabe a neni relevantni, protoze stejne BI aplikace nevyvijim), roztrousena aplikacni logika kudy-tudy je casem pod sebou podrezana vetev... Ale myslim, ze bych tohle nevysvetlil ani borci, co prave stravil celej tejden hledanim, kde se mu ty data v tabulce meni pri pseudonahodnych udalostech, protoze mi vysvetli, jak mu to strasne setri cas jinak

[Heron]

MySQL tradičně exceluje (zejména při použití MYISAM) při velmi jednoduchých selectech. Zatímco PostgreSQL ještě těžkopádně spouští optimalizátor prováděcího plánu, tak MySQL už má často hotovo. Zejména pokud jsou podmínky vhodné pro cache dotazů (tu PG vůbec nemá). PostgreSQL je naopak vhodný pro komplexní dotazy.

PostgreSQL má mnoho datových typů na kde co všechno a ke všemu i příslušnou sadu funkcí. Nemluvě třeba o PostGIS. Takže na straně DB toho lze spočítat poměrně hodně a to i bez použití procedur. Pochopitelně kdo chce, může si vlastní procedury psát v téměř libovolném jazyku. Před jistou dobou se PostgreSQL stal dokonce nejrychlejší NoSQL (not only sql ) db a předběhl dokonce i Mongo (v jeho vlastní disciplině).

Každopádně, obě databáze mají své místo na světě, na něco se víc hodí mysql, na něco se víc hodí postgresql. Je potřeba vědět o jejich vlastnostech a použít je na vhodném místě.

[trekker.dk]

PostgreSQL má mnoho datových typů na kde co všechno a ke všemu i příslušnou sadu funkcí.

Ještě pořád si libuju pokaždé, když mi DB z tabulky o 10M záznamech vyplivne všechny, které obsahují JSON jako je třeba {"dpkg":{"package":"linux-image-amd64"}}, za 0.00nic sekund.

[Heron]

Jo jo. Stále ještě si pamatuju šok, kdy jsem chtěl (v cca 2006) cosi analyzovat v Excelu (nebo tehdy možná ve StarOffice ekvivalentu) a zjistil jsem, že max počet řádek bylo směšných 65535 (16b). Tak jsem těch pár milionů řádků narval do DB a během pár sekund to analyzoval a od té doby to nedělám jinak.

Na JSON (sám ani pořádně nevím proč) bych použil Mongo, i když PG má podporu a funkce (a rychlost) skvělé.

[snajpa]

MySQL se tradicne s MyISAM ukaze, jako nejvetsi sr*cka pod sluncem a je to presne ten duvod, proc se lidi MySQL smejou. Leda ze by na tom systemu nejelo nic jinyho, nez prave ta databaze, jinak to bude hodne bida a zadrety disky (nebo rudy flashe :D).

[snajpa]

*Pokud* pod ni neni ARC nebo nejaky podobny caching, that is, s Linuxovou pagecache je to na systemu s kontejnery vrazda, nepouzitelne.

[citanus]

muzu se zeptat proc tomu tak je?

[snajpa]

MyISAM se spolejha na linuxovou pagecache, ktera pouziva trochu modifikovany mechanismus LRU. Tedy uz jenom tupe cp souboru nad velikost RAM ji spolehlive precisti od vsech nacachovanych dat databaze.

[Michal Kubeček]

Už to tady v poslední době čtu po několikáté, ale zkušenosti můžu říct, že to není pravda. Např.

mike@lion:/srv/backup> free -m
              total        used        free      shared  buff/cache   available
Mem:          15745        2312         162         238       13269       13039
Swap:         15633           0       15633              
mike@lion:/srv/backup> time cat $some_file >/dev/null
                                 
real    0m49,684s  
user    0m0,040s
sys     0m4,225s                                      
mike@lion:/srv/backup> time cat $some_file >/dev/null
                          
real    0m49,529s
user    0m0,054s                                             
sys     0m4,587s                               
mike@lion:/srv/backup> time cat $some_file >/dev/null                       
                   
real    0m1,200s
user    0m0,016s
sys     0m1,181s
mike@lion:/srv/backup> du -sh $some_file                    
5,7G    $some_file

Pokud je to tak, jak tvrdíte, proč je druhý pokus přibližně stejně pomalý jako první, ne tak rychlý jako třetí?

[snajpa]

Protoze jsem psal modifikovana LRU a OK, jednonasobne cp neudela nic, to je ale vytunena cache! A kdyz to pustim znova? Je po databazi ME-GA LOL.

[snajpa]

Na tohle totiz uplne krasne staci, aby nejaky odvazlivec ten nejaky jeho rsync prerusil a pustil ho znova parkrat v ramci prototypovaciho kolecka nejakeho zalohovaciho skriptu. A mezi tim cca vsichni ostatni na tom nodu dodatabazovali.

[trekker.dk]

To zní, jako že VPS s dedikovanou pamětí a vlastním kernelem mají i nějaké ty výhody, což?

[snajpa]

To zni, jako ze Linux si hraje na to, ze umi kontejnery, ale takovyhle banality poreseny nejsou Ve finale si tam clovek musi dopojit uplne cizi storage subsys, aby se to dalo pouzivat. Pak uz to ale jde

[snajpa]

Protoze jak vidis, tak stejne musis okolo produkcniho systemu s takovou prave MyISAM a vanilla Linuxovym storage chodit po spickach, jinak zabrecis.

[snajpa]

A jinak jo, maji vyhody, jasne, ze jo. Clovek spoustu veci nemusi resit. Cenou je teda hodit na to vic hardwaru, ale je to mensi zatez na adminy, to urcite. Dost by mne zajimalo, jak ted kmitaji lidi, co navalili vsechno na microservices pod par instanci kernelu na vanille.

[Heron]

Tak ono je celkem otázkou, jak by se to mělo chovat. Protože zatímco na linuxu jsem zvyklý, že soubor, který se před chvílí četl (nebo zapisoval) je velice pravděpodobně v cache (málokdy se mi stane, že bych se spletl a soubor v cache nebyl), tak na FreeBSD (ZFS s ARC) se mi celkem pravidelně stává, že ten soubor prostě nacachován není ani poté, co se s ním několikrát pracovalo.

Takže tentýž skript na linuxu, který opakovaně se souborem něco dělá, způsobí, že soubor je načten z disku jen jednou (při prvním tasku), tak na FreeBSD se daný soubor opakovaně čte (klidně i 4x), zatímco ARC mon je happy a ukazuje 90% hit rate. A mám celkem podezření, že ARC ten soubor strčí do cache právě až během posledního (tedy dejme tomu čtvrtého průchodu), kdy už je to naopak zbytečné a způsobí to vyhození jiných dat z cache.

Celkem bych ocenil nějaký syscall nebo něco, kdy bych OS sdělil "tento soubor prosím nacachuj už při prvním čtení".

Ano vím, že bych to měl pravděpodobně napsat jinak, cachovat si to sám, strčit to do ramdisku (pokud se to tam tedy vejde), což je další práce navíc, kterou na hloupé LRU právě řešit nemusím, protože vím, že ten soubor v iocache prostě bude, pokud se tam vejde, už po prvním průchodu.

[Michal Kubeček]

Jasnovidný software holt psát ještě neumíme a všem se zavděčit nejde. Ale když někdo cítí neodolatelnou potřebu při každé příležitosti kázat, jak celý ten Linux stojí od základu za houby, tak je každá rána dobrá.

Celkem bych ocenil nějaký syscall nebo něco, kdy bych OS sdělil "tento soubor prosím nacachuj už při prvním čtení".

Možná by to mohl řešit posix_fadvise() s POSIX_FADV_WILLNEED, případně madvise() pro mmapované soubory. Ale tohle není moje parketa, takže nemůžu říct, jestli je to přesně ono.

[snajpa]

Supr, o POSIX_FADV_WILLNEED jsem nevedel - myslel jsem si, ze je to specialita mmaped rozhrani -> to se bude hodit - diky

[trekker.dk]

Hm, POSIX_FADV_DONTNEED taky vypadá zajímavě - TODO: zjistit, jestli by o to nešel vylepšit rsync, aby mi nemíchal s pamětí, když se záloguje

[cezz]

Mozno nieco ako nocache by stacilo, ak to rsync nema priamo ako volbu. Vela backup nastrojov to robi by default. (alebo by rozhodne malo)

[trekker.dk]

Nemá, co jsem hledal, pár let zpátky se řešila možnost, že by to používalo přímé I/O, ale nakonec to padlo s tím, že by to k ničemu nebylo.

[cezz]

Ak som spravne pochopil, tak implementacia POSIX_FADV_DONTNEED je pomerne hlupa v tom, ze zahodi cache ktora existovala uz predtym, cize sice to naozaj nezahlti cache subormi ktore realne citas iba raz, ale tiez zahodi cache pre vsetky subory ktore si tak cital.

IMHO je to vo vela pripadoch prospesne. (napriklad ked zalohujes DB server, tak zvycajne zalohujes nejaky dump a nie priamo DB a tym dumpom naozaj nema zmysel vytlacit zivu DB z cache) Ale su pripady, kedy to je lepsie nepouzit.

[trekker.dk]

To je docela divný, když se to volá na specifický file descriptor. Ale v principu by mi to ani nevadilo - pokud to dokáže odlišit, že ten soubor používal ještě někdo jiný a v takovém případě cache nezahazovat, tak je mi to fuk. A i kdyby ne, tak místo toho, aby přepsal cache, tak ji vymaže, což v principu vede na stejný výsledek, že se často používaný soubory budou muset načíst znovu.

[cezz]

Je to cudne, ale presne tak to je. (v Linuxe)

Ono je to stale celkom OK, lebo ked si predstavis backup tool, ktory zalohuje povedzme nejaku web aplikaciu. Je pravda ze s POSIX_FADV_DONTNEED zahodi cache tych suborov, ktore mozu byt casto pouzivane a aplikacia bude pomalsia, lebo ich musi jeden krat opatovne nacitat do pamati. Ale bez tohto flagu bude zaloha opakovane zaplnat cache subormi ktore tam normalne len tak lezia a az do dalsej zalohy nebudu potrebne a tym opakovane vytlacia tych par aktivnych suborov z cache. Cize stale je to 1 krat vs pravdepodobne viacnasobny cache flush.

Plus ak mas stastie, tak napriklad taka databaza tym ani nemusi velmi trpiet, lebo POSIX_FADV_DONTNEED nezahodi dirty cache, takze ak je to prave tvoj pripad tak ani o tu cache neprides. (pravda, stale plati ze zalohovat aktivny DB subor asi nie je najlepsi napad)

[Heron]

Jasnovidný software holt psát ještě neumíme a všem se zavděčit nejde.

To je jasné, proto mě třeba více vyhovuje "hloupé" deterministické chování na které se dá spolehnout a když se o tom ví, tak toho využít, než různé chytristiky, které z měřených dat odhadují bůh ví co a snaží se neustále měnit parametry a chování neustále mění.

Ale když někdo cítí neodolatelnou potřebu při každé příležitosti kázat, jak celý ten Linux stojí od základu za houby, tak je každá rána dobrá.

Njn. Všiml jsem si toho u více lidí.

posix_fadvise()

Dík, mrknu na to.

[snajpa]

Njn. Všiml jsem si toho u více lidí.

Tak do veci, co by mohly bejt uz davno vyreseny, kdyby se prijaly navrhovany reseni vcas a nepolitikarilo se, to mne vcelku bavi zarejt, to musim uznat.

[Heron]

Tak to je asi otázka co kdo považuje za "vyřešené". U několika "řešení" se neumím ubránit pocitu, že to chtělo ještě několik dalších iterací, že to řešení sice jde správným směrem, ale pořád to ještě není úplně ono. Za příklad mohu vzít třeba PEP 572. Rozhodně je to super věc, tohle se vyloženě nabízelo (zejména třeba pro list comprehension), budu to používat, ale nedovedu se zbavit pocitu, že to prostě ještě není dostatečně uvařené. Problém je, že měnit syntax jazyka není dobrý nápad, takže pokud někdo za pár let přijde na finální verzi tohoto návrhu, tak už jej bude docela těžké prosadit, protože už je to přece "vyřešené".

Za kladný příklad považuju třeba v této diskusi zmíněné DDL triggery v postgresql, kdy tato funkcionalita byla ohlášená afaik o dvě verze PG dřív (tj asi tak o rok), ale protože sami vývojáři nebyli spokojeni s tím, jak to vypadá, tak to prostě odložili. Podle mě správný přístup. Důležitá je stabilita api a ne to, že něco vyjde o rok dřív (na to si za 20 let už nikdo nevzpomene).

[snajpa]

Nevim, jestli jde uplne srovnavat vyvoj jadra vs. vyvoj podoby jazyka. Kdybychom se bavili o vyvoji jadra vs. implementace specifikace toho jazyka, tak to bude velmi podobne. Tam bych byl pro radikalnejsi vyvoj a mnohem min politikareni, pro takovy novatorstejsi pristup - vyzkousime, pokud to nebude fungovat, nebudeme se to bat zahodit a udelat lip.

[snajpa]

Od toho rict si kernelu, jak to chci s cachi je madvise(manpage) s MADV_WILLNEED flagem pro mmap()ed soubory. Pak pujdou data jeste pres pagecache (co uznavam, je kopirovani navic, v urcitych HW konfiguracich s NVMe a pomalou pameti to bude asi znat).

@ ZFS a jak se chova - v tuhle chvili se FreeBSD implementace ARC dost lisi, pokud vim - v Linuxu je navic rozsirena o ABD, ktery vyresil problemy s fragmentaci pameti, na druhou stranu pridal dalsi kopii dat v RAM do cesty. Takze je mozny, ze dlouhodobe bezici system nebude uplne srovnatelnej. Jestli ti to dela ale i cerstve nabootovana vec, tak tam nekde v ty FreeBSD implementaci neco smrdi Popis, jak to vypada pri cteni dat na Linuxu, je tady.

[Heron]

Takze je mozny, ze dlouhodobe bezici system nebude uplne srovnatelnej. Jestli ti to dela ale i cerstve nabootovana vec, tak tam nekde v ty FreeBSD implementaci neco smrdi

Tak na prázdné cache se to chová rozumně (to už by teda bylo hodně blbý), "problém" je s plnou cachí, tam se mu evidentně moc nechce vyhazovat starý data z cache a udělat prostor pro tohleto.

Proč jsem dal problém do uvozovek. Ty procesy rozhodně netrpí nedostatkem dat, CPU je vytížené na 16x100%, takže rychlost zpracování je stejná i když je to už v cache nebo ještě na disku.

Problém je, že diskový výkon pro ostatní procesy dost citelně a měřitelně klesne. A to je proč to řeším. Takže kernel může být happy, procesy mají svá data, CPU je optimálně vytížené, tak nemusí mít potřebu tohle cachovat (z tohoto pohledu je to pochopitelné), akorát já potřebuju ty disky taky používat i k něčemu jinému.

[snajpa]

Jak vypada vystup arc_stat.pl z baliku sysutils/zfs-stats? Koukam, ze arc_summary.py je taky zalezitost ZoL-only...

[Heron]

Balíček je nainstalovanej, skript tady není. Podle názvu soudím, že to bude tohle:

zfs-stats -A

------------------------------------------------------------------------
ZFS Subsystem Report                            Wed Jul 18 21:20:22 2018
------------------------------------------------------------------------

ARC Summary: (HEALTHY)
        Memory Throttle Count:                  0

ARC Misc:
        Deleted:                                27.78m
        Recycle Misses:                         0
        Mutex Misses:                           84.59k
        Evict Skips:                            8.23m

ARC Size:                               69.18%  20.85   GiB
        Target Size: (Adaptive)         71.52%  21.55   GiB
        Min Size (Hard Limit):          12.50%  3.77    GiB
        Max Size (High Water):          8:1     30.13   GiB

ARC Size Breakdown:
        Recently Used Cache Size:       95.14%  20.50   GiB
        Frequently Used Cache Size:     4.86%   1.05    GiB

ARC Hash Breakdown:
        Elements Max:                           2.68m
        Elements Current:               41.16%  1.10m
        Collisions:                             20.73m
        Chain Max:                              8
        Chains:                                 121.48k

------------------------------------------------------------------------

zfs-stats -E

------------------------------------------------------------------------
ZFS Subsystem Report                            Wed Jul 18 21:28:57 2018
------------------------------------------------------------------------

ARC Efficiency:                                 2.12b
        Cache Hit Ratio:                91.66%  1.95b
        Cache Miss Ratio:               8.34%   177.14m
        Actual Hit Ratio:               91.15%  1.94b

        Data Demand Efficiency:         96.71%  122.13m
        Data Prefetch Efficiency:       23.75%  27.61m

        CACHE HITS BY CACHE LIST:
          Most Recently Used:           4.47%   87.09m
          Most Frequently Used:         94.97%  1.85b
          Most Recently Used Ghost:     0.01%   227.01k
          Most Frequently Used Ghost:   1.03%   20.11m

        CACHE HITS BY DATA TYPE:
          Demand Data:                  6.07%   118.11m
          Prefetch Data:                0.34%   6.56m
          Demand Metadata:              91.60%  1.78b
          Prefetch Metadata:            2.00%   38.99m

        CACHE MISSES BY DATA TYPE:
          Demand Data:                  2.27%   4.02m
          Prefetch Data:                11.89%  21.05m
          Demand Metadata:              80.52%  142.63m
          Prefetch Metadata:            5.32%   9.43m

------------------------------------------------------------------------

Jinak teď opravdu nemám čas to řešit, nemám tady ani žádný balík testovacích dat.

[snajpa]

To vypada, jako kdyby byl ten dataset fakt velky a mel v case vcelku rychle menici se pattern, ktera data se zrovna melou. Je to nejake zalohovaci pole nebo nejaka malo pouzivana archivujici databazova instance? Jak velka data to pod sebou ma? Mozna by tomu pomohla rozumne velka L2ARC.

[Heron]

Je to 10TB pole, aktuálně 7TB dat. Ale odhad skoro správný, aktuálně tam probíhá konverze video souborů do h265 s tím, že ty staré se po konverzi a kontrole mažou. Ten proces co jsem popisoval výše dělá něco podobného, původní soubor se po zpracování (ale až po určité době) smaže. Nevím, jestli mu zrovna tento pattern (tj několikrát načíst, zpracovat a na konci smazat) nevadí.

L2ARC (pravda, jen 64GB) jsem zkoušel, to nepomohlo. Do L2 to jen zapisovalo a čtení jsem neviděl. Nechtěl jsem to ssd trápit neustálým zápisem, tak jsem tu cache opět odstavil. Na rychlost to stejně nemělo vliv.

[xkucf03]

a pak je stejne potreba nekomu zaplatit za support...

Zvýraznil jsem klíčová slova: jednak platíš, až když to reálně potřebuješ, a jednak ten „někdo“ není monopolista (jeden jediný), který by tě mohl vydírat.

[Max]

Jop, existuje nějaký podobný sw pro Postgres jako tento pro Oracle Easy database source control with Git, SVN, and TFS? Vesměs to díky DML auditům sbírá změny v db a funguje to i jako zpětný audit + data jdou do verzovacího systému. Ukázalo se to jako dobrý nástroj na audit v případě, že do db hází změny více developerů a nejde to všechno přes jednoho.
Jen mně to zajímá, nebo zda jsi neřešil něco podobného?
Zdar Max

[Heron]

WTF?

Sorry, ale

Ukázalo se to jako dobrý nástroj na audit v případě, že do db hází změny více developerů a nejde to všechno přes jednoho.

Je cesta do pekel. To se přece dělá opačně, tedy vývojář navrhne změnu schematu (alter.sql), tohle by měl verzovat stejně jako ostatní zdrojáky a potom tuto změnu provést v DB.

Cesta, kdy si v db provede kdo chce co chce a potom se to zpětně audituje fakt není dobrá.

Jinak vím, že nedávno proběhla nějaká diskuse o tom, jak správně verzovat změny v DB schématu, ale konkrétní nástroj jsem nezachytil.

[Max]

To ano, takto to funguje, ale dle zkušenosti nelze spoléhat na to, že to tak skutečně je provedeno. Nevyloučíš, že vývojář si udělá nějaký zmatek a jiný soubor jde do svn a jiný pustí do db.
Z toho důvodu by to asi mělo jít přes verzovací systém a deploy změn dělat až po nějakém checkoutu z verzovacího systému.
Každopádně jakmile má vývojář přístup do db, nelze věřit ani tomuto postupu. Proto existuje zpětná kontrola v podobě auditování změn tímto sw. Nejde o to, že by nějaká neplánovaná změna byl úmysl, spíše omyl.
Další věcí je, že tento zpětný audit zaznamenává čas skutečné změny (né commitu do svn), udělá automaticky diff oproti předchozímu stavu a vše přehledně zobrazí. V případě nějakého problému zrychluje diagnosktiku.
Zdar Max

[Heron]

Tak já nevím, pokud někdo chce, tak si může dát do cronu třeba každou hodinu pg_dump -s, to schema diffovat a při změně ukládat do gitu a zatroubit na klakson .

Nebo ještě lépe, PostgreSQL má trigger i na DDL, takže pokud se změní struktura v DB, tak na ten trigger může být pověšený skript, který zařídí výše uvedené.

Pochopitelně ty změny se dají logovat, takže to jde i zpětně nalézt v logu.

[Max]

To jsem chtěl vědět, díky.
Zdar Max

[xkucf03]

To ano, takto to funguje, ale dle zkušenosti nelze spoléhat na to, že to tak skutečně je provedeno. Nevyloučíš, že vývojář si udělá nějaký zmatek a jiný soubor jde do svn a jiný pustí do db. Z toho důvodu by to asi mělo jít přes verzovací systém a deploy změn dělat až po nějakém checkoutu z verzovacího systému. Každopádně jakmile má vývojář přístup do db, nelze věřit ani tomuto postupu.

Sorry, ale tohle je problém organizační, nikoli technologický. Vývojář má odevzdávat svoji práci do verzovacího systému. Následně proběhne sestavení (pokud možno automaticky) a až výsledek tohoto sestavení si bere člověk, který bude nasazovat. Nasadí nejdřív na různá testovací prostředí, tam se to testuje, a až když testy projdou, tak se (přesně to sestavení, které se testovalo) to nasadí na pre-produkci a po dalším kolečku alespoň základních testů se to nasadí na produkci.¹

Vývojář má vyvíjet a ne nasazovat a hrabat se v produkčních datech a systémech. Dneska je děsná móda jakési DevOps, ale spousta firem si to asi vykládá tak, že můžou zapomenout na tradiční postupy a dobré praktiky a jakkoli to zprasit a ještě to nazvou líbivým buzzwordem + to pracovních inzerátů nejlépe přidají větičku „jsme pankáči“. Což o to, s punkáčema je fajn jít do hospody, na koncert nebo třeba jet na vodu… ale v práci chci dělat raději s lidmi, kteří nemají ve všem totální bordel.

_{[1] Pokud by někdo považoval tento přístup za extrémně konzervativní a nepružný – není tomu tak. Díky automatizaci procesů (CI) lze ten proces zkrátit (bez vynechání kroků) tak, aby od uložení do verzovacího systému do nasazení uběhla jen velmi krátká doba. A před zaverzováním si to každý vývojář testuje na svém prostředí.}

[xkucf03]

Jinak vím, že nedávno proběhla nějaká diskuse o tom, jak správně verzovat změny v DB schématu, ale konkrétní nástroj jsem nezachytil.

Dřív si na to lidi (resp. týmy) psali různé sady skriptů, které „sjížděly inkrementy“ a nasazovaly je do DB + k tomu ukládaly metadata, která verze byla naposledy nasazena. Je to prostě jen hromada .sql souborů + nějaké .sh + třeba Makefile.

Dneska existují hotové nástroje jako Liquibase, které stačí jen použít, není potřeba si to programovat sám. V principu to ale dělá totéž: ve verzovacím systému máš uložené soubory s inkrementy a pomocí Liquibase to nasadíš na nějaké prostředí – tím se aplikují změny a uloží se do DB i informace, jaká verze byla nasazena. Kromě toho to umí vracet změny zpět (pokud to z principu lze samozřejmě) nebo generovat SQL skript, který si můžeš zkontrolovat a nasadit kdekoli i bez tohoto nástroje. Inkrementy se dají různě štítkovat, a pak se dá na určitá prostředí nasadit jen podmnožina, nebo tam lze mít různé varianty pro různé DBMS atd.

Nasazovat změny v datovém modelu jen tak „z ruky“ bez podobného nástroje je fakt cesta do pekla.

[trekker.dk]

Ruby on Rails na to třeba má Rake task - do určeného adresáře se vloží soubor s třídou, která má metody up() a down()*. V up() jsou příkazy na update schématu, down to vrátí zpátky, to vše včetně případných konverzí, pokud jsou nějaké potřeba. Když je těch změn víc, spouští se podle času vytvoření.

* pro jednoduché změny to má jenom jednu metodu, která umí obojí, když se správně napíše

[xkucf03]

my jsme příkladem těch náročnějších procedur, takže CPU na db je dost vytížený. Existují přímo i produkty, které se skoro tváří jako db only.

Tohle mi nepřijde jako šťastný návrh. Sice neříkám, že DB má být jen hloupé úložiště – na některé věci ty procedury v DB smysl mají – ale je potřeba znát míru. Když se to přežene, tak právě narazíš na to, že to neškáluje nebo se to nešikovně nasazuje – zatímco třeba javovských aplikačních serverů si kolem jedné DB můžeš spustit kolik chceš a prakticky zadarmo, kdežto databázi máš jen jednu, na jednom železe a máš na ní jednu verzi uložených procedur. Když jsou procedury vně, můžou jednak běžet distribuovaně a jednak v libovolném množství verzí, mezi kterými lze libovolně přecházet, dělat mezi nimi HA a LB, testovat nové verze (v případě čtecích operací nebo testovacích uživatelů klidně i na produkčních datech před puštěním do ostrého provozu) atd.

[Max]

Je to z důvodu migrace / koexistence. Vývoj je hodně bouřlivý a paralelně jede vývoj nového řešení pro nové služby / požadavky (Vývoj v C# + Oracle ODP.NET + EntityFramework). Přidávají se tak fce do obou řešení a cílem je postupný přechod na to nové. Aby mohla být logika sdílená, musí být v db. Jinými slovy, po koupi jedné firmy se pro ně začalo vyvíjet relativně na zelené louce (fce, které potřebovali, nebyly v současném IS). Cílem je tedy postupný odchod z VFP k C#.
IS ve VFP je tak rozsáhlý projekt, že by nešel ani během dvou let přepsat, jediná možnost je tedy postupný přechod.
Zdar Max

[xkucf03]

pokud vezmu ty peníze za licence a použiji je na něco jiného (třeba HW), tak se v určitých parametrech a vlastnostech mohu dostat nad ten komerční produkt. Tohle jsem viděl několikrát. Někdo obhajoval nákup komerčního produktu za určitou cenu ale moc se nezamýšlel nad tím, že kdyby se ty peníze strčili jinam (hw, čas na implementaci něčeho, čas na otestování jiných produktů), tak by z toho vyšlo lepší řešení.

+1, tohle jsem taky hodně krát viděl. Vyhodí se neskutečné peníze za licence k proprietárnímu softwaru, ale pak je děsný problém někam přidat giga RAMky, pár giga disku nebo vyhradit půl dne testera, aby ověřil funkčnost nové verze. Prostě šetření/rozhazování na nepravém místě.

[xkucf03]

Chtělo by to někoho, kdo zná obě strany a mohl by nám to objektivně vysvětlit.

Na komplexní srovnání si netroufám, ale mám pár let komerčních zkušeností s Oraclem a na vlastních projektech používám PostgreSQL.

Z pohledu vývojáře jsem jednoznačně pro PostgreSQL, je mnohem modernější a vstřícnější, kdežto u Oraclu mám pocit, že zamrzl v čase, je to takový COBOL. To platí asi ve všem – až na Advanced Queues (AQ), ty se mi na Oraclu líbí.

Co se týče výkonu – na limity PostgreSQL jsem nenarazil, ale to je dané spíše velikostí těch projektů. U Oraclu jsem párkrát narazil s komplexitou dotazů – např. už nezvládal zanoření nebo parametry¹, nějaká ta ORA-600 taky byla. Něco z toho jsou chyby DBMS, ale jindy je to dané spíš deklarativní podstatou jazyka SQL² nebo je doba zpracování akceptovatelná s ohledem na objem dat, rychlosti disků a paměti. A to se stane víceméně u všech DBMS, někde dřív, někde později, ale pak už je to víc o návrhu datového modelu a procesů, než o volbě jednoho či druhého systému. To první typicky způsobuje řádově větší zrychlení/zpomalení než to druhé.

A v neposlední řadě: PostgreSQL je svobodný software, ale to už pod tímto blogem nemá smysl opakovat, o vendor lock-inu tu toho už to bylo řečeno dost.

_{[1] dotaz byl po dopsání některých (byť nesouvisejících) částí už tak složitý, že ho Oracle odmítal spustit s parametry – zatímco když se :parametr nahradil za literál (tzn. nechvalně známé lepení SQL dotazů), tak to zase fungovalo. Nebo někdy Oracle tvrdil, že našel cyklus mezi CTE/WITH výrazy, i když tam žádný nebyl – tam zase pomohla duplikace kódu a parametrů
[2] ne vše jde napsat deklarativně a u hodně složitých programů je lepší to rozdělit a řešit procedurálně}

[trekker.dk]

Fascinující. O kolik věcí jsme v OSS světě ochuzeni.

No, nutno říct, že Oracle je skutečný extrém - mám takový pocit, že jednu dobu měli licenční politiku takovou, že se muselo zalicencovat každé CPU, na kterém ta DB potenciálně může běžet. Celková cena za pár set procesorů té VMWare farmy prý byla docela zajímavá.

Ale jinak +1, taky nechápu, proč je někdo vůbec ochotný uvažovat o tom něco si od těchhle gaunerů koupit. Nadpis blogu by spíš měl být "necháváme se od Oracle ojebávat"

[xkucf03]

mám takový pocit, že jednu dobu měli licenční politiku takovou, že se muselo zalicencovat každé CPU, na kterém ta DB potenciálně může běžet

To mají snad pořád. Zrovna nedávno jsem byl svědkem diskuse, kde se řešilo, zda radši nekoupit nějaký slabší fyzický server s méně procesory, který by si tiše hučel někde v koutě, aby se nemuselo virtualizovat a ušetřilo se tím za licence na Oracle.

[Max]

Ano, to mají pořád. Jedinou výjimkou je jejich virtualizační řešení. Možná jsi o tom četl v tom mém prvním blogu o Oracle, kde jsem popisoval to, co píšeš.
Zdar Max

[trekker.dk]

Ne, mám to odjinud. U těchhle Oracle blogů většinou dám první tři odstavce a zbytek už nemůžu, protože pro samé kroucení hlavou nevidím na monitor

[xkucf03]

Byla to AFK diskuse, teď nedávno.

[Chulda]

To platí stále. V případě vmware je nutné zalicencovat veškeré hosty, na kterých by to mohlo běžet.

Jen to vylepšili, zatímco dříve stačilo oddělený cluster, teď už musí být úplně vše (storage, network, vcentrum) oddělené od jakéhokoliv jiného hostu, jinak se musí také zalicencovat.

[Max]

My také ne, než s tím přišli lidi od Oracle, že toto nemáme ve smlouvě uvedeno a v nějakých jejich podmínkách je nákup procesorové licence vázán jen pro použití v konkrétní firmě. Nicméně ověřeno to nemám, nezkoumal jsem to (toto je věc, kterou řešil někdo jiný). Je také možné, že máme nějakou historickou smlouvu a nové podmínky jsou jiné. Fakt nevím.
Zdar Max

[Crystal Ball]

Pokud nemate nejakou legacy core smlouvu, ktera by vyslovne zakazovala pribuzne strany (coz je vysoce nepravdepodobne), tak to je spis chyba vasich salesu, ze se na tohle nezeptali (pripadne legal, ze to salesum neporadili).

Jinak normalne se tohle da poresit uplne obycejnym amendmentem k orderu/smlouve o delce pouhe jedne klauzule. Z druhe strany, je taky mozne, ze jak se tohle dostane pryc z rukou salesu na obou stranach, tak se mozna uz Oraclu nebude prilis chtit tohle menit (a zastupnej duvod si business practices najdou). V Oraclu jsou precijen kurvy nenasytny.

[xvasek]

Přitom se vsadím, že když se člověk zamyslí, co to reálně dělá (aniž bych o tom cokoli tušil), tak nejspíš přijde na to, že kdyby to bylo dobře udělané, tak by výkonově stačila virtuálka s dvěma jádry a s postgresem. (Nebo aspoň takovou instalaci Oracle tady mám já - footprint dat, který se tam reálně sype každý den, má asi tak okolo 2MB a předchozí data se véceméně zahazují).

[Heron]

Mě trochu zarazilo toto:

Vývojáři jsou taktéž nadšený, protože se jim díky tuning packu odkrylo spoustu prasečinek (stovky tisíc zbytečných selectů denně apod.)

Pominu to, že selecty lze v normální db logovat i bez zakoupení speciálního balíčku, ale překvapilo mě, že vývojáři nevědí, jaké selecty a v jakém počtu do db posílají.

[Max]

Logovat selecty lze, ale následný reporting je trochu těžší. Do této doby byly logovány jen slow selecty.
Každopádně to, co jsem uvedl jako příklad, bylo ve stylu "tento status updatujeme při každém otevření okna, přitom by stačilo jen toto updatovat při změně" atd. Je to spíše o odhalení chyb/výkonnostních blbostí, na které doposud nepřišli.
Zdar Max

[deda.jabko]

Pominu to, že selecty lze v normální db logovat i bez zakoupení speciálního balíčku, ale překvapilo mě, že vývojáři nevědí, jaké selecty a v jakém počtu do db posílají.

Pokud pouzijes ORM, coz nekteri vyvojari povazuji za dobry napad, muze se snadno stat, ze si vyvojar ani nevsimne, ze tam ma nejake selecty, nebo ze jich je nekolik tisic na jednu operaci.

[Max]

...kdyby to bylo dobře udělané...

Což je právě ten nesplnitelný sen a hlavní problém.
Zdar Max

[Heron]

Ano, nikdy není dost času to udělat pořádně na poprvé, ale vždy je čas to neustále předělávat

[Max]

Kdysi dávno se migrovalo na Oracle z dbf souborů. Migrace probíhala tak, že co nefungovalo, se přepsalo, zbytek se nechal. To se bavíme o roku asi 2003. Od té doby se informační povědomost a zkušenosti programátorů zlepšili, ale jako každý velký a hodně starý projekt (v našem případě se bavíme o začátku někdy v roce 1993) v něm existuje pár špatných návrhů a věcí, jejichž náprava je hodně náročná.
V kombinaci s tlakem na nové fce je pak jasné, že některé věci jsou neoptimální. Nové věci se dělají už čistě, starší se přepisují/upravují když je čas, nebo když je potřeba (vyžaduje to implementace nové fce).
Celé je to tedy o prioritách, zda na rok zastavit vývoj a dát to do nějakého ideálního stavu, nebo přikoupit hw a tlačit dopředu nové fce a optimalizace dělat za pochodu.
Je třeba brát také v potaz, že nové fce = ušetření práce uživatelům, takže cena za silnější hw se vrátí v podobě menšího potřebného počtu zaměstnanců.
Teď k tomu tedy přibyl ještě nákup oné licence, ale jak už jsem napsal, není to jen o vývojářích, ale o lepším failoveru a dalších věcech.
Zdar Max

[tutanchamon]

Alza?

[Max]

Alza jede na MSSQL, ne?
Zdar Max

[tutanchamon]

jaaaj hej, spominam si clanok teraz k majovemu vypadku alzy :) A od juna hladali noveho riaditela IT oddelenia v Prahe. A Mrkvosoft sa k vypadku postavil tak ze nemaju premium support zakupeny tak nech sa staraju ...

[User682]

Tipnul bych to na HomeCredit nebo neco podobneho...

gf

[smazáno]

Pohoda?

[Käyttäjä 11133]

Max dělá v malé firmě; navíc HomeCredit má mnohem větší NetApp, než se kterým si hraje Max... :)

[Max]

Mno, nevím, zda je malá, nebo velká, část veřejně známých investic do nákupu pár věcí byla v poslední době asi 21 000 000 000 Kč.
Zdar Max

[Käyttäjä 11133]

To máš (skoro) jeden lék

[Max]

Sakra, sorry, možná nepochopil. Myslíš cenu vývoje nějakého léku?
Zdar Max

[Käyttäjä 11133]

JJ, vývoj nového léku se odhaduje na 1,5 - 2,5 mld. USD.

[Jeřdno]

Ministerstvo obrany?

[Max]

Ne, ale to je snad jedno, co jsme za firmu, ne?
Zdar Max

[Ondřej J]

Zvědavost je strašná věc :) Ale je to opravdu jedno. Každopádně díky za tyhle články

[alfa numlock]

a neprislo by nejake cloud riesenie (SaaS a HaaS) od amazonu, mrkvosoftu ci oraclu (whatever) lacnejsie ako sa drbat v dnesnej dobe so serverami, hw, licenciami, packmi a migraciami?

[Max]

Počítej ale, že všechna tvá data bude mít Oracle, budeš mu muset věřit a věz, že v ČR ten svůj cloud nemají, takže počítej s trochu většíma latencema (u nás většina klientů/služeb přistupuje do db lokálně). A levnější to bude jen do té doby, než se do toho cloudu dostaneš.
Zdar Max

[alfa numlock]

geograficka lokacia v dnesnej dobe uz nieje problem - vid cloudflare....

[Max]

Já jen říkám, jak to má Oracle, měli jsme do cloudu zkušební účet.
Migrace do cloudu by pro nás obnášela jednak migraci db a dále ipsec tunel mezi našemi pobočkami a Oracle Cloudem.
Stále máme tlustého klienta, takže jakékoli navýšení latencí je nepěkný výkonový propad.
Zdar Max

[xkucf03]

Pro nějaké cacheovatelné bloby (spousty souborů přenášených přes HTTP), které lze rozdistribuovat po serverech na celém světě ne. Ale věř, že pro transakční systémy to problém je a vždy bude (pokud se nepodaří překonat rychlost světla).

[xkucf03]

V první fázi možná, ale je to past. Spousta zákazníků už takhle naletěla. Z pohledu dodavatele dává SaaS ještě větší prostor pro vendor lock-in než „pouhý“ proprietární software. Je to vlastně takový proprietární software na druhou, protože pak dodavatel drží i data zákazníka a má k nim a k běžícím procesům přímý přístup, může ho kdykoli odstavit, mnohem účinněji vydírat.

[Josef Kufner]

Nebylo by v horizontu několika málo let levnější přejít na Postgres? Zjevně to nebude jednoduché, ale pokud cena licencí přesáhne cenu migrace, tak to z dlouhodobého hlediska dává smysl a mohla by to být investice s docela dobrou návratností.

[Max]

Před lety jsem tu možnost ještě viděl, ale teď už je to horší a bude se to jen zhoršovat.
Zdar Max

[Adolf Kernel]

Vendor lock-in...

[Max]

Postupem let se prostě naimplementovalo hodně oracle specific věcí a spoustu věcí běží v rámci db (packages, fcí, procedur atd.).

Samozřejmě něco z toho by šlo asi pokrýt pomocí EnterpriseDB a tou Oracle extension, co to má, ale určitě by to nebyla akce jen na pár měsíců.
Zdar Max

[Josef Kufner]

I kdyby to bylo na rok nebo dva, tak se to za dalších pár let může zaplatit. Udělat se to dá i tak, že se budou postupně odstraňovat/zapouzdřovat Oracle-specific věci a nebudou se přidávat další. A po nějakém čase bude ten systém na přechod připravený a ani to pak nebude moc bolet.

[Max]

Jak už jsem napsal, tla na nové fce je větší, než někde rok něco upravovat s cílem něco ušetřit. Příkladem budiž, že jedna lehce použitá pneu na jedno naše vozítko stojí asi 100kkč. A to autíko má ty kola 4 a těch autíček máme hafec. A toto je jen kapka v moři.
Zdar Max

[〹]

Osobně občas v práci odstřelím nějaký server a zkouším, jestli si toho někdo všimne. Když ne, je to zbytečné a lze to odstranit. Zkus to taky!

[Max]

Hehe, naši uživatelé jsou rychlejší než nagios :D
Zdar Max

[Käyttäjä 11133]

Dalším důvodem byl DataGuard, což je řešení, které umožňuje replikaci db na záložní stranu s téměř zanedbatelným rollbackem dat. Doteď jsme využívali k replikaci vlastní skripty, které kopírovaly rsyncem archivační logy do backup lokality, tam se pak pomocí cronu aplikovaly na standby db. Rollback dat byl pak cca 15min. S DataGuardem lze docílit mnohem menšího rollbacku a lze si vybrat možnost přenosu. Lze využít MaximumPerformance, kdy primární strana nečeká na potvrzení od standby (toto používáme my kvůli výkonu). O něco více pomalejší je pak režim, kdy primární strana čeká na potvrzení od standby, takže obě databáze jsou ve stejný čas 1:1. Režimů replikace existuje více druhů. Pak existuje něco jako Active DataGuard, který vylepšuje DataGuard jako takový, ale to je placená option (= pár stovek tisíc).

V roce 2012 jsme právě u jednoho klienta DataGuard nahrazovali za NetApp SnapMirror aby se mohlo přejít z Enterprise na Standard a ušetřit ranec

[Max]

Záleží, na jaký druh failoveru a časy se chce člověk dostat. Ještě v době standardky jsem chtěl naimplementovat sync transakčních logů v závislosti na inotify. Tzn. jakmile by se vytvořil file, hned by se spustilo kopírování. Otáčení logů by se pak nastavilo na nějaký mini čas. V takovém případě pak není ani potřeba ten NetApp.
Zdar Max

[Käyttäjä 11133]

V takovém případě pak není ani potřeba ten NetApp.

Byt to PS engagement na 50 MD, při ceně 2k GBP za MD ten NetApp stál méně, než jeho implementace... K tomu aby sis bastlil podobné věci potřebuješ taky kompetence, které očividně tenhle klient neměl, jinak by si na to nenajal nás...

[Bedňa]

Vždy si pri tvojích blogoch radšej počkám, na čas až to dám celé v kľude. Fakt úcta, že vieš problémy výborne rozobrať.

Ako toto vyriešiť?

Proste začal som sa meniť ja sám, schudol som 13kíl, zmenil zamestnanie a povedal si, že už nikdy nebudem pracovať vo firme kde ma sere fungovanie firmy.

Nechceš si to priznať, ale štve ťa to. Kámo závidím ti tvoju energiu a chuť sa z vecami na ktoré by som dnes už ani nešiahol. Chceš sračku, tak si ju rieš, ja tu nebudem. Pri tvojich schopnostiach sa uchytíš všade.

Ja som momentálne vyše mesiaca v Budapešti, som rád, som spokojný, možno potom inde. Proste život je jeden a podnes si vyčítam, že som veľkú časť minul na sračky a sere ma to. Tak sorry neverím, že ťa to nežere.