Átszokás Oracle-ről PostgreSQL-re - Kövendi-Veress Gábor (Mito)

Célja a tapasztalatcsere. Semmiképpen sem szeretném összehasonlítani és szembeállítani őket, mivel a felhasználási területük különböző, és egy 1-1 elleni összahasonlításban nyilván nem nyerhet a PostgreSQL. Viszont érdekes téma, hogy amikor az egyikről hirtelen a másikba csöppen az ember, milyen problémákba futhat bele, amik nem triviálisak. (Kezdve az SQL szintakszistól (hintes joinok hiánya), az indexelés relevanciáján át (Postgre-ben indexelni... kétes eredményességgel jár), egészen az anomáliákig.

Transcript

1. Átszokás Oracle-ről PostgreSQL- re Hogyan építsük le az idegrendszerünket 30 nap alatt   Kövendi-­‐Veress  Gábor  
2. Első akadály: Management eszközök •  Oracle: Quest Toad Quest SQL Navigator PL/SQL Developer •  PostgreSQL: pgAdmin (korlátozott használhatóság) Navicat for PostgreSQL EMS SQL Manager for PostgreSQL
3. Process management •  Oracle: Ha beragadt valami, akkor célszerűbb operációs rendszer szintjén kilőni. Van, amikor SQL-ből is leállítható, de a tapasztalatok szerint ritkán sikerül feloldani. (Viszont ritkábban ragadnak be például queryk, mert azok leállíthatók). •  PostgreSQL: db-ből többnyire minden feloldható. Ha nem, akkor itt is le kell menni operációs rendszer szintjére. Sajnos egy elengedett query gyakran nem állítható le.
4. Jobok •  Oracle: Jobok: beépített funkció, jól használható. •  PostgreSQL: pgAgent: utólagos komponens, csak pgAdminnal managelhető (1.9+). Működésre jó, de több problémával szembesülhetünk: -Gyengén managelhető -Esetleges beragadás feloldása nehézkes.
5. Backup/Restore •  Oracle: Rman: jól működik, de körülményes, elavult, és lassú. (Ha valaki nem gyűlöli szívből kérem tegye fel a kezét...) •  PostgreSQL: pgDump: jól működik, egyszerű, aránylag gyors. Igaz más elven működik, és nagy adatbázisoknál (100Gb+) biztos hogy nagyon lassú (valakinek tapasztalat?)
6. Szintaxis,  anomáliák  
7. Hintek hiánya Alapvetően ízlés dolga, de sokkal lazább és könnyebben variálható, mint az „oldschool” SQL. Left join Oracle-ben: select    cust.customer_id,    cust.customer_name,    task.contract_id,    task.contract_desc,    serv.service_code,    serv.type_desc,    serv.fee_huf   from    customers  cust,    contact  task,    service  serv   where    cust.id=task.parent_id(+)  and    task.id=serv.parent_id(+)  
8. Hintek hiánya Klasszikus megoldás:   select      cust.customer_id,    cust.customer_name,    task.contract_id,    task.contract_desc,    serv.service_code,    serv.type_desc,    serv.fee_huf   from    customers  cust    left  outer  join  contract  task  on    cust.id=task.parent_id    left  outer  join  service  serv  on    task.id=service.parent_id  
9. Joinok, performancia. Maradjunk egy kicsit a left join-nál. Oracle-ben (és minden másban) alapvetően megszokott, hogy a halmazműveletek lassabbak, mint egy bármilyen összekapcsolás. PostgreSQL-ben az a tapasztalat, hogy a left-right join performanciája annyira rossz, hogy ugyanazt az eredményt halmazműveletekkel sokkal gyorsabb elvégezni.  
10. Joinok, performancia Példa: select   cust.cust_id,cust.customer_name,task.contract_id,task.des cription   from   customer  cust   left  outer  join  contract  task  on  cust.id=task.parent_id     Helyett:
11. Joinok, performancia (select   cust.cust_id,cust.customer_name,task.contract_id,task.description   from   customer  cust   join  task  on  cust.id=task.parent_id)   union   (select  cust.cust_id,cust.customer_name,null,  null   from   customer  cust   where   not  exists  (select  1  from  contract  task  where  task.parent_id=cust.id))     A fenti módon megírt selectek futási ideje sokszorosan rövidebb, mint a left join. Az ok ismeretlen, a végrehajtási terv szerint a sima join kellene, hogy gyorsabb legyen.
12. Indexelés Minden –nagy adattartalommal rendelkező- adatbázisnál probléma lehet, hogy az indexelés ellentétes hatást vált ki lekérdezéseknél, mint amit várnánk tőle. (100 millió+os táblák esetén általában, db platformonként változó). PostgreSQL esetében sokkal kisebb adattartalom mellett is megfigyelhető, hogy nem segít az indexelés a futási időkön. (már 300-500.000 sortól!).
13. DB Link Meg kell emlékeznünk az adatbázis linkekről is, amely sajnos a PostgreSQL-nek nem nagy fegyvere. A kapcsolat létrehozása könnyű, de lekérdezés a távoli adatbázisból körülményes, nincs visszajelzés, ha valami mégsem jó. Példalekérdezés dummy1 távoli DB-be: SELECT  dblink_send_query(‘dummy1',  'SELECT  *  FROM  foo  WHERE  f1<   3');     Elég körülményes...
14. Azért fel a fejjel! Ne feledjük, hogy a PostgreSQL egy ingyenes adatbázis platform és annak kiváló! Amellett, hogy az elmondott akadályokba ütközünk, mindig van megoldás, és ha nem Oracle-re vagyunk szokva, akkor valószínűleg nem is éljük meg problémaként ezeket. Alapvetően működik, még adattárházként is. Tehát ha low budget mellett kell egy jó adatbázist építenünk, bátran ajánlom mindenkinek, azoknak is ,akik az Oracle aranykalitkájából repülnek ki, mint jómagam J
15. Kövendi-Veress Gábor g.kovendi@mito.hu Köszi  a  figyelmet!