Üdv Mindenki!
Több emberrel beszélgetve a PostgreSql hallatán majd hogy nem térdre borult előttem és rituális imádkozásba fogott. Viszont amikor megpróbáltam rákérdezni, hogy miért olyan jó, csak hebegett-habogott össze-vissza! Majd végül kinyögte, hogy a "tárolt eljárások" mágikus szavakat! Nem is firtattam tovább a dolgot!
Korábban már telepítettem, üzemeltettem és használtam is Oracle-t, MySQL-t, és volt némi szerencsém a PostgreSql-hez is - szerencsére csak kicsi! Minap viszont azzal bíztak meg, hogy két - sajnos - windows-os gépen lévő PostgreSql között alakítsak ki valami replikáció féleséget! Nem cél a terhelés elosztás csak redundancia! Már ott megbukott a dolog hogy "100 fajta" replikációból a negyede se működik windows-on és természetesen a 64bit is megnyirbálta a lehetőségeket. Persze persze lehet mindenféle forrásból így-úgy okos dolgokat forgatni, de ha nem muszáj akkor inkább nem vállalnám be!
Végül a streaming replication tűnt a legelfogadhatóbbnak, neki is álltam beállítani. Arról nem beszélnék, hogy normális dokumentáció a világ sincs róla, de csak egy nagy szenvedés az egész! A slave szervert egyszer állította le azóta el se lehet indítani és még sorolhatnám a problémák hegyeit! Én elismerem, hogy béna vagyok, de nem sok híja van, hogy ez egész mindenséget kivágjam a bezárt ablakon keresztül, pedig nem egy évet töltöttem el szakmában, és nem csak windows láttam életembe!
Az igazi kérdés most jön! Miért is olyan nagyon jó ez a PostgreSql? Amikor a MySql-en néhány paraméter beállításával már hasít is a replikáció tovább ha jól tudom, akkor MySQL-be is megvalósították a tárolt eljárásokat! Az Oracelről csak azért nem beszélnék mert szerintem az nem hobbi kategória!
Várom a pro és kontra érveket a PostreSQL mellett és ellen!
T.
Hozzászólások
Amiért mi használjuk:
- Nem GPL-es licenszelés
- Tárolt eljárások
- Amikor átálltunk, sokkal több feature-t tudott, mint a MySQL, pl. geo kiegészítések
- Stabilabb az egész, sosem volt olyan, hogy elszállt volna, vagy elszállás esetén ne lehetett volna visszaállítani
Én a következők miatt preferálom a PostgreSQL-t:
* FULL JOIN: általában nem kell, de amikor elromlik az adat, és meg kell nézni, hogy melyik sornak nincsen párja, nagyon hasznos tud lenni. Persze lehet FULL JOIN nélkül élni, 2-3 lekérdezés eredményének összefűzése ugyanezt adja, de stresszhelyzetben szeretném, ha nem kellene ezzel foglalkoznom.
* Sokkal-sokkal több adattípus: MySQL-ben van 2-3-féle int, 2-3 szöveg, pár lebegőpontos, meg még ez-az. De nincsen UUID, ami akkor jó, ha olyan rekordokat akarok tárolni, ami globálisan unique. AZ IP típus inkább kedves, enélkül tényleg lehet élni. Az XML már annák hasznosabb! A GEO típusokat egyelőre nem használtam, de eljöhet még az ideje.
* Tömbők: egy oszlopban tárolhatok tömböt.
* MVCC: ugyan a PG csak egyféle storage engine-t támogat, az viszont teljesen ACID compliant (nem tudom, mi a megfelelő magyar szó), és a hangsúlyt az adatok megbízható tárolására helyezi. A MySql-nél volt egy hiba, nem tudom, hogy kijavították-e azóta, de a REPEATABLE READ izolációs szint nem volt rendesen megvalósítva.
* A tárolt eljárásokat sokfajta nyelven lehet megírni, nyilván azt kell választani, ami az adott esetben a legcélravezetőbb. Az persze luxus, hogy mindegyik tárolt eljárást más nyelven...
* Sémát: MySQL: 1 séma = 1 adatbázis. PostgreSQL: 1 séma = 1 séma. Az adatbázis pedig egy másik dolog.
* TableSpace-ek: nem tudom, ennek van-e MySQL megfelelője. Mindenesetre megmondhatom, hogy fizikailag hol helyezkedjen el az adatbázisom.
Hosszú a lehetőségek listája, hirtelen ez jutott eszembe.
A replikációval nem foglalkoztam, de a streaming replikáció nem tűnik bonyolultnak.
Fuszenecker_Róbert
1 adatbabisban lehet n-db sema is lehet, kulon jogokkal mint egy adatbazis az adatbazisban. de a semak atjarhatoak
az ujabb pg-k ismerik a json tipust es vannak hozza fv-ek is, tehat nem egy sima text ami json-ra van keresztelve
a legujabb pg adatbazis szinten kepes kulso adatbazisokhoz hozzaferni es onnan lekerdezni illetve oda adatot bevinni.
es igen tarol eljarasok, pl, tcl, java, perl, c, stb
es igen van replikacio es terheles elosztas is.
es meg kis millio mas dolog, ami leginkabb csak erdeklodes es alapos utanjaras utan fedez fel az ember.
szoval pg rulez :)
Igen, félreérthetően fogalmaztam:
"1 séma = 1 séma"
Ez alatt azt értem, hogy a sémákat rendesen/szabványosan valósították meg.
Fuszenecker_Róbert
A tablespace-k leteznek MySQL oldalon is, de asszem csak InnoDB engine eseten.
--
És ahogy két napja felfedeztem, elég macerás a használatuk.
(hidden subs :) )
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Szerintem balgaság lenne azt mondani, hogy a PostgreSQL a király, a MySQL pedig a Sátán műve.
Nyilván van a MySQL-nek 666 olyan feature-e, ami alkalmassá teszi pl. webes alkalmazások fejlesztésére.
A MyISAM gyors, mint a willám, persze ennek az az ára, hogy nincs tranzakció és foreign key (sőt, mintha az izolációs szintek is csak elméletileg léteznének).
Bankban ez nem jó, ott az adatok megbízható tárolása az elsődleges, de egy fórumon ha elveszik egy-egy komment... veszett már több is Mohácsnál.
Úgy tudom, a users tábla is MyISAM, ami szintén jó, ha a web alkalmazás gyakran kapcsolódik-bont.
Az utóbbi időben mindig azt hangoztatom, hogy mindent arra kell használni, amire a legcélravezetőbb.
Nincsenek csodák a szakmánkban sem. Csodaszerek sincsenek. Az a mérnök feladata, hogy megtalálja a kompromisszimos megoldást, ha lehetséges, a legjobbat.
Varietas delictat.
Fuszenecker_Róbert
MySQL esetében van egy komolyabb gond is állítólag: a licenc. Nem néztem még soha utána, szóval mérget nem vennék rá, de mintha lenne valami kavar az üzleti felhasználással.
Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)
Nos, ennek valóban nem jártam utána. Köszi az infót!
Fuszenecker_Róbert
Amennyire en tudom, az opensource MySQL GA a GPL v2 ala tartozik, ami az uzleti felhasznalast nem korlatozza. Van uzleti verzioja is a a MySQL-nek, ami fizetos, van benne par plusz feature es persze jar hozza support.
--
* aszinkron értesítés (LISTEN, NOTIFY), publisher-subscriber pattern
Fuszenecker_Róbert
Feltételezve, hogy 9-es verzió van használatban, itt lépésekben leírtak mindent:
http://wiki.postgresql.org/wiki/Streaming_Replication
A 12-es pont után pedig ott van, milyen esetekben mit kell tenni. Valószínű neked a slave-en a 6-os ponttól kell újraépíteni. Nem egy nagy ördöngösség, két parancs között egy darab rsync.
En azt hallottam, hogy a MySQL tarolt eljarasok messze nem kompatibilisek a szabvannyal, raadasul vannak hianyossagaik. De ezen nem fogunk osszeveszni.
--
Google these:
- repmgr
- pgbarman (just in case)
- WAL-E postgresql
|| "Software is like sex: it's better when it's free." Linus Torvalds
anno mikor kezdtuk a postgressel, az akkori top programolo miutan megtekintette a mysql feature listajat, annyit mondott : fapad.
en akkoriban csak egyvalamit hianyoltam a mysqlbol : a tranzakciokezelest. azt már dos/novell alatt a btrieve is hozta.
mára a mysql sokmindenben beelozte a postgrest, csak eppen az igazi terhelés alatti stabilitásban nem, az elmúlt 13 évben nem volt (csak hw hiba miatt ) postgres adatbázis összeomlásom, ellenben tegnap epp egy (/ illetve az említett időablakban több /) mysql szervert kellett backupbol helyretenni...
Nem tudom, ez nekem olyan kriptikus, mint masnak az en XFS nyugjeim. Nekem sose szallt meg el MySQL adatbazisom magatol, mindig valami diszk/fajlrendszer crash vitte el oket. Illetve egyszer valt ket MyISAM tabla olvashatatlanna, de ott is volt fajlrendszer hiba (legalabbis az fsck megkohogte a particiot).
--
Egyszerűen szabványosabb, jóval egyszerűbb később migrálni bármi másra, ha már ki lett nőve a postgres. Legegyszerűbb oracle felé migrálni.