PostgreSQL 9

PostgreSQL

A PostgreSQL Global Development Group bejelentette nyílt forrású adatbázis-kezelőjének 9-es kiadását. Ez a kiadás nagy (major) kiadás, így ennek megfelelően számos új szolgáltatást kínál:

  • Replication and Scalability
    • Hot Standby
    • Streaming Replication
  • Administration and Security
    • Integrated Upgrade-in-Place (pg_upgrade)
    • RADIUS Authentication
    • Password Strength Checking (passwordcheck)
    • Easier Database Permissions Management Commands (GRANT ON ALL and DEFAULT PERMISSIONS)
  • Database Design and SQL
    • Deferrable Unique Constraints
    • Conditional Triggers
    • Column Triggers
    • Ordering in Aggregates
    • New Windowing Functions (ROWS PRECEDING and FOLLOWING)
  • Stored Procedures
    • Anonymous Procedure Code Blocks (DO statement)
    • Improved Perl and Python Stored Procedures (including support for Python 3)
    • Named Parameters in Stored Procedure Calls
  • Performance and Advanced Features
    • Improved Event Messaging (LISTEN/NOTIFY)
    • 64-bit Windows Support
    • Optimization for ORM-Generated Queries (JOIN removal)
    • Unique Keys for Non-Scalar Data (Exclusion Constraints)
    • Expanded Support for Key-value Data (HStore)
    • JSON and XML Explain Plans

[ Sajtóhír | Kiadási megjegyzések | Újdonságok a 9.0-ban ]

( uid_194 | 2010. 09. 22., sze – 11:32 )

Conditional triggers \o/
Column triggers \o/
Tobbi josag \o/

Vartam mar egy ideje ezt a releaset

Nem sok kifejteni valo van: arrol van szo, hogy van par hobby projectem, amikhez szerettem volna a ket emlitett trigger fajtat hasznalni, mert epp beleillik abba, amit akarok. Pl jelenleg - peldaval elve - ha megvaltozik egy jelszo, akkor a programom kuld egy signalt a tobbi reszenek, pluginoknak, stb, hogy haho, tortenes van, aztan azok majd csinalnak valamit, pl lelogoljak.

Ezt a column trigger teljesen jol lefedi, igy nem kell a programomnak szorakozni ezzel, elintezi a DB.

Szinten hasonlo, amikor markdown szoveget tarolok, ami kb sose valtozik: ezt tarolom eredeti markdown formaban is, es htmlkent is, hogy ne kelljen mindig ujra es ujraformazni. A programom az adott objektum minden mentesekor ezt ujrageneralja jelen pillanatban. Column triggerrel problema nelkul meg tudom oldani, hogy ezt ne tegye, csak ha updatelodik a kerdeses oszlop.

Szinten ebben a programban van egy fajta quota (feltoltott fileok szama N intervallumon belul) - jelenleg ez ugy van megoldva, hogy adott muveleteknel lefuttatja a quota ellenorzest, meg X idonkent cronbol is, majd az allapotot felveszi adatbazisba. Ez nem szep, egyik resze sem, WHEN trigger megoldja a problemamat egyszeruen es problemamentesen.

A deferrable primary keys szinten egy olyan dolog, ami jol jonne: db fejlesztes soran belefutottam parszor abba, hogy elesben szerettem volna modositani a dbn, a muvelet vegere konzisztens allapot jott volna letre, de kozben lett volna utkozes. Igy lett belole egy export, modosit, import... deferrable keyekkel ezt elesben meg tudom csinalni. Ehhez kapcsolodva, az hogy unique constraint hiba eseten sokkal jobb hibauzenetet kapok (benne van az is, hogy melyik key utkozik, pl) szinten tetszetos dolog - bar felmerul az is, hogy ez eddig miert nem volt, eleg alapdolognak tunik :P

Ezen kivul ott van meg a pg_upgrade script, upgradek segitesehez. A jelenlegi upgrade (legutobb 8.3-rol 8.4-re) nem epp a szivem csucske.

Amikor beuzemelem az uj szerverem, a hot replicationnel is el fogok jatszani, mert jopofa. Szuksegem ugyan nincs ra, dehat az ember szeret jatszani.

