Názory k článku Migrace aplikace z Oracle do PostgreSQL

Moc pěkný článek. Oracle používáme a zatím si neumím představit, že bychom u hlavního projektu (ISKN) přešli na něco jiného. Využíváme hodně vlastností Oracle jako je Partitioning, Spatial, Virtual Private Database, RAC, XML DB, Advanced Security apod., což se na něco jiného migruje blbě (ale zase to přináší dobré vlastnosti, funkce a zjednodušení). U nás je ještě ten problém, že aplikace jede v Oracle Forms a Reports, což v podstatě jinou DB vylučuje.
Využívali jste nějaké takové speciality? Pokud ano, jak jste to při převodu řešili? Věřím tomu, že pokud se používají jen standardní věci, základní SQL, pohledy, package, tak to určitě rozumně migrovat jde (i když práci to dá).
Je to vždy dilema - když si pořídím produkt, tak ho využít do mrtě, ale za cenu, že se od něj budu hůře odpoutávat? Nebo na něm moc závislý nebýt, ale zase budu muset řešit spoustu věcí, které ten produkt sám umí (a určitě lépe).

Bottleneck na db jsou SQL příkazy - a těch pustíte stejně, ať používáte jeden aplikáč nebo deset nebo máte logiku v uložených procedurách. Zátěž db serveru je +/- stejná. Pokud máte logiku v uložených procedurách, tak vám odpadne část síťových latencí, ale to gro je stejné.

Logika v db neznamená, že v db děláte všechno - v db dělám jen manipulaci s daty. O prezentaci, komunikaci se mi stále stará aplikační server.

Proč, když to databáze umějí a správně napsaná aplikace nad SP bude vždy rychlejší - a (můj osobní názor) čitelnější - SP vás donutí do dekompozice - databázové věci řeším na databázi, prezentační, komunikační v aplikaci. Navíc SP vám umožní zabezpečení, které v aplikaci nikdy nemůžete dosáhnout.
K dispozici jsou debuggery, profilery, verzování, deployment - není rozdíl od jakéhokoliv programování. U Oracle PL/SQL se používá jeden z nejlepších a velice dobře navržených programovacích jazyků - je to založené na ADĚ - i když to Oracle trochu zkryplil.
Problém jsou programátoři - s Javou většinou začínali junioři - lidi s čistou hlavou. SP historicky psali vývojáři odrostlí na Cobolu, DBase, FoxPro - a nikdo jim dostatečně důrazně nevysvětlil, jak se má psát - prasí se i v Javě a to většina programátorů dneska nemá návyky z Basicu nebo C. Metodologie vývoje v SP jsou k dispozici od konce devadesátých let - ale v korporátech kvalita kódu je to poslední, co se řeší - přebírá se jakýkoliv kód, který nepadá - a pak většina programátorů nemá motivaci, znalosti, čas, zkušenosti psát čistě.
V týmu co jsem, chlapi přecházeli z PCFandu na Oracle - bez jakýho-koliv proškolení a to musí být vidět. Tak je to skoro všude, kde jsem byl, kde jsem se bavil s programátory.

Skoro mezioborový článek, nabušený unikátními poznatky! Poklad.

Pavle, klobouk dolů, že jsi se podělil! Moc díky.

Mimochodem, cítím v tom velkou příležitost inspirovat vývoj pg fíčurkami z ora, protože tam určitě nějaké šikovnosti jsou.

Nevím, nejsem autor článku a neumím ora ani pg natolik dobře. Lituju, ale s touto flamewar nepomůžu.

