Názory k článku Čtení prováděcích plánů v PostgreSQL
-
Škoda že si nevybavujete spíše ty odpovědi :-)
Firebird samozřejmě vždy zohledňoval náklady na zpracování indexu. Ono by to bylo dost divné zohledňovat náklady na čtení dat ale už ne indexů, a takového opomenutí by si za těch více než 20 let jistě někdo z vývojářů všiml :-) Pravdou ovšem je, že Firebird zdědil poměrně hrubý vzorec na výpočet nákladů, takže ho bylo nutné zpřesnit, a do verze 2.0 neměl statistiky pro částečné klíče kompozitních indexů (a doposud nemá histogramy). Rovněž se vylepšovalo vyhodnocování vhodnosti indexů a optimalizátor obecně, a všechny tyto úpravy vskutku započaly s verzí 1.5, takže právě v této době byla v konferencích spousta dotazů na detaily optimalizace.
Problémy s optimalizátorem má ovšem každá databáze, protože cost-based optimalizace není dokonalá (o rule-based nemluvě), takže frekvenci dotazů ani existenci problémových oblastí nelze považovat za důkaz absence optimalizace :-) -
Bohužel ty odpovědi si fakt nepamatuji - verze Fb 1 a 1.5 mám spojené se slabší optimalizací, a verze řady dvě jako verze, kde tento problém byl nějak vyřešen. Absolutně souhlasím, že problémy s optimalizací jsou všude, včetně PostgreSQL - a řeší se, a asi se ještě budou dlouho řešit. Docela mne překvapilo, kolik změn se letos udělalo na optimalizaci v pg8.4, a to se ještě nezačala řešit otázka závislých sloupců. Zrovna tak se dost překopává optimalizace v MySQL. Moje poznámka byla spíš míněna jako varování před zastaralou verzí Firebirdu, nikoliv před Firebirdem samotným. -
Jan Molič (neregistrovaný)Ačkoli zrovna nyní s postgresem nedělám, je dobré vědět, že na první pohled dva triviální dotazy nemusejí být stejně výhodné. Na hostingovém serveru často zjišťuju, co jsou lidé schopni napsat, vycházejíce z předpokladu, že databáze si s tím nějak poradí (výpis katalogu eshopu 30 sekund není tudíž "nic nenormálního" :-))
-
xxx (neregistrovaný)zatim jsem se moc nemusel zabyvat efektivitou sql dotazu, mam ale obavy, ze budu
muset v praci zacit :-(
nebylo by marne srovnani jak vyhledavaji ve velkych objemech dat ruzne systemy
na uschovavani dat. srovnani sql databazi, klasickych filesystemu, nastroju pro xml.
protoze bych si tipnul, ze nejake hledaci algoritmy se budou pouzivat
ve vsech techto oborech. -
Jako cluster index jsem myslel to, co se používá v MS SQL serveru nebo v InnoDB. Zdeněk Kotala mne upozornil, že v Oracle se tato vlastnost jmenuje Index Organized Tables. Postgres pod příkazem CLUSTER nabízí fyzické seřazení záznamů v tabulce - k seřazení dochází pouze jednorázově - při provedení příkazu. Žádnou speciální statistiku si pg neudržuje - CLUSTER provede pouze jednorázové změny, a časem (díky změnám v tabulce) dojde k porušení pořadí. Tudíž CLUSTER má smysl u ro tabulek nebo u tabulek, kde dochází k minimálním změnám.
-
LENIN POWER! (neregistrovaný)jestli pgsql neco chybi tak to rozhodne neni rychlost, ktera je pro OLTP workload srovnatelna s Oraclem. V OLAP workloadu na ne pgsql nema: pomalu sorti, pomalu joinuje a neumi ani OLAP queries. V oblasti velkych db taky ne, protoze nema hodne funkcionality potrebne pro efektivni spravu velkych db.
-
Zdenek Kotala (neregistrovaný)
No myslim, ze si v prvnich dvou vetach trochu protirecite. Ale ano mate pravdu, ze Postgres neni stejne rychly jako Oracle, ale to si kazdy musi rozhodnout sam, zda mu ta rychlost staci a nebo zda investuje usetrene penize za licence a koupi lepsi zelezo. Podle pruzkumu 80% aplikaci vyuziva pouze 30% vlastnosti enterprise databazi.
Co se tyka tech OLAP queries tak neco by se melo objevit jiz v 8.4. A pro datove sklady existuje bizgress, coz je upravena verze postgresu na zpusob Teradaty.
Zajimalo by mne co myslite velkou databazi a jakou klicovou funkcionalitu Postgres nema?
-
LENIN POWER! (neregistrovaný)pro workload ala lamp Webaplikace na male db stejne rychly je. asi pred tydnem jsme si delali benchmarky ktere to potvrdili. Realna rychlost pgsql8.3 a db2 9 byla uplne stejna pro interaktivni workload. takze rychlost pgsql rozhodne nechybi. Oracle byl pomalejsi, ackoliv ne moc vyrazne, tak o 20%. MySQL 4.1 bylo nejrychlejsi ale ne o moc, tak o 20% oproti pgsql.
pomalejsi je pgsql ve velkych sortech a joinech (rekneme na result setech 40m a vice radek), ale zase ne tak vyrazne, zhruba o 30-40%. zejmena hashjoiny v pgsql jsou velmi pomale pokud se nevejdou do pameti.
pri testovani se db2 nedovolilo aby rozhazovala zatez z 1 klienta mezi vice CPU, to by pak postgres vyklepla, protoze ten to neumi.
pod pojmem velka db si predstavuji databazi obsahujici rozumne velike tabulky, takhle
tablice ma treba ~ 740GB (coz je natolik malo ze se jeste nevyplati saskovat s table partitioningem)
C:\IBM\SQLLIB\BIN>db2 select count(distinct day) from adwords.searches
1
-----------
505
Bylo vybráno 1 záznamů.
C:\IBM\SQLLIB\BIN>db2 select count(*) from adwords.searches where day = current
date - 1 day
1
-----------
55810561
Bylo vybráno 1 záznamů.
Ted koukam ze tablice je nekomprimovana, nanestesti odhadovany space saving rowcompestimate table je 30%, coz mne dost zklamalo, cekal jsem tak 50%.
Take bych si pral zpracovavat takova data, co se smrsknou o 85% jako SAP tablice:
ftp://ftp.software.ibm.com/software/data/pubs/papers/DB2-SAP-compression.pdf
Ja bych tak rad premigroval SAP z Oracle na DB2... nanestesi se to neda udelat uplne bez downtime a my proste bez toho SAPu neprezijeme ani chvili, navic je tu riziko ze downtime bude vetsi nez se puvodne planoval a nejsme nespokojeni s Oracle/SAP ze by byl spatny, ale ze DB2/SAP je lepsi. Mohl bych to zkusit 1.ledna 2009, to snad zakaznici pochopi, kdyz jim to oznamime 3 mesice dopredu.
http://www.sapusers.org/newsletters/2/files/Migrate_your_SAP_solutions_to_DB2-Nov06.pdf -
Zdenek Kotala (neregistrovaný)No je pravda, ze tuplestore (takovy swapfile na radky) by si zadal vylepseni. Co se tyce toho rozlozeni zateze na vic CPU to je znacna slabina a je to jeden z cilu pro vyvoj do dalsich verzi. Velikost tabulky v PostgreSQL je omezena 32TB, coz zatim asi nikdo nezkousel :-) nicmene mame zakaznika co ma 2TB tabulku (+3TB v TOAST) bez partitioningu. Funguje to dobre i kdyz to neni uplne svizne.
-
LENIN POWER! (neregistrovaný)Nezlobte se ale radit podnikum (zakaznim v kategorii nesocek) aby si misto Oracle/Db2/mssql vzali zadarmo pgsql a za usetrene prachy za licence koupili lepsi hw muze jen ten kdo ma s IT velmi male zkusenosti nebo ten kdo je silne zainteresovan na prodeji HW.
Zeptejte se Oraclistu (v CR asi nejpocetnejsi skupina z techto db) proc preferuji prave Oracle. Najdete si zde thread LO, LP vs Stehule o tom zda je OSS database vhodna pro vetsi projekt. Je to totiz prilis rizikove a usetrene penize za licenci tohle nevyvazi.
Nedostatky pgsql jsem zde uz dostkrat rozebiral, zkuste vyhledavani. Ja vim ze diskuze s lidmi od Sunu nemaji cenu, absolvoval jsem jich uz mraky a oni moc dobre nechapou realne potreby zakaznika, ziji uplne v jinem svete.
http://www.mysql.com/tcosavings/ -> a ted maminko jeste tu o panu bendovi a o jestircich. Problem je ze lidi opravdu te masazi od Sunu uveri a pak jejich IT podle toho vypada. Pak prijdou k nam s tim svym hnojem a prosi abychom jim to predelali, coz se nam moc nechce, protoze mame prace vic nez stihame, tak si zakazky vybirame.
http://forums.mysql.com/read.php?60,190734,192723#msg-192723 -
Těchto diskuzí tu bylo několik - myslím si, že nemá cenu znovu argumentovat.
http://www.root.cz/zpravicky/prague-postgresql-developers-day-2008/
http://www.root.cz/zpravicky/dubnovy-termin-skoleni-postgresql/
Doporučuji si nepřehlédnout poslední dva příspěvky Radima Koláře
http://www.root.cz/diskuse/2927/204356/vlakno/#o204742
Z mého pohledu cca do 100G databází nejsou s PostgreSQL nejmenší problémy - PostgreSQL se používá i pro 24/7 systémy. Instalací nad 100G je minimum (v poměru k menším než 100G). Já sám se setkávám poměrně často s použitím PostgreSQL jako backendu k request tracker systémům středních podniků (cca do 500 zam) a jako backend ve větších e-shopech. Vím o fakturačních systémech v pekárnách, nemocnicích (ale i ve strojírenství), které běží nad Postgresem. Sám jste argumentoval relativně dobrým výkonem v OLTP. Což je primární segment užití pg - pro OLAP v Pg chybí podpora - budoucí analytické dotazy nebo CTE na tom moc nezmění. To je segment, kam se PostgreSQL netlačí. -
LENIN POWER! (neregistrovaný)Vas zpusob vyvoje SW je neefektivni. Vy ho sice povazujete za efektivni, ale to je dano tim ze jste inzenyr a ne manager a proto nevidite veci v sirsich souvislotech, ktere zahrnuji kuprikladu vynalozene naklady na lidskou praci, ztrata zpusobena nefukcnosti reseni, cas k realizaci, naklady na udrzbu. Proste spatne pocitate TCO a chybi vam management rizik.
Vzhledem k tomu ze pro pgsql soft prakticky neexistuje, tak predpokladam ze si vsichni zde vyse jmenovani nakodovali reseni inhouse. To je ale dost drahe a neni tu zaruka ze se to vubec uspesne dokonci. -
honzak (neregistrovaný)...reseni inhouse. To je ale dost drahe ...
ja uz delsi dobu sleduji vase vyplody a musism se priznat, ze tomu vasemu humoru nerozumim. To ze nikdy nepouzivate ironie-tags mi ani nezarazi, to patri k nasi ceske mentalite, presto si myslim, ze je vas humor tak zastreny, ze si nekteri zde mohou myslet, ze to myslite vazne. Navrhuji nejake stylisticke gramatikalni prostredky - slangove slovo, citat nejakeho americkeho herce a nebo neco podobneho, abychom se mohli proste neceho chytit a presne vedet na cem jsme.
Jinak k te vete nahore .... nemohl by jste nam prozradit, co stoji auto. -
LENIN POWER! (neregistrovaný)moje posledni auto stalo asi 32 klacku, mne auta nezajimaji, jinak bych si asi koupil neco drazsiho. Tedy jezdim v jedne licenci Oracle EE.
Jo krome auta mam jeste dve cryrnohe kocky, jednoho psa, spanelsky mluvici sluzku a cernocha zahradnika. Doma mam 2 notebooky, 3 pocitace a 12 Mbit DSLko. Barak ve kterym bydlim stal 450klacku. Dane platim, optimalizaci dani si ale sam nedelam. Dvakrat do tydne chodim strilet a v nedeli jdu do kostela a pred kazdym jidlem se poctive pomodlim. Rano cvicim a do prace jezdim autem. Z televize posloucham CNN a Discovery. Sluzku nebiju.
Potrebujete jeste neco vedet? Klidne se zeptejte. -
Pavel Stehule (neregistrovaný)Ja take netvrdim, ze PostgreSQL je idealni - chybi OLAP, chybi JDBC2 napriklad, implementace partitioningu je stale primitivni, online zalohovani je docela alchymie. Nicmene pro celou radu uloh se kterymi se setkavam, vyhovuje a osvedcuje se. Zalezi na usudku designeru, analytiku, programatoru, jestli PostgreSQL doporuci nebo ne.
-
nez se mi zmrsil post, mel jsem asi 35 bodu co se mi nelibi na pgsql. Krom toho ja vim ze neni vule tyhle problemy resit a kdyz delate velke projekty tak ty veci opravdu desne vadi, takze pgsql pro velke projekty se sice pouzit da, ale je to vicemene nouzovka nebo pozadavek zakaznika, ktery si mysli ze usetri, coz neusetri. Fajn budeme mit CTE a OLAP ale to nejak vyrazneji pozici pgsql mezi EE db nezlepsi. No a rozpocet velkych projektu ten uz vam dovoli si Oracle za $15k koupit, protoze je to kapka v mori, vzhledem k cene lidske prace.
Ja jsem s pgsql delal opravdu dost velky projekty, ale dneska po tech 5+ letech zkusenosti s nim bych ho jiz pro tenhle druh aplikaci nepouzil pokud by ho zakaznich neprosazoval. Neni to dobra volba. Existuje ovsem rada projektu kde by nevydelaly ani na licenci Oraclu, o jeho provoznich nakladech ani nemluve a tyto projekty by bez mysql/php/pgsql ani nevznikly.
Napriklad podpora toolu je v postgresql uplne tragicka, dale podpora profi zalohovacich systemu neni, pgsql nemi delat XA TM, SQLJ neni, diky flaky JDBC2 driveru nefunguji ani takove zakladni tooly jako BIRT i kdyz pravda reportovaci tooly pouzivaji casto JDBC3 api pro databaze metadata (ktere pgsql driver neumi).
Krom toho vyvojari pgsql nikdy nerespektuji de facto standardy dane Oraclem (kuprikladu jak se ma databaze semanticky chovat pro zamykani updatable cursoru). Kdyz si treba vezmeme zamykani v databazich tak kazda z db pouziva jiny model, zamykani dat je kriticke pro obranu pred races a prepisovat zamykaci model je pomerne narocna prace, protoze se to musi delat velmi peclive.
oracle (zamyka nejvice)
db2/cloudscape
firebird
postgres (zamyka nejmene)
Neexistence hintu dost vadi, nemuzete zamykat access plan aby se dal garantovat service level, replikace je primitivni, smutnym faktem je ze z replikaci pro pgsql je slony nejlepsi a neumi ani tak zakladni vec jako si vybrat ktere radky/sloupce vlastne chcete replikovat. Navic obnova databaze ze zalohy znici slony instalaci, takze musite ho odinstalovat, nainstalovat znova a znovu sesynchronizovat db.
Ta freeware DB2 co tu inzeroval lenin je velmi vyrazne lepsi nez pgsql a je za stejnou cenu (zdarma), ackoliv se za nejake featury (HA a Replikace) plati, ale dostanete k nim i 24/7 support, ktery by si zakaznik delajici vetsi projekt stejne koupil (navic musite zohlednit fakt ze slony1 je pomerne problematicke v produkci a support pro nej nikdo v cz neprodava). Prakticky je tak databaze zdarma a platite jen za support. Problem je ze Cesi DB2 nechteji, tuhle db vidim v produkci nasazenou ale opravdu velmi vzacne.
Ja vim databazi zase tak moc neni: mysql, db2, oracle, pgsql. Mysql ma ale vybornou podoporu nastroju, snad kazdy profi nastroj umi dneska i mysql a lidi co umeji delat s mysql jsou _velmi_ levni, dostupni a bohuzel take velmi nekvalitni, ostatne kvalita mysql je opravdu velmi nizka, donedavna jeste vracela pri joinech chybne vysledky a 5.0 ma problemy s views, ktere nekdy spatne vyhodnoti. Ja bych mysql ale neriskoval pro aplikaci ktera zachazi s penezi na blog/webforum je to ok, tam o nic nejde.
PGSQL ma tu vyhodu ze z vyse uvedenych databazich nejmene havaruje diky internim SW chybam, oracle a mysql nejvice. Idealni databaze pro install & forget aplikace. Ja Oracle sice vubec rad nemam pro znacnou poruchovost v produkci (zejmena pri nasazeni v RAC), ale cesi ho maji radi a dobre se pro nej programuje. -
Já bych také rád viděl některé funkce z Oracle nebo DB2 v PosgreSQL. To co není ve standardu se ale docela dost obtížně prosazuje - navíc standard neobsahuje některé zajímavé funkce, které jsou jak v DB2, tak v Oracle - ale jinak implementované. Je fakt dost velký odpor k implementaci duplicitní syntaxe - i když je to pár řádku v gramatice, a i když historicky PostgreSQL určitou kompatibilitu s Oraclem nabízel. S drivery je to jednoduché - v podstatě, co kdo napíše, to je. Fakt je ten, že .NET komunita je o dost aktivnější.
-
RK (neregistrovaný)Problem je ze zpusob jakym je pgsql projekt veden. Proste vedeni projektu kasle na lidi kteri by radi z pgsql meli databazi srovnatelnou s oracle/db2. Pod pojmem srovnatelna myslim to, aby byla pouzitelna pro vetsi projekty.
LO i Lenin maji pravdu s tou zpetnou vazbou, ktera proste bez penez nefunguje.
Pokud pridavate feature X (writeable cursory) tak zakaznici oceni zamykaci model kompatibilni s Oracle nebo v horsim pripade s DB2, protoze jim kompatibilita usetri mnoho casu (a tudiz i penez). Budou s produktem spokojeni a budou dale platit a neposilhavat po konkurenci.
Kdyz ovsem zpetna vazba od uzivatelu neni, tak vas nic nenuti se starat o jejich blaho a tak pokud danou vec nespecifikuje SQL standard presne, udelate si to proste podle sebe (t.j. nekompatibilne) a uzivatele maji smulu. Proste se musi prizpusobit.
Pritom mne lidi z EDB, kteri nejsou v pgsql komunite moc oblibeni nepripadaji jako ze by chteli neco nerealneho, proste chapou potreby svych zakazniku, kteri by se radi venovali svemu byznisu a ne ztraceli cas s databazi. Pokud ma ovsem nekdo vyvoj pgsql jako konicka tak ja ho chapu, tyhle problemy ho asi netrapi.
Kompatibilita s de facto standardem je dobra vec. A nechapu proc jsou opravdu tak zasadne proti syntax sugaru. Komu by vadilo ze pgsql umi i oracle kompatibilni syntax rekneme pro sekvence? mne ne. -
Problém s Oraclem je asi následující - Oracle si bere standard jen jako inspiraci - celkem logicky se snaží o vytvoření vlastního standardu a o vendor lock. Něco implementuje podle standardu, něco nikoliv (např. chybí operátor DISTINCT OF). Není problém implementovat dvě syntaxe (většinou, pokud nedojde ke kolizi). Problém je v dokumentaci a ve vývoji - výsledkem je takový kočkopes - (což už tedy PostgreSQL stejně je). V okamžiku, kdy jednu věc můžete napsat 4x trpí kvalita kódu a paradoxně přenositelnost (i když přenositelnost u komplikovanějších aplikací je utopie). Zavedením režimů kompatibility zase dost bobtná parser, což pak znamená vyšší režii na údržbu a vývoj. Existence EDB se ukázala jako docela přínosná v tom, že se nemusela řešit kompatibilita s Oraclem - tu si řešila EDB. Mimochodem - neoblíbenost EDB v komunitě není nijak zásadní - stále jsou v EDB zaměstnáni klíčoví vývojáři - a nikdo EDB nevyčítá, že používá kód PostgreSQL. Takových firem je více a EDB alespoň sponzoruje vývoj. Marketingu EDB se ovšem povedlo vyprodukovat několik nešťastných neobjektivních tiskových prohlášení - čímž si komunitu rozhodně nezískali.
-
je fakt ze existuje jeste informix, ktery ibm v soucasnosti marketingove tlaci pro OLTP aplikace aby se vratily naklady na jeho vyvoj. Argumentuje vykonem a HA featurama, ale zadne tpc benchmarky k dispozici nejsou a cena je stejna jako za db2. Ale i kdyby byl opensource, pochybuji ze by nekoho zaujal tak ze by na nej premigroval.
Driv se ho snazila ibm zbavit, ale ukazalo se ze nektere organizace (treba VISA) z informuxu migrovat nechteji, nechce se jim prepisovat aplikace. Presto pocet uzivatelu informixu rok od roku klesa, ja osobne bych informix pro nove aplikace jiz nepouzil.
Na trhu databazi jiz pro nej neni misto. Stejne tak neni misto pro SAPDB, na tu se pamatuji a bylo to tak zabugovane, ze mne neprekvapuje ze ji dneska nikdo nechce ackoliv je pod GPL a featurelist nema rozhodne nejhorsi. Pres 70% SAPu beha na Oraclu. IT prumysl potrebuje co nejmene ruznych databazi, ponevadz jsou navzajem nekompatibilni - protoze jak je videt na prikladu pgsql - oni se na vicemene standardu proste neschodnou a zamykani ma kazda databaze semanticky uplne jine. Kdyz kuprikladu hodite pgsql kod do db2, tak zamykani (select for update) nebude vubec fungovat. Prenositelnost i velmi jednoduchych aplikaci je proto utopie.
http://www.google.cz/url?sa=t&source=web&ct=res&cd=32&url=http%3A%2F%2Fevents.ibm-smb.cz%2Fforum2008%2F5_DatabazovaReseniIBM.pps&ei=M4jHSJyHFI--0gWTwJkT&usg=AFQjCNGFS6CxTM0XdybyHj81XluQ8VmLYg&sig2=yonFS1qy6sStT1lqdQe0CQ
ja jsem s informixem pracoval naposledy tak pred 10 lety a to byla hrozne zabugovana databaze. Osobne bych rad videl kdyby firebird, informix a sybase uz konecne odkraceli do vecnych lovist. Oni umiraji pomalu, protoze nikdo je uz pro nove aplikace je uz nechce.
Prekvapive mainframova IMS z roku 1960 je dodnes nejpouzivanejsi databazi na mainframech. Ukazuje to hezky na fakt, ze ne vzdy je SQL dotazovaci jazyk potreba. S IMS jsem jiz delal, ale jeste jsem nedelal zadnou aplikaci pro CICS, to bych si taky jeste chctel zkusit. -
honzak (neregistrovaný)ja skutecne nechapu, co s tim sledujete. Je to takovy povzdech nad nedokonalym svetem nebo si skutecne prejete, aby vznikla nejaka postgresql, ktera by mela vsechny klady tech ostatnich DB bez vsech vlastnich a cizich nevyhod?
Z toho co pisete by mel clovek dojem, ze bez DB2 nemuze byt lidstvo spokjeno. Ale napr. v Nemecku je 2 miliony firem, ktere maji mene nez 10 zamestnanci. Pak dalsi 1 milion firem, ktere maji do 50 zamestnancu nebo tak 20 milionu EUR obrat. Pro ty mensi firmy staci sprava dat ve filesystemu, ty vetsi (moje osobni zkusenost) maji tak do 10GB dat. Jenom nekolik stovek firem v nejakem state ma 100GB dat.
Otazka tedy musi znit, pro koho se tady vyviji a kdo bude nakukovat ty provadeci plany? -
LENIN POWER! (neregistrovaný)pgdump o velikosti 2.8 GB.
Doba zalohy - 779.46 real 27.62 user 15.41 sys
doba obnovy - 3392.39 real 25.33 user 16.72 sys
velikost db na disku:
originalni db 8.6 GB
obnovena db 7.1 GB
to jako platforma pro 100GB databaze nevypada, vzdyt by obnova znamenala alespon 1 denni vypadek. Takze se da pouzit pokud cena jednodeniho vypadku + slozitejsiho vyvoje < cena licence mssql/db2/oracle. Tedy jen pro amaterske pouziti.
Pro zajimavost restore 100GB DB2 ze stejneho diskoveho pole 19 minut. Jo, je to kapanek rychlejsi. -
honzak (neregistrovaný)neco se mi na te dnesni db-technologii nelibi. Nebo jak si to mam predstavit?. Jiste to neni mysleno tak, ze aplikacni vyvojar se zabyva s tim, co je zde popsano. Aplikacni vyvojar se stara o to, aby zakaznik dostal optimalni reseni. To uz je tezke dost na to, aby studoval nejake provadeci plany.
Kdo se s tim tedy zabyva.? Tusim, ze firma ktera vyviji aplikace tedy zamestnava jednoho takove systemoveho db specialistu, ktery pri nesnazich nahlizi ty provadeci plany a meni pak ty dotazy. Vyplati se nekdo takovy? Jak je to skutecne ve firmach organizovano? -
Začnu z druhé strany - otázkou. Co je to aplikační vývojář - kodér nebo programátor? Ke znalostem aplikačního programátora by rozhodně mělo patřit jak SQL, tak i schopnost alespoň základního ověřování a optimalizace SQL dotazů. Programátor bez znalosti db napáchá víc škody než užitku. V určitém objemu dat to není tak složitého, což jsem se snažil vysvětlit v tomto článku. Dokonce je to velice jednoduché. Práce pro specialisty začíná v okamžiku, kdy se velikost databáze přehoupne přes určitou laťku - pak už je potřeba dost znalostí, které běžný programátor nemusí mít.
Pokud vím, tak řada firem zaměstnává DB specialisty - na různých pozicích a osobně si myslím, že se jim to velice vyplatí. Sám jsem rozhýbával několik líných a více-méně nepoužitelných aplikací - přičemž zrychlení bylo jasně prokazatelné - cca 50-100% celkového strojového času databáze. Rozhýbal jsem systémy, které již byly nepoužitelné. Nemohu ale říci, že bych k tomu potřeboval speciální know-how. Většina brzd je do očí bijící pitomě napsaný kód. -
surda (neregistrovaný)potvrdil nektere vlastni objevy a dukladne rozsiril vedomosti kudy dal. Mensi DB ( v radu jednotek az desitek GB) se chovaly korektne, pouzivaly pripravene indexy, pri narustu pres 100GB nezbylo nez zvysit cenu sekvencniho cteni. Po precteni tohoto clanku budeme dal experimentovat. Jeste bych upozornil na jednu vec, ktera by se nikdy nemela stat, ale bohuzel, stane se nam casto na malych ad-hoc tabulkach, primarni klic napriklad varchar a ve velke tabulce foreign int a i kdyz je zaindexovan, postgres index nepouzije, protoze nedela automatickou konverzi typu a je nutne na neindexovane strane doplnit pretypovani ::int.
Postgres je perfektni a pokud se objevi i oracli analyticke rozsireni, tak nevidim rozumny duvod k pouzivani oracle. K tomu cast analytickeho rozsireni se da delat workaroundy uz nyni ...
Dik -
PostgreSQL indexy použije, pokud existuje implicitní konverze a to ještě pouze pro rovnost. Pro ostatní operátory musí být stejné typy na obou stranách. Ve všech ostatních případech je nutné explicitní přetypování. Což asi lepší nebude - je snaha o minimalizaci počtu implicitních konverzí. Na druhou stranu by se mohlo objevit alespoň varování, proč se ten či onen index nepoužije - tohle leckoho nekopne. Toho, co by se dalo dělat, je hodně.
p.s. těší mne, že tahle práce, má nějaký efekt. -
anonYmouse (neregistrovaný)diky za nej
jeste by mozna bylo vyborne trochu poresit GUCS (viz v clanku zminka o work_mem), nebot jejich spravne nastaveni strasne moc ovlivnuje celkovy vykon databaze. Na webu moc srozumitelnych informaci na toto tema k nalezeni neni
dobre jsou i odkazy, treba ten o Desateru, ktere by mozna klidne vydalo na deset samostatnnych clanku na rootu :) -
Doporučil bych Joshuovy slajdy: http://www.pgcon.org/2008/schedule/events/104.en.html
ČLÁNKY DO MAILU