Tarolt eljarasokat eddig nem nagyon hasznaltam, de a fentebb emlitett fejlesztesek + a nevesitett eljaras parameterek maris szimpatikusabba teszik a dolgot.

Roviden ennyi. Van meg sok mas uj feature amivel eljatszadozom, de ezek dobogtatjak meg pici szivem.

> peldaval elve - ha megvaltozik egy jelszo, akkor a programom kuld egy signalt a tobbi reszenek, pluginoknak, stb,
> hogy haho, tortenes van, aztan azok majd csinalnak valamit, pl lelogoljak.
>
> Ezt a column trigger teljesen jol lefedi, igy nem kell a programomnak szorakozni ezzel, elintezi a DB.

Egy "sima régi" trigger miért nem (volt)jó erre? Azzal is megoldható, csak kell egy plusz vizsgálat ( NEW.paswword <> OLD.password ) de ez valóban "gáz" hogy bármilyen adatváltozásra eldurran, így több a költsége

(nem kötözködöm, csak tényleg érdekel.)

> A jelenlegi upgrade (legutobb 8.3-rol 8.4-re) nem epp a szivem csucske.

dump, upgrade, restore (persze ha nem hot-hot-line a szolgáltatás):

http://www.linuxinsight.com/optimize_postgresql_database_size.html

> Amikor beuzemelem az uj szerverem, a hot replicationnel is el fogok jatszani, mert jopofa. Szuksegem ugyan nincs
> ra, dehat az ember szeret jatszani.

Ez nagggyon érdekelne engem is, ha van eredmény jó lenne ha írnál róla

> Egy "sima régi" trigger miért nem (volt)jó erre? Azzal is megoldható, csak kell egy plusz vizsgálat ( NEW.paswword <> OLD.password ) de ez valóban "gáz" hogy bármilyen adatváltozásra eldurran, így több a költsége

Megoldhato, csak mint irtad, kell egy extra vizsgalat, es minden updatere elougrik, amit annyira nem szeretnek. Akkor mar inkabb megoldottam a sajat programbol, ugy hatekonyabb.

> dump, upgrade, restore (persze ha nem hot-hot-line a szolgáltatás):

Nem azt mondtam, hogy nehez ;)

Abba futottam bele, hogy debianom upgradeltem lennyrol squeezere, ez felrakta 8.4-et, 8.3-at meg leszedte, de automatikusan nem upgradelt. Ellenben sikerult valahogy osszehoznom, hogy 8.3 meg futott - igy minden mukodott is szepen. Egeszen addig amig nem akartam kezzel turkalni, mert akkor kiderult hogy hat ezt meg nem upgradeltuk sajna.

Ugyhogy levadasztam postgres8.3 debeket lennybol, felraktam, kidumpoltam, 8.4-be restore, 8.3 leszed (megint).

Ez nem teljesen postgres hibaja persze, de ha ok is fejlodnek upgrade teren, az csak jo lehet :)

( gUHU | 2010. 09. 22., sze – 11:59 )

"PostgreSQL is a powerful, open source object-relational database system."

Hát ja... :)

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

( Andrei | 2010. 09. 22., sze – 14:40 )

Eddigi felszines tapasztalataim alapjan a Postgres szamomra tobbnyire ertelmesebbnek tunt, mint a MySQL.

Miert annyival nepszerubb megis a MySQL? Van valami technologiai oka, amivel en nem szembesultem?

Az adatbázisokat használó projektek jórészének semmi szüksége nincs arra, hogy egyszerre egynél több táblából select-eljen valamit, esetleg egynél táblába insert-eljen valamit.

A MySQL default beállításokkal historikusan gyorsabban hajtotta végre az ilyen egyszerű műveleteket. Cserébe ezért a default beállításokkal a bonyolultabb lekérdezések lassabbak voltak, sérült az ACID valamelyik betűje, meg hasonlók.

A PostgreSQL ezzel szemben erősen arra törekedett, hogy a default beállításokkal, akár teljesítményvesztés árán is mindig teljesen ACID-megfelelő legyen az adatbázisuk és mindenféle workload esetén hasonló teljesítményt nyújtson az adatbázis.

Az elmondottak alapján a MySQL lett az elterjedtebb és népszerűbb.