:) - některé zkušenosti/potřeby z tohoto projektu se promítly do nové verze Orafce, kde jsou částečně emulovány i některé systémové pohledy Oracle, což jsem původně nechtěl dělat - nicméně Orafce se opravdu primárně používá při portacích z Oracle a tato funkcionalita částečně pomůže.
Co se týče SQL - tam se moc inspirovat nejde - pro Postgres (nikoliv pro EBD) je cíl ANSI SQL - a tam je hromada možností - temporální tabulky, lepší podpora JSONu, .. Některé užitečné vlastnosti, které má Oracle, a které by se hodily ať už při samotném použití Postgresu nebo při portaci jsou v ToDo (jelikož zatím se musí používat workaroundy). Tady primárně to jsou schéma variables a autonomní transakce - kdyby byly peníze na vývoj a čas, tak bych se do toho pustil - pracnost na schéma variables odhaduji na půl roku relativně intenzivního vývoje - a na to nejsou zdroje.
Interní věci - tam se spíš přebírá z výzkumu - roky se dělá na hw akceleraci, poslední dva roky na integraci JITu. Tam je obecně velmi pomalý postup už při psaní prototypu (i výzkum není nějak daleko) - a výsledky nejsou zas až tak fascinující - pro běžný provoz zrychlení pár desítek procent nežene vývojáře k rychlejší akceptaci - přičemž reálně uživatelé preferují stabilitu a spolehlivost před novými vlastnostmi.

Děkuju. :-)

Chill out. :-) Obávám se, že jsi nepochopil můj původní příspěvek. Pavlovou odpovědí na něj jsem dostal mnohem víc, než jsem čekal, takže dobrý. Zmínku o flameware netřeba brát vážně.

Paradni clanek. Moc dekuji. Kdyby firmy, ktere plati za Oracle dali jenom polovinu toho co za to plati na vyvoj PostgeSQL, tak uz to mohlo byt uplne nekde jinde.

Podle slov autora byl Ora2pg rychlý hack, kdy šlo hlavně o to, jednoduše zmigrovat strukturu tabulek a data z Oracle do Postgresu - a šlo o to to udělat co nejjednodušeji a co nejrychleji. Potom se na to nabalovaly další věci a více-méně pro samotného autora šokující, co všechno se dá udělat sadou regulárů.

Reguláry fungují, ale není to kdoví jak rychlé - 200K řádků se převádí cca 100 minut (pořád je to použitelné). Tipnul bych si, že pokud by se použilo AST, tak by odpovídající migrace trvala 10 minut. Hlavně by asi kód Ora2pg byl výrazně čitelnější. To AST v plánu je - ale zatím autor nenarazil na limity stávajícího řešení, takže chce dokud to jde, pokračovat ve stávajícím kódu - a privátně si buduje testovací bázi, vůči které pak bude psát Ora2pg 2, která už bude na AST. Nevím, jestli to vyjde, ale předběžně se bavím s Gillesem, že by přijel na P2D2 2018 příští rok.

Pro tuhle aplikaci je to jediná šance. Oracle, kdysi poskytoval malým vývojářům velice zajímavé slevy, takže jejich produkty byly i nad Oraclem konkurence schopné. Ochota Oracle tyto slevy poskytovat výrazně klesá a bez nich je ten produkt neprodejný. Stejně tak rostou náklady na licence - produkt je určený pro prostředí, kde nejsou velké marže, dneska už je i docela konkurence a cena hraje primární roli. Takže buďto migrace do Postgresu nebo konec - a autoři mají ještě 15 let do důchodu. Cenovou alternativou by byla migrace do Oracle cloudu, ale to je nestravitelné pro významné uživatele té aplikace.

Migrace by byla výrazně jednodušší, kdyby ta aplikace byla čistě napsaná - pak je to skoro trivka, a dá se provést za několik málo týdnů i v takovém rozsahu. Teď se tam půl roku dělá refaktoring, který se předchozích 15 let nikdy nedělal.

Je to malá firma, která má jediný produkt a nemá moc alternativ - na druhou stranu tam není dosazený management - firmu si řídí vlastníci, kteří jsou docela v obraze, a technicky na tom jsou také dobře - jsou motivováni tu migraci udělat. Ve větších korporacích je to něco úplně jiného - hromada řečí - a viditelný progres je za tři, čtyři roky - není to značka, která je jim známá, a ošahání si nové (pro ně neznámé) databáze trvá - není to problém jenom managementu, ale i adminů, vývojářů. Pokud to není Oracle, tak je to pro ně podezřelé - ale už je tu pár podařených projektů v oblastech, kde by mne před 5 roky nenapadlo, že by se Pg mohl nasadit.

