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.
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.
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?
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.
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 toolom
BI, 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.
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, ...
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.
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.
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.
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...
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.
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.
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! :)
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.
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.
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.
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 ..
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.)
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 :)
Messaging, ktery podporuje (distribuovane) transakce neni az takova hloupost. Oracle AQ je opravdu dost pomaly. Na intertetovych forech je spousta lidi kdyz jsou nestastni z toho, ze to nasadili a zjistili, ze nedokaze rozumne skalovat. Na druhou stranu ale, uroven ochrany dat, kterou to poskytuje je ale zase nekde jinde.
PS: porad je to ale lepsi nez to co predvadi zoufalci s Java JMS, kteri si implementuji messaging pomoci tabulek v db "rucne".
- Messagingov ktore podporuju distribuovane transakcie a nie su postavene na DB je dostatok
- Pre spracovanie vstupnych sprav je ale ovela efektivnejsie pouzit napriklad Kafku a 'At least one delivery' a znacit si v DB iba cislo spravy. Duplicitne potom zahodite. Bude to o niekolko radov rychlejsie a pri tom stale bezpecne. Popripade mozte aj exactly one delivery ak viete co robite.
- Pri posielani sa da tiez nieco vymysliet aby to fungovalo bezpecne zalezi od podmienok, v kazdom pripade distribuovane transakcie su zlo ktoremu sa treba vyhybat ako sa len da. Riesit transakcny monitor, jeho stavy, pady pripadne ho nasledne rucne opravovat, ... brrrr najhorsie nocne mory sa mi vracaju.
Takova ta klasika, mate tabulku do ktere vam na jedne strane ( producer ) cpe zaznamy ke zpracovani a na druhe strane ( consumer ) je chce zpracovat. Pokud nemate neco jako Oracle AQ pristupujete na hloupost typu (select * from trabulka where status = "Nezpracovano") a dostavate se do problemu, bud to delate rychle a ubijite DB timto dotazem a nebo mate delay ale tim "omezujete" rychlost reakce na zpracovani pozadavku.
Jinak AQ provozuji od doby co to Oracle zavedl ( miliardy procpanych pozadavku, nikdy problem, nikdy zadna ztrata dat apod. ) a naprosta spokojenost, kdyz to clovek pouziva s rozumem. Samozrejme kdyz se nadje troll co do te queue jako payload cpe 2MB xml message a divi se ze je to pomaly ;-) neni to problem technologie.
Viděl jsem několik extenzí - díky SKIP LOCKED lze i relativně efektivně řešit zamykání - ale stejně pro větší zátěž - tisíce zápisů/výběrů z fronty bych se snažil takové řešení rozmluvit. V těchto systémech mají data relativně krátkou životnost - a to není case pro Postgres. Postgres je fajn databáze, ale mizerná cache - není praktické (při větší zátěži - několik tisíc write transakcí za sec) používat Postgres pro data, která mají krátkou životnost. Jakýkoliv sw, který bude optimalizovaný pro frontu (v Pg tabulky jsou haldy) bude při větší zátěži výrazně stabilnější. To řešení od Skype by mělo být funkční - Skype to používal pro svou potřebu, ale je fakt, že je hodně specifické co se týče designu a sám jsem věcem ze Skype toolu na chuť nepřišel (ale neměl jsem ani moc velkou motivaci).
https://pgxn.org/dist/qgres/
Jsem nadšen ze změn partitioningu a nemohu se dočkat, až je nasadím. Ale vzhledem k náročnosti migrace a očekávaná zlepšení nejspíš počkám na pg11. https://www.postgresql.org/developer/roadmap/ ale neukazuje, na kdy je plánována. Dá se odhadnout, kdy by tak mohla být +- čtvrtletí?
Další dotaz je, zda je k dispozici nějáký doporučený postup při migraci stávajících child tabulek na nové deklarativní partitions.
Pouzivame PgSql v produkcii (archivacia nameranych udajov). V porovnani s Oracle vyhrava co sa tyka spolahlivosti a bezudrzbovosti, ako aj jednoduchosti konfiguracie.
Kde je Oracle lepsi - ma IOT (index organizovane tabulky), co v praxi znamena, ze index a data su v kope. Kedze nase tabulky vyzeraju tak, ze maju par stlpcov (cas-kluc, hodnota, priznaky, dalsie priznaky) tak Oracle dokaze data zapisovat ovela uspornejsie (povedzme ze 2x).
Takze jedine co mi chyba su tie IOT a potom uz budem uplne spokojny :)
Ale aj tak je to skvela databaza; vychutnali sme si najma upserty v 9.5 ...
Přesně na tohle jsou v Postgresu pole. To, že máte 2x větší soubor asi není kvůli indexům, ale kvůli implementaci MVCC v Postgresu. Každá verze řádku obsahuje kromě vlastních dat ještě 21 režijních dat, což je u úzkých dlouhých tabulek znát.
A přesně z tohoto důvodu je vhodné v postgresu používat pole - pokud byste do jedné hodnoty uložili 3600 hodnot, pak tahle režije není na 1 řádek, ale na 3600 hodnot - navíc díku TOASTu to pole bude na pozadí zkomprimované. Mohl bych Vám nabídnout školení - tam přesně takové věci říkám :)
Jinak existuje relativně nový fork Postgresu pro časové řady (archivace naměřených údajů) je dělaná https://github.com/timescale/timescaledb
Dakujem Vam za informacie!
Pozeram trochu to pole, ale mam s tym problem. My pre kazdy archivovany objekt v SCADA systeme vytvarame separatnu tabulku (kvoli tomu, ze uzivatel si na kazdom objekte specifikuje casovu hlbku - ako dlho sa uchovavaju data. Starsie data su raz za N hodin mazane). Niektore objekty su zmenove (pricom niektore sa menia az viackrat za sekundu, niektore raz za N dni). Niektore su periodicke (casto 1min, 15 min, hod, 24 hod). V jednej aplikacii mozu byt stovky az desattisice objektov. Takze ked archiv vklada do DB, tak data "rozhadzuje" do vela tabuliek (pouzivajuc predkompilovane indexy). Keby sme mali tie polia, tak by musel nacachovat data a vlozit ich tam naraz (alebo postupne do pola pridavat, co by zase robilo nove verzie riadkov az kym by sa nevycistili cez vacuum, nie?).
Okrem tabuliek pre jednoduche hodnoty (stlpce cas, hodnota, priznaky, dalsie priznaky - index nad casom) su podporene tabulky pre stlpce struktur (navyse v tabulke je este stlpec "row", index je podla "row" a cas) a cele struktury (tam su navyse stlpce "row" a "col", index je "row", "col", cas).
Index je taky aby bolo rychle vyberanie hodnoty podla casu (select .. where cas>=t1 and cas<=t2, pripadne where cas < t).
Kedze sa ale data vacsinou vkladaju s casovymi znackami zhruba kopirujucimi realny cas, tak v tych stlpcovych/strukturovanych su rozhadzane po disku. Takze ked pre konkretny "row" resp. "row/col" hladam data, tak rychlo prejde index ale potom zhana data po disku.. v pripade Oracle rychlo prejde index a data ma v ramci indexu, takze je to ovela rychlejsie. Samozrejme, pomoze "upratanie" prikazom cluster (pri vytvarani tabulky zapiname CLUSTER ON index).
Určitě není dobrý nápad dělat UPDATE nad polema - ty se obvykle připraví externě, nebo v uložených procedurách v proměnných, a pak se insertnou, a tak by měla více méně zůstat. V případě vyhledávání lze použít index, případně lze pole funkcí unnest převést na tabulku. Někdy se bokem uloží min, max z pole, aby se zjednodušily operace a nemuselo se pole pokaždé rozbalovat.
Samozřejmě, že nemůžu tvrdit a netvrdím, že pole jsou řešením pro každého (je to doporučené řešení, ale ne vždy je to možné použít). Případně, pokud aplikace podporuje zároveň Postgres a zároveň Oracle, tak implementace přes pole být příliš odlišná od Oracle a implementačně neefektivní.
Tam bohužel pro Vás, Postgres clustrovaný tabulky nemá a neuvažuje se, že by měl - připravují se spíš optimalizace organizace indexů, aby se urychlil UPDATE na řádcích s velkým množstvím indexů. Tady je pak už jediná možnost SSD nebo hodně RAM, čímž se neguje cena za random IO.
Dakujem Vam za odpoved pan Stěhule,
Nad tymi SSD uvazujeme.
Zatial sme v archive implementovali vlastnu cache. Dnes uz je RAM niekde inde ako pred 10 rokmi, takze su zakaznici, kde moze mat aplikacia pristupujuca k datam (archiv) napr 2 alebo 6 GB RAM cache do ktorej sa vmesti poslednych niekolko dni. Takze bezni uzivatelia pozadujuci cerstve data (napr. do grafov za poslednu smenu/24 hodin a pod) ich maju do niekolko ms bez dotazovania databazy. Ostatni si pockaju (nove data idu z cache+starsie cez dotaz do DB).
Taktiez mame "casove rezy" - 'partitioning' ktory si robi samotna aplikacia - 30 dni naplna tabulku a potom urobi dalsiu - a po naplneni ju vieme upratat (cluster table) takze ta fragmentacia starsich dat sa poriesi. (casove rezy su teda funkcne napr. aj na Oracle SE/SEO/SE2 kde partitioning nefunguje z licencnych dovodov).
Pouzivame PgSql na Windows platforme; ked konvertujem databazu z Oracle, zvycajne zapinam NTFS kompresiu na adresari s databazou; kompresny pomer byva spravidla 2:1 (az 2.5:1), cim sa mi velkost dat oproti Oracle plus minus nezvacsi. Na vykone pri zapise kompresia ma vplyv na urovni niekolko % (akurat zalohovanie je pomalsie).
Co je ale pre mna najdolezitejsie: postupne nasadzujeme PgSql na viacerych zakaznikov a aj ked ma nizsi vykon ako Oracle, tak POSTACUJE. Tj. existujuce zelezo to utiahne (o novom ani nehovorim), takze nic z toho, co spominam, nie je taky problem, aby sme Postgres nepouzili.
Dakujem Vam aj za tu TimescaleDB, urcite vyzera zaujimavo a vyskusame ju ..
zde v diskuzi je nekolik nazoru ohledne Oracle versus Postgresql. V tomto ohledu me zaujal clanek na abclinuxu, ve kterem je prezentovana strategie Oracle vuci Cloudu.
Zjednodusene receno se tam vypravi, jak Oracle brzy pobezi jen v cloudu a admini nebudou vubec potreba, O vse se postara umela inteligence.
Ja vim, ze Larry Ellison je pekny tluchuba a navypravi toho hodne, jak je den dlouhy, ale v tomhle si myslim, ze na to jde chytre. Dokonce mam ten dojem, ze tu jejich celou AI udelaji tak, ze v pripade potreby pridaji dynamicky procesory a pamet :-).
Myslim, ze tahle tematika zatim Oracle a Pgsql diametralne odlisuje. Jsem presvedcen, ze cela IT a i cela spolecnost stoji pred tou 'automatizacni' problematikou a nevyhne se tomu nikdo. Nekolik mych kolegu je v projektech, kde jde o podobnou problematiku - totiz o to, aby fabrika fungovala bez lidi - napr. nakupciho dnes nahradi pocitac uplne bez problemu.
Cele to nebude zitra a pan Stehule bude urcite jeste leta delat ta skoleni , ale dyl jak do penze to nebude.
Co sleduji výzkum v oblasti databází, tak na nějaké formě integrace adaptivních algoritmů se už pracuje 20 let - ať už je to automatická tvorba indexů, automatický partitioning, automatické přeplánování - na cloudu automatickou alokaci zdrojů. Nebo se celá inteligence redukuje a jde se inteligentní hrubou silou - sloupcové databáze, push místo pull executoru, nebo úplně jiný směr - map/reduce přístup. Je hodně nových zajímavých databází souhrnně označovaných jako New SQL.
100% tyto nové databáze budou mít hodně zajímavé vlastnosti. Horší to bude se stabilitou (ze začátku).
Postgres je hodně konzervativní (preferuje se stabilita provozu a dlouhodobá udržitelnost projektu před experimentováním). Na druhou stranu není to zavřený projekt a dost experimentů v této oblasti vychází z Postgresu (postgres má super API a je skoro neuvěřitelné, co se dá s PG udělat, když se využijí veškeré možnosti rozšiřitelnosti). Některé hodně zajímavé věci jdou i do upstreamu - řekl bych, že Pg je hodně na špici, co se týká nabídky indexů. Připravuje se integrace JIT, existují prototypy ACID memory engine.
Do důchodu bych měl teoreticky za 20 let - myslím si, že tu ještě Postgres bude - je to stavěný poctivě. Určitě tou dobou bude IT vypadat jinak, a budou modernější systémy, ale dobré věci zůstávají dobré pořád. Unix vypadá pořád stejne, Cčko také a podobné je to s Postgresem. Díky licencím Postgres není vázaný na konkrétní firmu - neroste s ní, nepadá s ní. Dokud budou kreativní vývojáři a dokud se data budou dávat do databáze a bude se používat SQL, tak tu bude Postgres.
Nemůžu si pomoct, ale takový názor mi připadá směšný. A to i za předpokladu, který je víc než pravděpodobný, totiž, že singulární AI je jako fenomén navyhnutelná a je to otázka tak 10-20 let.
Ale vyvozovat z toho naprosto konkrétní závěry, to mi připadá jak když si komáři kdysi představovali, jak poroučejí větru dešti... Když už jsme u těch "adminů", tak by se měl říct jaký je smysl práce admina, ne jeho konkrétní současná náplň. Jestli je tím smyslem provádění rutinní práce a opravování triviálních chyb, tak takové tvrzení může platit (s ohledem na rozvoj samoopravujících se AI). V tom případě ale totéž se bude týkat všech rutinních profesí, toto není žádné specifikum oblasti DB, natož oracle a postgresql. Celkově vidím přispěvek úplně mimo, ono už začínat argumentací subjektivem "Larry Ellison je tlučhuba" mluví za vše....
Jako Oracle admin se o praci nebojim. Ver. 12.1 prinesla adaptivni exekucni plany, zajimava myslenka ale nebylo to dost odladene. Ve verzi 12.2 uz je to by default vypnute. Verze 12.2 (RAC) dokonce uz ani nejde nainstalovat, funguje pouze upgrade z 12.1. Nova verze Oracle rozhodne o praci adminy nepripravi, max. tak prijdou o dusevni zdravi.
Nepoužívejte DELETE ale partitioning. Zabbix jej umí
https://www.dasm.cz/clanek/zabbix-postgresql-a-table-partitioning
https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_autopartitioning
Perfektni shrnuti, diky za nej.
Par poznamek do diskuse:
- columnstore v postgresu pouzivame uz roky od citusu (cstore_fdw), na BI ucely nebo archivni data parada, neni to tak uplne komfortni jako v MSSQL / Oracle, ale vlastne to staci naskriptovat jednou, respektive tenhle druh skriptu se neprepisuje kazdy den, mozna ani kazdy rok ;)
- partitioning v 10ce si zaslouzi potlesk
- paralelizace nekterych operaci v clanku zabrala tri radky, ale nemela by zapadnout ;)
- data governance v plenkach ... ano i ne, dost zalezi na navrhu databaze
- scheduling (aka resource governor, jestli jsem to dobre pochopil), pekna featura, ale v 24x7 k nicemu a napr. v provedeni od MS je to spis dalsi zrout prostredku / generator resource waitu a komplikator prostredi ;)
- BI JDBC/ODBC nesmyslny errory, nerovnomerny throughput, ruzna zajimava preteceni apod. to se deje snad uplne u vsech zdroju dat, nic typickeho jen pro postgres, mssql, hive, impala, vertica i pitomy CSVcka.
BTW.: Nekdo do Varsavy?