Azért azt is hozzátenném, hogy megfelelő hozzáértéssel mindkét adatbáziskezelővel remek dolgokat lehet alkotni, és nem merném kijelenteni, hogy egyik jobb, mit a másik.

Jobb lenne, ha crashed táblákkal indulna?
Én élvezni szoktam...:)

A legjobb pl az volt, amikor decemberben a májizámcsekk behülyült a symlinkektől és kb. 20 millio rekordot truncatelt ki sikeresen 6 táblából. A viszzaállítás során meg persze egyel eltoltam a referencia tábla autoincrementjét, merugye ügyes voltam... (Mondjuk ez 5.0.51 volt.)

'lekene sslje'

azenoldalamponthu

mert az initscriptbe belerakta a debian maintainer.

#!/bin/bash
#
# This script is executed by "/etc/init.d/mysql" on every (re)start.
#
# Changes to this file will be preserved when updating the Debian package.
#

source /usr/share/mysql/debian-start.inc.sh

MYSQL="/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf"
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
MYUPGRADE="/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf"
MYCHECK="/usr/bin/mysqlcheck --defaults-file=/etc/mysql/debian.cnf"
MYCHECK_SUBJECT="WARNING: mysqlcheck has found corrupt tables"
MYCHECK_PARAMS="--all-databases --fast --silent"
MYCHECK_RCPT="root"

# The following commands should be run when the server is up but in background
# where they do not block the server start and in one shell instance so that
# they run sequentially. They are supposed not to echo anything to stdout.
# If you want to disable the check for crashed tables comment
# "check_for_crashed_tables" out.
# (There may be no output to stdout inside the background process!)
echo "Checking for corrupt, not cleanly closed and upgrade needing tables."
(
upgrade_system_tables_if_necessary;
check_root_accounts;
check_for_crashed_tables;
) >&2 &

exit 0

http://www.mysqlperformanceblog.com/2009/01/28/the-perils-of-innodb-wit…

Tyrael

persze, biztosan.
azt ugye tudod, hogy az osszeborult tablak szepen reklamalnak, ha repair-re van szukseguk.
ez kb. olyan, mintha a scandisk/checkdisk/fsck minden restartnal lefutna, nem csak crash vagy mondjuk az elore beallitott (mondjuk evente egyszer) intervallumonkent.
raadasul akkor is lefut, ha nincsenek is myisam tablaid, szoval nagyszeru megoldas.

ettol fuggetlenul meg mindig kivancsi lennek ra, hogy ha minden restartnal lefut ez az ellenorzes, akkor miert kellett kulon kihangsulyoznod, hogy neked mysql inditas utan korrupt tablakat keres az init script, hogyha ez szerinted helyenvalo mukodes.

szerintem a maintainer reszerol egy gagyi megoldas egy nem mindenkinel letezo problemara.

Tyrael

oké, akkor bontsuk ki az okot és az okozatot.
az, hogyha reális esélye van annak, hogy korrupt táblák előfordulhatnak, akkor helyes, hogy indításkor ezt ellenőrzi. de ez az okozat, nem az ok.
az ok az, hogy a mysql képes összeborogatni a myisam táblákat. és erre céloztam, hogy ez azért nem teljesen normális, így érthetetlen, hogy miért lett annyira népszerű...

"nekem még ma reggel is úgy indult a debianom, hogy a mysql indítás kiírja, hogy korrupt táblákat keres..."

erre irtam, hogy mindig igy indul debianon a mysql, es ez nem azt jelenti, hogy szukseg van ra, csak azt, hogy a maintainer belerakta.

raadasul vagy nem vagy tisztaban ezzel (ti. hogy ez debianon nem varatlan, hogy igy mukodik, es ez nem is default viselkedes), vagy szandekosan probalsz meg hangulatot kelteni.

ugyhogy lehet jobbra balra terelni, de legkozelebb ha csak be akarod irni, hogy a mysql szar es kesz, akkor ird be azt, ne probald meg ilyen alszakmai suletlensegbe csomagolni, hogy megalapozottabbnak tunjon az allitasod, mint amilyen valojaban.

vegyel peldat gabuccino-rol
http://hup.hu/node/89115#comment-1065328
o nem probalja szakmai ervekkel bizonygatni az igazat es megis milyen jol megvan. :)

Tyrael