ROLLBACKy, SAVEPOINTy jsou v Postgresu implicitní - dané strukturou - většinou stačí přizpůsobit blokovou strukturu kódu a pak v Postgresu je zakomentovat (je to v ToDo Ora2pg). COMMIT je v Postgresu také implicitní - v podstatě je to aplikační záležitost - pokud nedojde k chybě, tak při autocommitu se se commituje automaticky.

Záleží na důvodu proč v kódu používáte COMMIT - ve většině případů jej stačí pro migraci do Postgresu opět zakomentovat (Ora2pg to při migraci může udělat). V aplikaci, kterou jsem migroval se pouze v jediném případě nějak aktivně používal opakovaný COMMIT v procedůře - a bylo to z důvodu pádů příliš velkých transakcí na Oracle - což v Postgresu není problém, takže vnitřní COMMIT v proceduře jsme v Postgresu mohli ignorovat.

Ora2pg umí vyřešit i bezpečné porovnání na prázdný řetězec - nicméně výsledný výraz je výrazně delší, takže je jednoduší opravit kód na Oracle, tak aby se mohl 1:1 použít i na Postgresu - tj na Oracle nepoužívat prázdné řetězce, ale pouze NULL (v IF a pro jiné datové typy než je varchar). Je to asi masivní změna, ale dá se to udělat hromadně - takže i při statisících řádcích je to práce na pár pracovních dnů.

Netvrdím, že migrace aplikace, která často používá silně Oraclovské obraty je na lusknutí prstu - ale je realizovatelná - a kromě toho, že se připraví port do Pg, tak se i hlavně zásadně pročistí kód v PL/SQL.

Pokud by kód v PL/SQL (Oracle) byl napsaný podle moderních best practicies, tak pak migrace je docela jednoduchá. Když se použivají deprecated výrazy, obsolete funkce, tak je to výrazně pracnější - prvně je potřeba modernizovat (vyčistit) kód v PL/SQL a pak poté provést migraci.

V některých případech to může být pro uživatele, vývojáře příliš drahé - pak je alternativou EDB, kde jsou alespoň poloviční a nižší licenční náklady a je tam vrstva, která emuluje Oracle, anebo aplikace musí dožít na Oracle.

EDB je v jádru Postgres - vrstva kompatibility s Oraclem není příliš tlustá - úplně emulovat Oracle nelze - ale nejčastější balíčky a PL/SQL emulují v zásadě dobře. Určitě je tam nějaký posun. Určitě ne každá aplikace poběží bez úprav na EDB, na druhou stranu těch úprav nemusí být zase až tak hodně.

To je dobrá připomínka - díky za ní.

V SQL prostředí ten nástroj, který bych měl používat proti duplikování kódu nejsou funkce! K tomu slouží pohledy - což hromada programátorů nepochopila -svoje znalosti přenášely do prostředí SP 1:1 z klasického programování - případně z Cobolu, FoxPro, kde pohledy neexistovaly - jde o nesprávné uchopení technologie - navíc v tomto případě s potenciálně fatálními důsledky.

Jde o to, jestli je úloha matematicky komplexní nebo datově komplexní - pokud generuje větší množství dotazů, případně dochází k přesunu většího objemu dat mezi klientem a serverem, pak mají uložené procedury smysl - cílem je minimalizovat komunikaci mezi databází a klientem - a vytvořit sémantické API pro klienta.
Jinak uložené procedury už dnes běžně umí notifikovat klienta - v případě změn dat, aby provedl refresh.

