Vlákno názorů k článku PostgreSQL 12 – bude rok 2019 rokem Postgresu? od ITFUN - V prvom rade vďaka za článok - je...
-
V prvom rade vďaka za článok - je veľmi odborne napísaný. Ja sám však som laik, ktorý by rád použil PostgreSQL práve v kombinácii s Javou. Na youtube som našiel toto video https://www.youtube.com/watch?v=-tUdTxHOB90
Toto video porovnáva out-of-the-box výkon PostgreSQL 9.2, Oracle 11g Xe a Microsoft SQL 2005 EXPRESS.
Videom som bol troška zdesený, že v rýchlosti vyhrával práve MS SQL v Express verzii.
Veľmi by ma potešil /možno aj ostatných/ článok o PostgreSQL optimalizácii. Jediné čo viem o optimalizácii ohľadne databázy, je nutnosť dostatočnej veľkosti RAM-ky a použitie rýchleho SSD disku najmä čo sa týka výkonu 4K Write a 4K Read - súdiac podľa článku na phoronix.com https://www.phoronix.com/scan.php?page=article&item=intel-ssd-660p&num=2 V článku na phoronix.com je test zvaný PostgreSQL pgbench v10.3 a v tomto teste Intel Optane 900p má najvyšší výkon v teste - pretože má ohromný výkon v 4k Read a v 4k Write.V postgresql plánujem vytvoriť 600 tabuliek, ktoré budú mať tieto stĺpce.
1.stĺpec - BIGSERIAL -AUTOINCREMENT Primary key napríklad 1,2,3,4,5,6 atď.
2.stĺpec- TIMESTAMP napríklad 2019-01-29 01:36:14.123456 - bez časovej zóny
3.stĺpec REAL
4.stĺpec REAL
5.stĺpec REAL
6.stĺpec REAL
V SQL dotazoch chcem použiť zoradenie údajov podľa TIMESTAMP - údaje budú tiecť z postgresql do mojej aplikácii napísanej v Jave.
Úplne jednoduché SELECTY a INSERTY.
Ak by niekto vedel poradiť ako mám zoptimalizovať PostgreSQL v takomto mojom scenári - poprosím o radu. -
Ten test je zvláštní - jestli jsem to pochopil, tak je to o rychlostech INSERTu (z toho videa ale nejde pořádně nejde odhadnout, co to dělá). MS SQL i v Express edici je psaný primárně pro Windows (vlastně pouze pro windows). Oracle i Postgres jsou naopak primárně Unix databáze - vnitřek Oracle neznám, ale o Postgresu se dá říct, že je to primárně Unix databáze, kterou lze spustit na windows, která nevyužívá žádné speciální optimalizace pro win. U téhle úlohy je to primárně o tom, kolik Vám dá operační systém IO. Postgres používá filesystém API bez jakékoliv prioritizace - a koneckonců dá se předpokládat, že Microsoft bude mít svou databázi pro svůj operační systém vyladěnou (a naopak). Z toho videa se vůbec nedá říct, v čem je problém - není vidět zátěž CPU, IO a já vůbec neznám .NET driver, abych odhadnul v čem je problém.
Na tom Vašem příkladu v podstatě není co optimalizovat - je to vlastně jen asi o konfiguraci shared buffers, aby se vám v RAMce udržely důležité části indexů. Případně možná o vypnutí synchronního commitu. Jinak ty phorox testy jsou pro praktický život dost na nic. Určitě nikdy nebudete mít a ani nechcete mít stejnou zátěž jako generuje pgbench. Je tam hromada dalších faktorů, které mohou mít vliv, a syntetické testy nic neříkají o normální zátěži, stejně tak o zátěži, kterou může generovat vaše aplikace.
-
Vážený pán Stěhule,
veľmi pekne ďakujem za vašu reakciu a za vaše cenné pripomienky. Váš príspevok som si uložil, budem ho mať na očiach, keď budem ladiť svoju postgresql databázu, ktorá bude prevádzkovaná samozrejme na Linuxe.
Ohľadne toho videa určite máte pravdu, MS SQL je vyladený pre Windows a Oracle a Postgresql sú pre Unix/Linux.
Ešte raz ďakujem za vaše cenného pripomienky. -
To tvrzení o MS SQL bych si dovolil rozporovat, Microsoft tu Linux verzi vyvíjí už déle a od prvních kroků, kdy to bylo na Linux spíš jen "nabastleno" se to docela posunulo a optimalizace už je dnes slušná (zlí jazykové dokonce tvrdí, že občas podává MS SQL na Linuxu lepší výsledky než na Windows Serveru). To vámi odkázané video nemá se současným stavem nic společného, je z roku 2013, kdy Linux verze MSSQL ještě neexistovala a mimochodem v testu užitý SQL Express 2005 byl dost přežitý už tehdy i na Windows.
Jinak ale smysl Linux MS SQL verze je spíš k možnosti nasazení aplikace vzniklé na Windows a MS SQL na více platforem. Pokud tvoříte něco od nuly a navíc jste si opravdu jistý s tím, že to bude běhat na Linuxu, tak pak skutečně nemá pořizování licence MS SQL smysl (zadarmo je jen Express, který má limitů spoustu). Nicméně výkonu a stability bych se nebál...
-
Jenom podotek, doporucuju se podivat na TimescaleDB, je zalozena na Postgresu a slouzi prave pro ukladani time-series dat.
https://github.com/timescale/timescaledb
Alternativa je InfluxDB
Jinak pokud chces tyto data mit v cistem Postgresu, rozhodne pouzij partitioning podle timestampu, ten v danem pripade hodne pomuze.
-
Navíc má Influxdb parser vstupu (line formát) který není konzistentní sám se sebou a vhodným zřetězením backslashů vám na insert vrátí 500 Internal server error. Takže nesmíte dát útočníkovi plnou kontrolu nad jmény tagů , metrik a nad retezcovými hodnotami (stačí zakázat uvozovku uvnitř řetězce a backslash a navíc whitespace, čárky a rovnítka ve jménech metrik a tagů - ty backslahe ale můžou být problém u Windows style paths - mělo by ale stačit zakázat koncový backslash který by bylo možné interpretovat jako escape: tedy na konci, před whitespace, čárkou a rovnítkem). Pokud bych parser bral jako ukázku kódu jakým je influx napsaný, tak bych mu data nesvěřil.