Persze, tegyuk hozza, ha es amennyiben jol ertelmezed az init script uzenetet. Mert peldaul Gentoo-n nem keres korrupt tablakat, akkor ezek szerint Gentoo-n egyenerteku a Postgre es a My ?

Nem akarom azt mondani, hogy az erveid egy picit furcsak. Oke, nagyon. Teny, hogy _neked_ tobbszor omlott ossze MySQL, es teny, hogy sokaknak soha nem omlott ossze. Miert erzem vajon a parhuzamot, hogy egy szinvak probalja magyarazni, hogy az eg pedig nem is kek?
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"Teny, hogy _neked_ tobbszor omlott ossze MySQL": ezt te honnan veszed? kotord már elő ennek a forrását légyszíves.

A tény az, hogy itt többen is írták, hogy a mysql gyakran megborul. Az érveimet meg mindenki, kivétel nélkül mindenki furcsának szokta találni, akinek más véleménye van, ez a legenyhébb jelző, amit használni szoktak.

"Miert erzem vajon a parhuzamot": mert az álmaid alapján vitatkozol és nem tények alapján.

Teny, hogy en egy tobbgigas adatbazist uzemeltettem, es soha semmi gond nem volt vele, azon kivul, hogy idonkent kinotte a disket, es kellett egy masikat alatolni. Ezt a db-t eleg komolyan terheltek, megis, osszeomlasa soha nem volt. Annak ellenere, hogy a MySQL inditaskor megnezte, hogy nem korrupt-e valahol.

Az a hiba az ervrendszeredben, hogy a MySQL inditoszkriptje azert ellenorzi az osszeomlasokat, mert a MySQL neha osszeomlik. Ez persze lehet igaz, de igaz lehet a PostgreSQL-re is, az is ossze tud omlani - noha senki nem ellenorzi ezt, valoszinuleg mert a csomag maintainere lusta volt az ellenorzest megirni.

Lehet amugy, hogy osszetevesztettelek valakivel, es nem neked szakad ossze rendszeresen a MySQL, akkor bocsi.

Ezzel egyutt hibasan ervelsz. Elfogadhato lenne a velemenyed, ha nem arra alapoznad, hogy egy init script inditaskor korrupt tablakat keres. Ennyi erovel en is mondhatnam, hogy hat nyilvan akkor Debianon szar a MySQL, mert nekem Gentoo-n, sot Mandriva-n se keres soha korrupt tablakat az init script. Es pont ugyanennyi ertelme lenne az erveimnek. Szvsz kettonk kozul nem en vagyok az, aki az almai alapjan vitatkozik.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

tehat a teny az, hogy te hallomasbol szerzett informaciok alapjan vitatkozol olyan emberekkel, akiknek mondjuk elso kezbol szarmazo tapasztalataik vannak, es csodalkozol, hogy kivetel nelkul mindenki (minden ilyen vitapartner) furcsanak tartja ezeket az "erveidet".

itt a hup-on mar minden eszkozt/technologiat/architekturat leszaroztak tobben is, szoval ha az itt hallottak alapjan alakitod ki a sajat preferenciadat, akkor jobb ha maradsz a papir/ceruza kombonal.

Tyrael

Nem küzdök problémákkal az olvasás terén.

Emellett sajnos az alapján, hogy "az egyik [adatbáziskezelő] az indítóscriptek szerint rendszeresen összeomlik, a másik meg nem", mégha igaz is, akkor sem tudom kijelenteni egyértelműen, hogy valamelyik adatbáziskezelő jobb, mint a másik.

Szövegértelmezési gyakorlat, csak mert te is kötözködő hangulatban vagy.

Melyik szoftver lesz népszerűbb egy adott időpillanatban?

Szoftver A:
- van command line interfésze

Szoftver B:
- van command line interfésze
- van grafikus interfésze
- van webes interfésze

Ha ezt nem érted, akkor kár ragozni...

idézet innen: http://hup.hu/cikkek/20100922/postgresql_9#comment-1124661 szerző: syntern.
"Melyik szoftver lesz népszerűbb egy adott időpillanatban?": ez a mondat a tartalma, a szerkezete (kérdőszóval kezdődik) a mondatvégi írásjele szerint kérdő mondat.

tehát te kérdezted.