Sry za trochu zneužití této diskuse. Ale jsou tu Ora i Pg experti a mluví se tu o výkonu a Pavel nyní zmiňuje čekání na IO.
Můžete pls naznačit své zkušenosti, jak zatěžovaným databázím pomůže jejich umístění na SSD disky?
Dík.

Nazdar chlapci prisel jsem se na vas podivat, autor mne zklamal misto aby delal karierni postup a vydelaval poradne prachy jak jsem mu pred 5 lety navrhoval, tak pokracuje v aktivitach na kterych se nedaji vydelat penize. Proc cilit na zakazniky kteri neutahnou ani licenci Oracle? Jak pak mohou zaplatit za kvalitne nacenene IT sluzby? Je potreba se v kariere posunout dal a hry o drobne prenechat malym detem. Doufam ze si spolu rozumime v tom ze penize jsou pozitivni vec.

Postgresql je minoritni databaze, neznam zadneho z nasich zakazniku ktery by ji pouzival v produkci. MySQL pouzivaji protoze to podporuje Oracle, ma to kvalitne zmaklou replikaci a clustering, Je to levne (uspori se 90% nakladu oproti Oracle).

Je tu nejaka vetsi a solidni firma co by delala podporu a poskytovala zaruky na PostgreSQL? Je tu EDB ale ti nejsou ochotni verejne sdelit ceny, kazdou delaji individualne a fixaci ceny nabizi jen na 3 roky. Jednat s podobnymi spolecnostmi se mi uz mnohokrat silne nevyplatilo, protoze mi nabidli pokracovani smlouvy za podstatne vyssi (i 10x cenu) kdyz zjistili jaky delame obrat. Prachy jsem jim stejne nikdy nedal a premigroval.

Ze stored procedur jsem byl nadsen v 90 letech, tehdy jsme je delali v embedded SQLC, dneska je pouzivame jen z duvodu vykonu po dukladne performace analyze - je v nich asi 1% logiky. Tohle neplati pro mainframy, tam se v psane v COBOLu pouzivaji vice a i to je jeden z duvodu proc vyvoj na mainframech je zhruba 20x drazsi.

Ty pořádné peníze mi nestojí za to, abych byl, víc než chci, namočený v korporátu. Řeší se tam problémy, jejíž řešení mne nebaví, a na to, aby člověk mohl být kreativní, tak bych musel být asi v Oracle, nebo v MS - jinak se blíž člověk k technologii nedostane. Co jsem slyšel o Oracle, tak tam bych asi určitě dlouho nevydržel. Takže tak.

To, že Vaši zákazníci nepoužívají Postgres, to neznamená, že by byl Postgres minoritní db. Díky BSD licenci se na ní nedají moc vydělat peníze (ohledně licencí a supportu) - takže ve spojitosti s Vašemi názory mne to vůbec nepřekvapuje. Navíc, pokud někdo používá db jen jako storage, tak MySQL může být optimální.

Support Postgresu - RedHat, v ČR Elostech, globálně 2nd quadrant, PostgreSQL Pro. Když máte tolik peněz, tak si zaplaťte dva - tři top vývojáře Postgresu, budete mít špičkovou podporu z první ruky - dělá to tak hromada firem.

Nebrec ze se ti nelibi makat pro korporaci. Zrovna tobe jsem nabizel ze ti pomuzu se zalozenim startupu nabizej jsem ti 30% a 2 mega. V zivote neni mnoho momentu ktere dokazi zmenit tvuj zivot - tohle byl jeden z nich. Bylo to v dobe kdy se IBM snazilo procpat svym zakaznikum PGSQL, udelalo prirucky, skoleni, podporu migraci - no ukazalo se ze to byl fail a jejich zakaznici na to neslysi.

To byl dalsi z dukazu ze se na PGSQL vydelat neda. Na postgresu zdechlo uz neuveritelne mnozstvi i velkych firem. To je jako podnikat na pousti kde se vali kosti. Zdechnula Great Bridge, Sun, IBM. Je videt ze o tento produkt nemaji zakaznici zajem. On to totiz neni produkt protoze nema veci co cini produkt produktem, je to technologie. Technologie se prodavaji licencovanim, coz nejde kdyz je technologie k dispozici bezplatne. Jedina zivotoschopna firma delajici PGSQL je EDB protoze v ni ma IBM zainvestovano 20 mega a postara se aby nepadla.

