Vlákno názorů k článku PostgreSQL 10: drsně rozběhnutý slon od klokan - Takže vývoj PostgresQL 10 dodržel časový plán a...
-
Takže vývoj PostgresQL 10 dodržel časový plán a současně uvádí všechny plánované novinky... proti prakticky všem uzavřeným projektům to zní jako science fiction. Pánové (a dámy), smekám před vámi. PostgresQL suveréně drtí prakticky jakoukoli jinou databázi z hlediska fičur, interoperability, dokumentace, otevřenosti pro aplikace, i z hlediska podpory různých platforem. Jediné, v čem mají Oracle, DB2 a MSSQL stále navrch je výkon, ale jestli to takhle půjde dál a projekty na optimizaci své sliby, tak na PostgresQL 12 už nebude mít nikdo.
-
. . (neregistrovaný)
no, řekl bych, že mají navrh ještě v jiných věcech (federace, columnstore, obecně governance, scheduling, integrace s nástroji ať už BI, tak přístup třetích stran atd.).
Tím ale nechci říct, že PG je zlo a ani se hádat co umí/neumí, mám tuhle databázi rád a nasazuji jí na projektech jak to jen jde. Jen jí srovnávat s Oracle či Teradatou jednoduše nelze, stejně tak nevěřím, že dokáží za několik let ztrátu dohnat, to ale nesnižuje užitečnost PG, jen nesouhlasím s tvým pohledem.
-
Palo (neregistrovaný)
Mozte to nejako aj viac rozviest. Z mojho pohladu:
- federacia - OK to mozu zlepsit a zlepsuju
- columnstore - na to nebudem pouzivat SQL databazu na to mam ine columnstore orientovane DB systemy
- governance - konkretnejsie co vam chyba?
- scheduling - konkretnejsie?
- BI - ktory z dnesnych nastrojov sa nedokaze pripojit na PostgreSQL? -
. . (neregistrovaný)
Ono asi nemá smysl o tom moc diskutovat, pro enterprise nasazení jako náhrada těch etablovaných databází to ještě není, řada drobných bugů a nestabilit se musí terpve vychytat.
- federace - pokud jí k produktu potřebuješ, musí fungovat
- columnstore - ty možná ne, ale používá se to, MSSQL column store jako optimalizaci pro analytické dotazy používá, stejně tak Oracle, Teradata, Netezza atd.
- governance - tohle striktně záleží na vnitřních předpisech dané společnosti, v PG je celá data privacy v plenkách, chybí např. data masking
- scheduling - klasicka v enterprise, dopoledne chci, aby určití uživatelé měli vyšší prioritu a v noci naopak chci, aby zase jiné joby měli k dispozici celý výkon
- BI - přes jdbc/odbc lze napojit ledacos, s PG ale často řešíme různé problémy, vidám chyby typu ArrayIndexOutOfBoundsException v jdbc, to jen pro příklad.Rozhodně nechci hanit PG, je to výborná databáze, issue zpětně hlásíme, ale nesouhlasím s názorem předřečníka, že jediné v čem má Oracle, DB2, MSSQL navrch je výkon.
-
Palo (neregistrovaný)
federacia, columnstore, BI - ak to robim pre velku DB tak si to fakt vyhodim do Elasticu, Sparku, HBase, ... nakoniec ak robite skutocnu BI tak musite integrovat udaje z viacerych zdrojov
data masking - riesime uplne jednoduchym command line toolomBI, data masking, ... nie su predsa funkcie databazy. To ze ti to tam Oracle pcha neznamena ze je to tak spravne. My ak si mozme vybrat DB system a organizacia ma Oracle zakupeny a nestoji to naozaj nic aj tak radsej volime PostgreSQL. Jednoduchost, nastroje, vsetko to mame nejako viac pod kontrolou tak povediac pod prstami. Oracle si zije akoby svojim vlastnym zivotom mimo vasej kontroly a vy ho iba obsluhujete. MSSQL som naposledy videl davno a to sme pri importe museli este vypinat constrainy lebo to ten system nezvladal. To je v mojich ociach stale taka small enterprise DB. A u jedneho klienta mame este informix a ked sa to vie ten system celkom poslucha. U dalsieho klienta naplname Teradata koli BI. Asi je to nastrojoch, ja si nemyslim ze SQL databaza sa ma pouzit ako vseobjimajuce ulozisko dat vo firme.
Upozornujem ze tieto nazoru su moje vlastne a subjektivne a namaju za ucel napadat tie vase. -
Bugy má každý sw - bez ohledu na cenu. Ohledně nasazení v enterprise sféře - tam Postgres pomalu proniká - a je to postupný proces. Jednak Postgres získává funkcionalitu, která se vyžaduje v tomto prostředí. Z druhé strany uživatelé v této oblasti si trochu rozšiřují spektrum software, který akceptují a zároveň akceptují, že některé vlastnosti nejsou pro řadu aplikací nutné, že řada věcí se dá udělat jednodušeji a přitom stále spolehlivě a robustně - a že nemusí vždy kopírovat patterny z Oracle.
Cílem komunity je poskytnout kvalitní robustní relační SQL databázi - která si udržuje rozumnou složitost. Včera jsem školil Oraclisty, a ty mi několikrát potvrdili, že to co by v Oracle konfigurovali několik hodin mají v Postgresu za pár minut. To je cíl - jednoduchost, praktičnost v použití - není cílem mít každou funkci, která se objeví v některé z databází na trhu. Samozřejmě, že se Postgres coby generický RDBMS poměřovat s OLAP speciály jako je Teradata nebo Netezza (která vychází ze starší verze Postgresu), případně s Oraclem, který běží na vlastním železe (pro OLAP). Na druhou stranu pro hromadu uživatelů jsou už nyní k dispozici extenze nebo výkonné forky Postgresu, které jsou funkční a pro danou oblast jsou konkurenceschopné - CitusDB, GreenPlum (má column store), StreamlineDB, TimelineDB.
Stále se hodně pracuje na FDW API - brzo by měla být podpora 2PC (už nyní firmy používají Pg jako datový hub, bo FDW drivery existují ke všemu). Tomáš Vondra dělá na PostgreSQL XL - což by mělo umožnit clustering. Existuje několik prototypů colum store - pracuje se na univerzálním řešení pro libovolný typy storage (zatím lze použít Citus nebo GreenPlum) např. transakční paměťový.
Zpřístupnění, zamaskování dat - to bezpečně mohu udělat v Postgresu přes extenze - zde zatím chybí poptávka, a tudíž i nabídka.
K schedulingu - existuje několik extenzí pro Joby - časem možná bude něco přímo i v pg, ale opět neexistuje poptávka - cokoliv lze dneska napsat přes Bg worker API - nicméně, co vím, tak ty extenze nijak zvlášť nepoužívají. Priority jobů, priority procesů - to je relativně hodně diskutabilní i diskutované téma. Snížením priority procesu zároveň prodloužím dobu běhu procesu a tím prodloužím i držení zámků. Je otázkou jestli je to win/win řešení. Odpovídá to samozřejmě primárnímu cílení PG na OLTP.
-
. . (neregistrovaný)
Ano, bugy jsou všude, každý SW se musí ustálit, u PG se zatím několik věcí neustálilo, ale stačí issue nahlásit a ono se to změní.
Souhlasím plně s tebou, do enterprise zatím proniká velice pomalu, to se ale časem změní, několik velkých nasazení máme rozjednaných ale narážíme na řadu drobných zádrhelů, tak se čas protahuje.
Přes extenze lze řešit cokoliv, obrovský problém ale je kompatibilita a support, je to hodně tenký led pro enterprise, pro eshop si extenzi napíšu, to není problém.
Palo: tohle lze dělat u malých projektů, u enteprise sektoru si takovéhle čachry nemohu dovolit, hbase je fajn, ale zase vyřešit synchronizaci, acl a další požadavky už není tak snadné (řikám uz pozice, kdy jsme několik hbase takhle nasadil).
-
Pro firmy v této oblasti není problém si zaplatit 2nd q nebo Edb, kteří zajistí veškerý support včetně vývoje a údržby extenzí. Vývojáři Pg nejsou takový střelci, aby měnili interní API (často nebo bez náhrady). Napsal jsem a cca 10 let udržuji Orafce - a jediné, co je pracné jsou buildy pro Win. Co je hlavní - v enterprise oblasti nejsou zatím žádné zkušenosti /(nebo jsou minimální) jak s Pg, tak s extenzemi - a co se nezná, tak je podezřelé.
Nasadit Postgres ve větší korporaci je běh na dlouhou trať - infrastruktura, vnitropodnikové předpisy, pracovní postupy - všechno je šité na Oracle. Někde to má smysl, někde je to silně kontraproduktivní. U větších firem vidím první výsledky po dvou, po třech letech. To samozřejmě není jen o Postgresu, ale o libovolném jiném sw, než který se v této oblasti používal posledních 30 let. Dodneška se někde emuluje COBOL, RPG, ...
-
Palo (neregistrovaný)
Co je enterprise sektor? Robime pre rozne firmy, rozne produkty, napriklad management fondov, nakupy, predaje, 100.000 novych riadkov v niektorych tabulkach kazdy mesiac. Nikdy to nespadlo, mali sme problemy s JDBC drivrom naposledy v nejakej 8micke verzii, uz dlho nic nevyskocilo. 99% veci je Java hibernate ale mame aj nejake ulozene procedury, window query, rekurzivne query 'rucne' urobene a vsetko slape a funguje. Uplne genialne riesene a presne nastavitelne lockovanie (napriklad ROW_SHARE mode). Niektore veci fakt neviem ci Oracle zvlada.
Za to si presne pamatam ze na nejakej velkej tabulke v Oracle sa zjavne zle vytvaral query plan a nedokazali sme ho upravit ani cez hinty. Oracle support po pol roku prisiel s nejakym riesenim updatu nejakych magickych cisel v nejakych internych tabulkach a potom to zacalo chodit. Je ale jasne ze na SK/CZ podla mna nie je dostatocne velka entita ktora by dokazala mavat Oraclom tak aby realne nieco co iba im nefunguje v rozumnom case opravili. Som si isty ze z PostgreSQL aj ked OpenSource by som fix dostal skor. -
Trident (neregistrovaný)
100k radku kazdy mesic nelze povazovat za velke enterprise projekty. To bych porad povazoval za maly projekt.Ty velke zacinaji desitkach tisic denne. Typicky mnohem vic. 1m denne je stred. Obvykle databaze dokazi dostat do kolen realtime tradingove systemy a vyzkumne projekty.
-
. . (neregistrovaný)
enterprise, bavím se globálních projektech či lokálních bankách, průmyslových podnicích či výzkumných ústavech. Běžná velikost warehousů je 30TB (ale i řády více), hodinové přírustky v desítkách, stovkách milionů řádků i pro jednotlivé tabulky, které se počítají na stovky, tísíce, roční náklady na provoz podobných systémů jsou stovky mega, tohle je pro mě segment kam míří MSSQL, Oracle, Teradata, Netezza, DB2 aj. a tohle je úroveň, na kerou PG ještě zdaleka nemá.
Tím rozhodně nechci říct, že PG je špatná, neschopná databáze, je ale potřeba jí používat tam, kde na to stačí a vyhovuje. PG provozujeme v desítkách instancí i s vlastními extenzemi, zajišťuje chod řady eshopů, interních systémů nebo testovacích projektů, v tomhle prostředí je plně srovnatelný s čímkoliv jiným.
-
MP (neregistrovaný)
Jedeme taktez primarne na postgresu a jsme s nim docela spokojeni. Nedokazu to porovnat z hlediska enterprise reseni, ale co mi zatim nevyhovuje:
1] md5 pro hesla
2] upgrade replikovanych slave (jo, ja vim, ze je moznost pres logickou replikaci, ale to neni jeste tak snadno pouzitelne jako pouhy pg_upgrade)
3] "interni" HA reseni - srovnejte to s mysql gallera
4] nefunkcnost fqdn v pg_hba, co jsem posledne na nektere z 9.3/4 zkousel
5] slabsi podpora AD - a obecne centralni sprava uzivatelu z hlediska fluktuace vyvojaru a vliv na prava v tabulkach atd (ale to je asi spis o DBA navrhu)Ale jinak si nemuzu stezovat, lepsi nez mysql z hlediska funkci a zvlaste nasazeni PITR v 9.x nam hodne zlehcilo ochranu dat
Jen by mne zajimalo, co je nejlepsi (web)GUI? Phppgadmin je dost pozadu...
-
mirsen (neregistrovaný)
Bohuzial pre Postgre neexistuje ziadny web/gui klient ktory by bol naozaj dobry s vela featurami... Pgadmin4 je zabugovany a pre mna nepouzitelny (copy/paste, zobrazovanie dat, spustanie selectov...)
Ja som sa zatial vzdy vratil ku klientovi Adminer od Jakuba Vrany. Bezi mi na localhoste na lighttpd, na spojenie so servermi mam porobene makra na SSH tunely, na zobrazovanie dat som si to trochu priohol nejakym tym pluginom (vyuzivajucim oficialne Adminer plugin API). Jednoduche a funkcne.
-
MP (neregistrovaný)
A vase doporuceni ohledne (web)GUI? Protoze konzole je sice silny nastroj, ale bez GUI se obejit je v nekterych pripadech kontraproduktivni. Nasi vyvojari pouzivaji priohnuty phppgadmin z debian7, mozna i starsi, a pokud dle githhubu posledni verze umi "jen" 9.5, tak to s 10+ bude mit problem (nemluve o php7). Co ta nova verze PgAdmina?
-
Web GUI jsem nepoužil roky - co vím, tak PgAdmin 4, by se měl nechat použít i jako tenký klient - v podstatě i když jej použijete jako tlustého klienta, tak je to fakticky tenký klient s vlastním html browserem. Stav je takový, že asi letos už by to mělo být použitelné. Jako www klient je možné použít i https://omnidb.org/en/.
Jinak ke klasickému GUI - Pořád je k dispozici PgAdmin 3. Pokud už potřebuji GUI klienta, tak používám https://dbeaver.jkiss.org/ - hlavně, že mi funguje celkem dobře i s Oraclem.
-
martinus (neregistrovaný)
Ono je vzdycky lepsi, kdyz je nejaka konkurence. Kdyby nebylo ostatnich DB systemu, tak by ani Postgre nebylo tam kde je (osobne tedy nevim kde presne je). Co vim, tak hodne (mnoho, vetsina - dosadit si muzete cokoli) velkych zakazniku (systemu) jede na Oracle, DB2, MSSQL a jen okrajove maji nasazeny tyto opensource db. Samozrejme, ze jsou i taci, co to maji obracene atd. atd ... takze budme radi, ze je v DB svete zivo a vsichni z toho maji uzitek ;-)
-
Ti "velcí" používají komerční databáze zejména ze setrvačnosti a utopených financích. Často ty firmy platí zlomky ceníkových licencí a už je téměř nemožné z rozjetého vlaku vystoupit. Mladá firma to má ovšem jinak.
Nicméně jak už mnoho lidí řeklo, nesoustřeďte se na TOP 500 FORTUNE firmy, ale na ten zbytek! :)
-
martinus (neregistrovaný)
Tak jinak, pokud ma firma miliardove obraty a vypadek DB je stoji treba 100K dolaru za hodinu, tak se proste nebude spolehat na opensource komunitu, ze jim ten problem vyresi. Tam je proste nutny mit zabezpeceny support a ten proste Oracle a dalsi placene db maji na vysoke urovni (mluvim o opravdovych problemech, ne o problemu severity 3, ktery dostane do ruky indicky support). Oracle ma specialni "komando", ktery resi opravdu kriticke problemy.
-
Kolemjdouci (neregistrovaný)
Jenze prumerny cesky developer skonci u tech Indickych !@#. Osobni zkusenost je cekani zhruba dva roky, nez zabugovany kod sami obejdeme a nechame SR zavrit pro neschopnost.
Posledne jsem jim poslal popis chyby, debug log i patch a oni mi 14 dni dokolecka tvrdili, ze muj problem neexistuje! Musel jsem jim jejich kod doslova omlatit o hlavu nez blahosklonne potvrdili, ze muj patch mergnou v pristi major verzi.
Oracle support je banda naprosto neschopnych predrazenych kretenu. -
Honzucha (neregistrovaný)
No dovolil bych si odporovat. my treba migrujeme z Oracle ma MSSQL a rozhodne nejsme FORTUNE500 company. Nase DB ma pres 1TB (pri pouziti column store) s tabulkami majicimi nekolik miliard zaznamu kazda. Denni prirustky v mensich tabulkach se pohybuji okolo 100K radku. PostgreSQL mam rad a velmi moc bych chtel videt jak by se popral s takovym objemem dat (toto neni ironie). Jinak mate pravdu, ze volume licencing neni cenikova cena, ale i tak licence na 192 jader stoji nepredstavitelne penize, nicmene stale je MSSQL masivne levnejsi nez Oracle a v nasem nasazeni i vice vykonny.
-
Pet (neregistrovaný)
Dobry den, nas SCADA/MES system u konkretneho zakaznika ma PgSql archivnu databazu (realtime data) s 450 GB (kazdu sekundu sa vklada 200-300 hodnot pricom aplikacia - archiv - paralelne zapisuje na niekolkych taskoch, aby vyuzivala vykon viacerych CPU).
U ineho zakaznika su 2 databazy (dvoch aplikacii), samotny archiv ma iba 210 GB resp. 170 GB, ale su tam aj tzv. "trezory" co su databazy s historickymi udajmi od za 8 resp. 5 rokov (co mesiac to DB). Premigrovali sme ich z Oracle (v r. 2016), mali dokopy cca 4.85 TB (screenshot z novembra 2016) a uzivatelia sporadicky pouzivaju citanie aj z tychto db (resp. pytaju si data a ak uz nie su v archive, prehladavaju sa automaticky trezory). Tie 2 archivne databazy + vsetky trezory sa nachadzaju na jedinom virtualnom serveri s 32GB RAM. Fyzicke zelezo je HP DL380 G9 + Win2008 + lokalne disky (starsie trezory na NAS na pomalsich diskoch). Takze ziaden extremny HW.
Takisto niekolko sto vlozenych riadkov kazdu sekundu v kazdej z dvoch aplikacii.U tretieho zakaznika (ktory funguje primarne na Oracle) sme vyskusali ako sekundarny archiv PgSql, databaza mala (screenshot z 2014) 1.03 TB, bezala na starom neprodukcnom "vyradenom" zeleze (DL380 G4, 2x Xeon 3.4 GHz procesor).
Cca 500-600 realtime hodnot vkladanych za sekundu (a v ustalenom stave tolko isto mazanych, periodicke vymazavanie prebieha na pozadi raz za N hodin).Systemy funguju 24/7, spolahlivost vysoka, spokojnost tiez (najma moja, kedze robim v pripade problemov servis, zase 24/7).
Pouzivame aj Oracle, niekedy na Metalinku pomozu ok, niekedy nie (na Oracle 11g mi nevedeli pomoct s postupnymi pamatovymi problemami a ORA-600, jedine co poradili je "pridajte RAM", takze databaza co bezala na 10g na 4GB RAM serveri skoncila po upgrade na 11g na 24 GB RAM serveri a nestabilita sa prejavuje iba raz za 1/2 roka.. predtym s 8GB RAM to padalo kazdy tyzden/dva a bolo treba otocit ORacle, nestacilo restartnut nasu aplikaciu).Kazdopadne negarantuju "cas dokedy opravia chybu" .. alebo mozno ano, ale zakaznikom inej triedy a za ine peniaze :).
Zazil som raz patchset (10.2.0.5 na OpenVMS Itanium) ktory sposobil vazne problemy (databaza pri vyssej zatazi jednoducho zamrzla). Riesili to cca 2 tyzdne (a to sme mali stastie, ze to hlasil nejaky dolezity zakaznik ako najvyssiu Severity, takze my sme sa zviezli popri nom). Ak by niekoho zaujimali detaily, tak sme pouzili patche p14727319_10205_ItaniumVMS.zip a p6904068_1020510_ItaniumVMS.zip a nakoniec finalny p16053781_1020510_ItaniumVMS.zip, na Metalinku sa to da snad dohladat).
Plus zazil som u zakaznika jeden Oracle audit - neskutocne mnozstvo casu, nervov a penazi to stalo.. a odvtedy tlacim vsetkych do PgSql .. -
otis (neregistrovaný)
Ano, ten Oracle zakaznik je naozaj velmi, povedal by som, delikatny. Inak, co sa Oracle supportu tyka: Na Slovensku je fakt vynikajuci HW support a support na "vyssie vrstvy" engineered systemov. Ak sa jedna o "low level" problemy, vsetko ide do USA (niekedy s medzipristatim v Indii.)
-
Zgub (neregistrovaný)
No posledne mam skusenost so 110TB databazou na postgrese. Miliardy riadkov. Jop :) Nad Hitachi Ent. storage. A po predchadzajucich skusenostiach s Oracle, ci SQL serverom, toto bolo peklo. Tiez netvrdim, ze postgres je zly, nasadzujem ho kde sa da. Ale na takto velke projekty a hlavne tam, ked sa vyzaduje HA sa podla mna este stale nehodi. A budem prvy co to bude skusat, az sa tam postgres dostane :)
ČLÁNKY DO MAILU