Hlavní navigace

Vlákno názorů k článku PostgreSQL 10: drsně rozběhnutý slon od Pet - Pouzivame PgSql v produkcii (archivacia nameranych udajov). V...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 10. 2017 15:23

    Pet (neregistrovaný)

    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 ...

  • 6. 10. 2017 17:58

    Pavel Stěhule

    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

  • 10. 10. 2017 6:33

    Pet (neregistrovaný)

    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/struk­turovanych 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).

  • 10. 10. 2017 19:22

    Pavel Stěhule

    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.

  • 11. 10. 2017 7:02

    Pet (neregistrovaný)

    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 ..

  • 6. 10. 2017 19:58

    DW (neregistrovaný)

    Ak tym, ze data a index su v kope, myslis na klastrovany index, tak ten ma aj postgres. Od 9.3 tusim...

  • 6. 10. 2017 20:08

    Pavel Stěhule

    Pokud vím, tak Postgres clustrovaný index nemá - možná máte na mysli index only scan - což by asi tou 9.3 sedělo.

  • 6. 10. 2017 21:23

    DW (neregistrovaný)

    Nie, mal som na mysli CLUSTER table... ale ako pozeram tak to nevytvara clustrovany index... sorry :)