Názory k článku Novinky a vývoj v PostgreSQL 9.2
-
Michal Zahradnicek (neregistrovaný)
V prvom rade chcem pochvalit clanok - velmi pekny prehlad.
Dosial som pouzival Mysql a na veci ktore som robil to zatial stacilo. Odkedy vsak Oracle kupil SUN, tak premyslam, ze by som zacal pouzivat Postgre.
Viete niekto o nejakom zhrnuti Postgre vs Mysql. Pripadne ako je na tom postgre s podporou znakovych sad(UTF-8, cp1250,....)?
Dakujem
-
Peposh (neregistrovaný)
Toto je dobrá otázka na flame :D
Ale moja skúsenosť je nasledovná:
MySQL je údajne rýchlejšia, no mňa viackrát zaskočila zvláštnosťami, ako stĺpce nemusia byť v GROUP BY alebo sa mi nedal spraviť viacnásobný sub select. Tiež kedysi nemala analytické funkcie (a netuším, či ich má teraz).
Ergo ak by som hľadal databázu pre projekt, ktorý hľadá rýchlosť a má databázu len na uloženie jednoduchších dát a nepredpokladá sa ich ďalšie spracovanie, potom MySQL.
Ak je to projekt, kde sú dáta podstané - teda informačný systém, potom PostreSQL. Za podstatnú výhodu PostgreSQL považujem jeho Oracle like prístup. Neznamená to, že je to prenostiteľné na Oracle len tak hala-bala, ale má to k sebe relatívne blízko.PS: PostgreSQL podporuje Unicode už hrozne dlho. Tvrdil by som, že minimálne 10-12 rokov.
-
Michal Zahradnicek (neregistrovaný)
Nejde mi o flame.
S Mysql robim uz cca 10 rokov a vzdy som po Postgre tak trocha poskuloval...
Ale nikdy som nenasiel nejaky racionalny dovod ho zacat pouzivat.V Mysql som si zatial vzdy vystacil. Ale pozeram ze Postgre ma asi viac moznosti - vid napr. datove typy predstavene v clanku, atd...
-
Peposh (neregistrovaný)
No obávam sa, že sa asi nenájde človek, ktorý by používal oba engines tak intenzívne, že by vedel podrobne vysvetliť na čo sa hodí MySQL a na čo PostgreSQL ;-)
Preštudoval by som net ako: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
Pre mňa osobne problém so subquery bol dostatočným dôvodom MySQL zase vynechať z rozhodovania. Bude to asi tým, že sa mi nechce trápiť z môjho pohľadu s bežnými vecami ako rank().
http://stackoverflow.com/questions/3333665/mysql-rank-function -
Ten srovnávací článek na wikivs je fakt pěkný, i když některé komplexnější (a méně tradiční) věci tam zmíněny nejsou (např. problémy s transakcemi jdoucími přes několik storage enginů na MySQL). Každopádně díky - většina podobných srovnání je zoufale nepřesná nebo zastaralá.
Moje osobní zkušenost je že mnoho programátorů prostě MySQL (nebo cokoliv jiného) začnou používat, různých omezení a problémů si na začátku nejsou vědomi a když na ně později narazí tak akceptují i nejšílenější workaroundy. Co na tom že nějaký dotaz jde vyřešit elegantně pomocí CTE nebo window funkcí - v MySQL to často řeší na úrovni aplikačního kódu. Apod.
Čímž v žádném případě netvrdím že to je nějaké specifikum MySQL, nebo že PostgreSQL nemá chyby a "podivnosti" (ale nikdo se jimi netají a naopak se na ně často upozorňuje).
-
Ano, jako námět na flame je to dobré ;-)
Nechci tady zabíhat do problémů v designu MySQL, ale za sebe můžu říct že jedna mnoha z věcí které se mi na PostgreSQL líbí je že featury se implementují buď správně nebo vůbec.
Příkladem může být ta klauzule GROUP BY. Ony tam ty další sloupce být mohou, ale musí být funkcionálně závislé na těch sloupcích které jsou uvedeny v GROUP BY (jednoznačně určené). Tj. pokud grupujete podle PK tak tam vlastně můžete uvést cokoliv. Nesmí dojít k nejednoznačnosti, že by v úvahu přicházelo několik hodnot. To je problém MySQL, která si tam prostě vybere nějakou (v podstatě náhodnou) hodnotu, byť samozřejmě rozumné SQL dotazy to určují jednoznačně (např. další sloupce z přijoinovaného číselníku apod.).
Na druhou stranu PostgreSQL toto dlouhou dobu neimplementoval vůbec (byť to šlo obejít přes nějaké agregační funkce), od 9.1 to umožňuje ale kontroluje právě funkční závislost.
Druhá věc kterou má PostgreSQL výbornou je plánovač / optimalizátor dotazů. Na triviálních dotazech to nepoznáte, ale pár joinů nebo složitějších podmínek a MySQL z toho jde hlava kolem.
Co se týká znakových sad, PostgreSQL už hodně dlouho podporuje snad jakoukoliv standardní znakovou sadu (včetně UTF-8). Daleko větší problém jsou různé locales - dlouhou dobu bylo podporována jen jedna locale "per cluster" (tj. jediná možnost třídění, porovnávání apod.). Šlo to sice jakž-takž obejít ale byl to "voser". Od 8.4 je to podporované "per database" a od 9.1 "per column".
PS: Když u dat nepředpokládáte jejich další využití, není lepší je vůbec neukládat? ;-)
-
Franta (neregistrovaný)
Místo Oraclí MySQL můžeš klidně používat MariaDB. Co se týče přechodu, jde hlavně o kompatibilitu aplikací (abys je nemusel přepisovat), jinak mi přijde PostgreSQL jako celkem jasná volba. MariaDB má zase některé zajímavé DB "enginy", což se může pro některé úlohy hodit...
-
talpa (neregistrovaný)
ja pouzivam jen Postrgres a nemenil bych, je to proste od zakladu vetsi kanon.Prednost mysql, mala a lehka se uz vytratila a ja marne hledam pro ni uplatneni (nechci diskutovat o jeji masivni podpore na vsech webhosting serverech), diky tomu ze jedu na samostatnem serveru tak se mi prace s postgres vzdy vyplatila, robusnejsi architektura, vyssi vykon pri velkem mnozsti zaznamu, podpora i pro jine jazyky (napr. si muzete napsat script v perlu kdyz Vam nevyhovuje pqsql, ci v python,jave atd.), takze vselijake tools se da lepe vysvihnout, to nemluvim o bash a zalohovani atd. atd. 4
Plno veci resi i mysql, ale na muj vkus bud nekomplexne nebo nesikovne. Nepouzil jsem moc objektivnich argumentu, ale ono je to o tom se postgres prokousat, nejake velke analyzy nemaj cenu
-
Myslím, že jediná současná výhoda mysql je lépe řešená replikace. Řešení v postgresql jsou zatím takové přes ruku, i když vývoj jde rychle kupředu.
Jinak poslední dobou když se někdo zeptá na fóru: jak udělat ...., tak mi hned vyskočí odpověď.... a pak půl hodiny přemejšlim, jak to implementovat v Mysql, když tam nejsou CTE, nejsou Window funkce, neumí updatovat s poddotazem do stejné tabulky.
Jo, ještě jednu výhodu má mysql - session proměnné. To jde sice v postgresu emulovat, ale je to vopruz a asi výrazně pomalejší.
-
Postgres jeste neumi MERGE? I kdyz pravda hibernate to nepouziva, takze proc to implementovat.
Ty checksumy stranek se mely udelat uz davno. Naprosto zakladni vec.
Poradnej partitioning taky jeste neni, chybi podle hash() a automaticke vytvareni partitions.
index only scan je dobra vec, jediny co ma smysl.
-
Partitioning je potřeba předělat - kromě toho, co jste zmiňoval, je tam limit cca na 100 partitions - můžete jich mít více, ale začíná docházet ke zpomalení plánování - v pg je partišna víceméně relace, což je občas výhoda a občas i nevýhoda. Ale dost možná, že změna je na dohled - firmy, které dělají komerční support pro pg to intenzivně řeší - a vypadá to, že je to jen otázka zdrojů - tohle jsou funkce, které se nedají psát na koleně a je nutný fulltime programátor. S checksumy je spojeno několik problémů - v prvé řadě to byl výkon na slabších CPU a averze k duplikování funkce souborového systému. A aktuálně je to problém s kompatibilitou formátu - díky pg_upgrade už při upgrade se nemusí používat dump/load a změna formátu - rozšíření o checksum je problém. Na téhle funkci se v 9.2 hodně dělalo a intenzivně se o ní diskutovalo, což dává velkou naději, že bude v 9.3.
-
Na Postgresu dělá na fulltime cca 20 lidí - a to už tak od roku 2005. Finančně je to pořešené tak, že tito lidé jsou většinou zaměstnanci firem, které z PostgreSQL profitují - a většinou se jedná o lidi, kteří nějak přičichli k pg, získali zkušenosti, a pak už u pg zůstali - a pak je dost lidí jako jsem já, kteří se motají kolem pg - a primárně se živí jako DBA, ale díky tomu, že do pg vidí, tak jsou schopni psát extenze, případně si rozšířit pg, tak jak jim to vyhovuje - hromada kódu do plpgsql vznikla tak, že jsem něco řešil ve svých projektech - ale za kód v pg nemám ani korunu. Něco si vydělám ze školení - ale na živobytí si vydělávám jako normální programátor a konzultant (a jako zaměstnanec) - a podobně funguje dalších 30 lidí.
Vzhledem ke komplexnosti projektu tak už je implementace složitějších funkcí práce na dva, tři roky - např. window funkce, CTE, ... I relativně jednoduché věci se řeší měsíce - a komplexní věci, které jdou napříč db pak roky - a partitioning nebo třeba replikace jsou z téhle kategorie - to buďto může napsat někdo v rámci disertačky a nebo fulltime programátor v rozumném čase.
-
No ale na 25 lidi fulltime je to dost slaby vysledek. Mrknete se sem https://github.com/postgres/postgres/commits/master kdo realne na tom pracuje: Tom Lane, Petere a bmomjian, Robert Haas. Ostatni prakticky vubec.
S takovym pracovnim nasazenim je jasny ze checksumy budou trvat dva roky. Vzdyt tam bude jen nekde funkce nacti blok a zapis blok a nejaky testy k tomu. To prece neni prace na dva roky. To musi byt i s testama udelany za tyden kdyz se na tom fulltime dela.
LO ma pravdu ze kdyz neni u OSS zpetna vazba penezi tak ze ty projekty delaji minimum. Kdyz se podivate kuprikladu na JBOSS tak tam ten vyvoj jede fofrem - komercni firma si ohlida aby se ji lidi neflakali.
-
Vidíte jen seznam commiterů. Ostatní tam nikdy nebudou, poněvadž nemají práva zápisu - viz http://wiki.postgresql.org/wiki/Development_information.
Je fakt, že progress je v řadě případů pomalejší než by se mi líbilo, ale je to daň za popularitu pg - je to databáze - v případě chyby by uživatelé lehko mohli přijít o data - a je to dnes i rozšířená databáze - a pokud se tam dostane blbě navržená funkce, tak tam z důvodů na kompatibilitu minimálně 5-10 let zůstane. Takže se převládá strategie - než něco dělat blbě, tak je lepší to nedělat. Ale podle OHLOHu je vývoj poměrně stabilní - což vzhledem k rostoucímu objemu je, minimálně pro mne, uspokujující. https://www.ohloh.net/p/postgres/analyses/latest
Konečně - je zatraceně velký rozdíl mezi systémovým programováním a aplikačním - to co má aplikační programátor za týden, trvá systémovým měsíce - ale pokud byste se chtěl přidat, a ukázat, jak se checksumy přidají za dva týdny, tak jen do toho - každá ruka se hodí - minimálně jako reviewer nebo tester.
-
mam neco mnohem lepsiho nez se patlat s checksumy.
Zalozit startup dostanete tam vy + ten komik parasutista podily a preportujete postgresql do Z/OS. Obadva tomu rozumite a pokud se vam chce makat tak to dokazete. Proda se to zhruba za sestimistnou cifru v dolarech jednomu zakaznikovi a ja mam 123 zakazniku s mainframama. Prezentovat umite, o tom si nedelam starosti ze by si to od vas nekoupili.
-
A ten startup vam patri nebo jste jen zamestnanec? Jesti je to ten gooddata co mate u sebe napsano na linkedin tak tam vam nepatri ani ta zidle na ktery sedite.
Asi fakt na to nemate abych vas nechal vest firmu. Misto abyjste resil jak rozject firmu co ma realnou moznost mit obrat 10 mega USD z ceho byjste mel procenta navic k 100k+ platu tak resite Lenina.
V byznisu s vama nikdo v rukavickach jednat nebude, co si neurvete to nemate.
-
Takze jste podnikal, nevyslo to a z neuspechu vinite penize. Ze strachu ze krachnete znova chcete byt uz jen zamestnanec kde za iluzi jistoty platite majiteli vypalne asi tak 2/3 sveho vydelku. Turistiku povazujete za vyzvu.
S timhle pristupem je jasny ze by jste to jako sef startupu nedal. Musite se zmenit. Penize nejsou zlo, kdyz spoustite nejaky projekt tak bez penez se daleko nedostanete. Penize je potreba aktivne vydelavat abyjste mel zdroje na kryti neuspesnych projektu. Bez penez firma neprezije.
-
Nevím, kde jste přišel na to, že jsem podnikal, a nevyšlo to. Mám vedlejšák na školení a konzultace - a dělám, co mne baví, čemu rozumím a co je potřeba a mám relativně slušnou reputaci, takže na živobytí si vydělám - a to mi stačí. Berte to tak, kdybych byl věřící, tak bych možná byl kněz nebo mnich, ale jelikož jsem agnostik a líbí se mi ženské, tak mnich nejsem.
-
Tak že by se zrovna Simon Riggs (který checksumy implementuje) flákal, to mi fakt nepřijde. Implementace za 2 týdny včetně testů je z říše pohádek - ostatně viz. vlákno http://archives.postgresql.org/pgsql-hackers/2011-12/msg01206.php kde se řešily code reviews, různé nástrahy internals apod.
Ad počet lidí kteří na PostgreSQL pracují - jak už psal Pavel, to číslo 25 jsou jenom commiteři, ne skuteční autoři. IMHO je to brutálně podhodnocené, nedivil bych se kdyby reálné číslo bylo ve výsledku o řád vyšší, ale těžko to spočítat protože nic jako "firma PostgreSQL" neexistuje, spousta lidí na tom pracuje jenom "na půl úvazku" (např. zaměstnanci jiných firem které sponzorovaly nějakou featuru kterou potřebovaly apod.).
-
Ony hlavně ty checksumy na úrovni filesystému jsou nedostatečné, protože stránky používané filesystémem jsou jinak velké než stránky DB - fs má typicky 4kB, databáze 8kB. Takže jedna DB stránka = dvě stránky fs, což občas vede k torn pages (zapíše se jenom jedna z fs stránek - obě jsou validní ale celá DB stránka nikoliv).
-
K těm session proměnným - pokud se použije C implementace, tak je to maximálně rychlé - a pravděpodobně by nativní implementace nebyla o moc rychlejší. Je ale fakt, že funkcionální interface do SQL moc nezapadá - a bohužel není ani velký zájem o jejich implementaci jak ze strany uživatelů, tak ze strany vývojářů. Možná časem se dostanu k tomu, abych do pg dostal alespoň lokální statické proměnné v PL/pgSQL. Priority jsou jinde: MERGE, PARTITIONING, REPLIKACE...
-
Nejsem si jist co znamená "lépe řešená replikace" - binární (streaming) master-slave replikace je v PostgreSQL IMHO velmi pěkně vyřešená. Co se týká logické replikace (statement based) tak to bohužel zatím v jádře není, nezbývá než použít např. pgpool-II.
Session proměnné - mne osobně to nijak zásadně neomezuje, v uložených procedurách to je tak nějak samo od sebe ;-) Ale pokud to potřebujete tak myslím že naimplementovat si jednoduchou extension která to bude řešit by nemělo být úplně obtížné. Kdyžtak se mi ozvěte, já něco základního napíšu.
-
František Sousedík (neregistrovaný)
Nastudoval jsem, co se kde dalo.
Vytvořil jsem vlastní tablespaces a nového uživatele, který má vlastnit novou databázi. Po vytvoření nové databáze s uvedením vlastníka rozdílného od postgres, na mne "vyskočilo" v pgAdmin překvápko.
Nová databáze aniž bych to požadoval obsahuje v podstatě totéž, co databáze postgres. Nejdříve jsem uvažoval zda pgAdmin nezobrazuje něco špatně.
K čemu tam, prosím, jsou duplicitně Katalogy, Rozšíření a Schémata? Lze to zrušit? Lze vytvořit databázi "prázdnou"? -
Každá databáze obsahuje několik desítek systémových tabulek, které obsahují informace o samotné databázi a jsou nezbytné pro provoz databáze. Taktéž po instalaci máte vytvořeno několik schémat - public - výchozí schéma pro tabulky uživatele, pg_catalog - schéma pro systémové tabulky a information_schema - což je schéma obsahující předdefinované pohledy vyžadované ANSI SQL. Každá databáze má tyto systémové tabulky vlastní.
Těchto objektů se zbavit nemůžete - jsou nezbytné - jak pro provoz samotné db, tak pro provoz např. pgAdmina - např. seznam tabulek, seznam funkcí nebo seznam schémat. Pokud nepotřebujete pracovat s těmito systémovými objekty, tak si v pgAdminu zrušte volbu "zobrazit systémové tabulky".