Podivej se na FreeBSD. Tuhle technologii pouziva rada veci - ibm, juniper, cisco, playstation, nitendo, apple. Je to spatna technologie? Evidentne ne. Da se vydelat na FreeBSD jako na produktu? Ne. Jediny zpusob jak na ni neco vydelat je to vzit a postavit si neco nad tim a to pak prodavat. Technologie je zdarma, usetri se za licencni poplatky.

To co ty nabizis za reseni - zamestnat vyvojare jako support jen dokazuje jak je maly tenhle trh. Tech vyvojaru moc nebude, pro support potrebujes aspon 3. Na kolik firem by se timhle zpusobem dostalo? A kolik vyvojaru je ochotno delat misto programovani 247 support?

Dival jsem se na 2nd quadrant a na PGSQL pro. Taky nemaji verejne ceny, chteji aby zakaznik s nima navazal vztah a pak mu sdelili jejich tajnou cenu. Kdyz nevi za kolik vlastne prodavat, jak jim mam verit ze se v byznisu udrzi. Pocet lidi co by si koupili PGSQL je maly a oni jej jeste snizi tim ze vyzaduji tuhle ceremonii s navazovanim vztahu. Pletou si byznis s manzelstvim, byznis je o cislech. Vsechny 3 firmy maji svuj fork PGSQL ktery se snazi prodat jako svuj hlavni produkt, koupit si fork udelany malou firmou a vyrazit s tim do produkce je jeste vetsi riziko nez vyrazit se stock pgsql - co kdyz firmicka krachne? To budeme prepisovat aplikaci? Proc jit do tohodle rizika kdyz nemusime?

Ted si vem ten tvuj pripad. Mas zakazniky co nechteji platit za Oracle a ani za EDB ktera je levnejsi a migrace by byla mnohem snadnejsi. Evidentne jim nejsou schopni prodat databazi s nenulovou cenou jako soucast reseni. Cil je nejak to doklepat dalsich 15 let. Nikdy nevydelas dostatek penez abys mel na investice do rozvoje protoze tvy zakaznici penize nemaji. Takze pracujes za naklady diky neschopnemu managementu ktery nema koule na to poslat neperspektivni projekt k zemi a jit delat neco pro lidi kteri maji penize na zaplaceni.

Ja proste nevidim zadnou pozitivni vec ktera by mne presvedcila ze mam do PGSQL jit. Napis mne 3 duvody ktere mne podle tebe presvedci ze je to nejlepsi mozna volba. Pro mne je to hobby.

Asi vůbec netušíte, o čem tu píšu a co a proč dělám - opravdu 30% a 2MB není nic, co by mně oslovilo.

Berte to tak, že Postgres je životní styl, jako Linux, nebo BSD .. buďto vám sedne a baví vás v něm psát, používat jej, nebo ne. Je to sw, se kterým můžete věci dělat jednoduše a po svém - a dobře a slušně - protože máte možnost se podívat na to, jak je napsaný, máte možnost se bavit s vývojáři, máte možnost se podílet na vývoji - a to aktivně nebo pasivně. Nemusíte řešit komplikované licence, a nemusíte biflovat checklisty a pohled do zdrojáku, možnost si něco odladit nebo se zeptat autorů je za desítky stránek dokumentace, takže nemusíte ani biflovat mraky dokumentace. Prostě s Pg je život jednoduchý - což je to, co mi vyhovuje. Nemusím se bavit s obchodníkama - bavím se s inženýrama.