Te tényleg nem olvastad el a parent root hozzászólást, mert valami greasemonkey script kigyomlálta az oldalról, ugye? Bazzeg, megint kérdezek... Hihetetlen, hogy a megnemértésed magyarázataihoz néha kérdezni kell, bár hiába teszem, mert nem lehet Téged rávezetni a jelentésre. Mindegy.

tényleg nem értelek, elkezdted forszírozni, hogy az a program lesz népszerűbb, amit nem kell hekkelgetni. Ezzel burkoltan arra céloztál, hogy a mysql azért népszerűbb szerinted, mert jobb eszközök vannak hozzá. Erre válaszoltam, hogy a postgres és a mysql parancssori kliense között nem látok érdemi különbséget, a postgreshez ugyanúgy van grafikus kliens, mint a mysql-hez, az pedig, hogy a mysqlhez van egy webes felület, ami betörések kedvelt célpontja, nem válik a mysql előnyére. Erre próbáltam hol burkoltan, hol nem burkoltan célozni.

Mivel fentiek miatt nem látom a különbséget, ezért nem is értek egyet azzal a burkolt célzással, hogy a mysql jobb. Ha jobb, nem ezért jobb. Egyébként szerintem nem jobb, de ez más tészta. És emiatt az a korábbi hozzászólásom, hogy a rosszabb lett a népszerűbb, ezzel koherens.

Segítek, összefoglalom: szerintem az a program válik népszerűbbé, amelyikhez előbb alakultak ki használható grafikus adminisztrációs eszközök. A különbség nem a parancssoros interfészek között van, hanem abban, hogy kezdetben a pgsql-hez csak parancssor volt, míg a mysql-hez a parancssor mellett volt grafikus felület, és ez nagy előnyt jelentett a népszerűségi versenyben. A webes felület biztonsági problémái egy későbbi esemény, az már a népszerűség megszerzése után történik, az eredeti kérdés a népszerűség megszerzésére vonatkozott.
És a személyes véleményem, hogy a mysql nem jobb - bár az állásfoglalás az eddigiektől tudatosan távolmaradt, ha esetleg nem lett volna nyilvánvaló, akkor íme. Ha emiatt kötözködtél, akkor hiába volt az erőfeszítés.

Mondhatnád, hogy igazán mire gondolsz, mert így csak kóstolgatni fogjuk egymást, amíg valamelyikünk meg nem unja!

Megpróbálom másik irányból még egyszer megfogalmazni a mondanivalómat; még mindig a pontosság igénye nélkül, mert azt gondolom, hogy mindketten értünk ennyiből is:
Nem kell ssh hozzá, hogy messziről abajgatni lehessen egy postgresql alapú adatbázist.

Probaltalak ravenni arra, hogy kimondd a titkositas szot, ugyanis titkositas nelkul ilyent kiengedni publicba azonnali maglyahalalos tevekenyseg.
Egyebkent meg titkositas mellett sem jo otlet, mert igaz, hogy a belepesi adatokat nem lophatjak el, viszont direkte tudjak hekkelni az adatbazist. Hacsak nincs VPN-be rejtve, melyen eltemetve a rendszerben, akkor en eroteljesen nem ajanlanam semmilyen adatbazis portjanak kirakasat - de a VPN-nel egyszerubb az SSH.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

postgres-nek sokkal okosabb parancssoros kliense van nagyon reg (?mindig is?).
webes teren valoban kesobb lett neki jo webadminja (van mar hozza jo? vagy meg mindig a phppgadmin a csucs?)

vastag kliensre az EMS SQL Manager-et hasznaltam anno, fenyevekkel jobb volt a postgres-es verzio, mint a mysql-es, viszont mysql-bol sokkal kevesebb tapasztalatom van a fizetos admin tool-okkal (hallottam a TOAD-rol, meg hasznaltam a mysql query browser-t, meg lattam screenshotokat a mysql enterprise webadminjarol, de azt nem probaltam meg.)

Tyrael

Mi PostgreSQL-el indítottuk a weboldalunkat huh 2005 vagy mikor. Csak a baj volt a suporttal és drága is volt. Amikor áttértünk MySQL-re, akor adtak két évre, három szerverre tízezer dollárért olyan supportot hogy csak néztem. Úgy értsd, hogy felhívtad őket, fél órán belül visszahívott egy ember aki értett a témához.