Jak IBM, tak další korporace Pg používají - jedním z největších uživatelů je Microsoft nebo Cisco. Pro ně je Pg dostatečně dobrá databáze. Do jisté míry Postgres je alternativa - je to projekt, který nemůže krachnout - je to alternativa ke korporátnímu způsobu uvažování a chování - a buďto jste zaháčkovaný v korporátu a asi těžko budete hledat motivaci pro použití Postgresu, jelikož na licencích fakt nenaděláte těžký prachy nebo hledáte alternativy - takovou alternativou, přičemž ale technicky na úrovni (každý si může zkontrolovat kód), je Postgres (v oblasti SQL relačních DB).

Je to [MySQL] levne (uspori se 90% nakladu oproti Oracle).
To jako vážně nějaký váš zákazník uvažoval o Oracle DB, a pak místo toho pořídil MySQL? To je jak porovnávat formuli jedna s tříkolkou. „Ano, uvažovali jsme pro naší tříletou Matyldu o monopostu F1, ale pak jsme si řekli, že ušetříme, a pořídili jsme jí tříkolku.“

Jo byla to zdravotni pojistovna, asi 35M klientu. Pri jednom z upgradu sw co jsme jim delali se jednalo o koupi noveho HW (ten stary mel 10 let, fungoval spolehlive) a manageri zacali strasne knourat jak nemaji prachy na provoz a ze to chteji co nejlevnejsi a ze jsme podle jejich nazoru drazi. Tak se rozhodli ze misto Oracle chteji MySQL a misto IBM RISC chteji Windows Dell PowerEdge cluster. Ja jim nato ze si musi udelat load testy a smlouvu o podporu HW, OS, Database s garanci. Tvrdili ze to vsechno maji, no tak dobre, tak jsme u nas prehodili ORM na MySQL a zkouseli zda to jde, ono to neslo protoze MySQL melo bugy, ale kdyz jsme upgradovali MySQL na posledni verzi tak unit testy prosly bez problemu. Sice se jim nelibilo ze nebudeme pouzivat tu verzi MySQL co tam nainstaloval admin a na kterou maji podporu, ale kdyz videli ze to opravdu jinak nejde tak na to kyvli.
Vzhledem k tomu ze na teto platforme negarantujeme nic z provozu, jen to ze projdou nase testy, tak jsme s nimi v kontaktu uz nebyli. Prisel jsem na pobocku jako client - system nejel pry uz 2 dny, pak jsem prisel za par mesicu to jim slo, na dalsi navsteve jim to opet nejelo. Tak jsem zmenil pojistovnu. Pak uz od nas nechteli ani SW zdali jsme se jim drazi.
Pred 3 lety jsem se nahodou potkal s klukem ktery vedl tym co tehle pojistovne delal sw servis. Brecel jaci jsou to drzgresle ze si nemuze dovolit koupit ani sw na load testing za 15000 USD protoze z tech penez co plati sotva zaplati lidi kteri makaji vyhradne na open source sw.

Pritom jsem zjistil ze jednak pojistovna pouziva nas SW bez licence, a chlapec ma k dispozici ostra data pacientu. Takze jsem zazaloval oba dva. Chlapec i pojistovna dostali pokutu za nelegalni pouzivani SW a pojistovna i chlapec dostali basu za neopravnenou manipulaci s daty pacientu.

Pojistovna se dostala do problemu a investor tam musel nasypat dalsi prachy, tak si se mnou dal schuzku zda bychom to neudelali jako predtim. Rekl jsem si o 50 Mega USD za 10 let - blackbox reseni vcetne HW, pojistek etc. To se mu zdalo moc a vykopnul mne s nadavkama. Za par dni volal ze by chtel schuzku - ja jsem mu rekl ze na zadnou nejdu, neumi se chovat a ze moji nabidku kterou nechtel jsem stahl. Nechtel moje reseni a tak ho taky nema - v cem je tedy problem. Rikal ze si nechal udelat konkurecni nabidku a tam chteli 12 mega rocne, tak jsem mu to nakonec dal za 10 mega rocne s tim ze v cene budou i prazdniny pro management no a vzal to.