PostgreSql vs MySql

Adatbázis: SQL, XML DB

Két gépen tükrözött adatbázist szeretnék építeni. Melyik DB-t ajánljátok?
Érvek, ellenérvek? :)

  • 3258 megtekintés

Szervusz !

Hasonló témájú kérdés már korábban is felmerült, mindíg az az első viszontkérdés, hogy mekkora várható adatmennyiség, milyen elosztásban (táblák, stb), ill a lekérdezés gyakorisága és összetettsége.

Mintha a PostgreSQL is fejlésztése is bizonytalanná vált, a MySQL körüli bonyodalom az jóval közismertebb. (Sun / Oracle)

Te melyiked ismered jobban?

CSZ

( janoszen v | 2009. 12. 07., h – 23:11 )

A MySQL úgy működik, hogy az egész master adatbázist read onlyra kell lockolnod (vagy LVM snapshotot készítened), ezután jöhet a dump és a master adatok mentése, amit be kell tápolni a slavebe. Ezen felül a programnak, amit futtatsz, replikáció-kompatibilisnek kell lennie (nem lehet két NOW() egy queryben, etc etc). A szoftvernek ezen felül tudnia kell azt, hogy az olvasó queryket nem a masternek küldi.

Multimasterre majdnem ugyanez igaz annyi adalékkal, hogy egyesek szerint az még kevésbé stabil. Én használom gond nélkül. Az biztos, hogy monitoroznod kell a slave lagot és ha fölmegy, akkor cselekedni. A rendszeres backup melegen ajánlott.

Nem ismerem a PostGreSQL-t, de ha ezek kizáró tényezők, akkor a MySQL nem a Te célszoftvered.

az egész master adatbázist read onlyra kell lockolnod (vagy LVM snapshotot készítened), ezután jöhet a dump és a master adatok mentése, amit be kell tápolni a slavebe.

Hat, a mysql replikacio ennel azert egyszerubb. Nem kell semmit sem RO lockolnod, csak arra figyelni, hogy minden 'iras' a masteren tortenjen, es a replikacio szepen szetteriti a modositasokat a slave-ekre.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Ha innodb tablaid vannak, akkor ha xtrabackupot hasznalsz, ez nem kell. Ha az innobackupex-et --slave-info-val hivod, akkor a mentesedben benne lesz az a binlog pozicio, amire slave-et allitanod kell utana. A xtrabackup csak io szempontbol lehet intruziv a db-re nezve, ezt pedig tudod kezelni a beepitett io throttling-gal, vagy ionice-szal.

Az ilyesmiért sajna fizetni szoktak :(
A Pg-t probáltuk sokszor szétesett, egy jó sqlserver de localon egy másik db elérése is kinszenvedés.
Ha 4GB bele férsz megnézhetett az mssql-t a 2005-től benne a replikáció esetleg linuxra sybase vagy oracle ingyenes verziója (ha tudja), lehet hogy rosszul láttom de ha már ilyen igényeid vannak az "magasabb" kategoria vagy leprogramozod aszerveren (linked server, trigger, log ship..)
választhatsz hogy fizetsz a kész technikáért vagy le programozod, "a db-d ill a tudásod méretétől függ" mindenkép "fizetsz" érte.

A MySQL doksiban azt olvastam bő egy éve, hogy a queryk bináris formában timestamppel együtt kerülnek a slavere. Mivel a query futása nem atomi, a két now kiértékelése más eredményt fog adni és ez a differencia a slaven nem lesz ugyanaz.

Ne vedd biztosra, inkább keress rá "replication safety" címszó alatt. (Sajnos telóról vagyok, nem tudom kikeresni.)

( bambano | 2009. 12. 08., k – 00:17 )

Eddigi tapasztalat:
- a postgrest nem lehet rendesen replikálni
- a mysql meg nem adatbáziskezelő:)

ezt nézegesd: http://ha-jdbc.sourceforge.net/ a végén vannak linkek, pgcluster, és különösen a belőle származtatott cybercluster felejtős. a sequoia-t kipróbálhatnád helyettem:)

A ha-jdbc-vel annyi a tapasztalatom, hogy amikor indult a thread, beírtam a guglinak a témát és kidobta:) most láttam először. Azért másoltam be, mert a végén ott van a lista általam korábban ismert cuccokról.

Amikor utoljára néztem (idén év elején) még nem volt 8.4-es postgres. Reménykedem benne, hogyha a pgcluster nem outsider projekt lesz, hanem rendesen integrálják végre a pgsql-be (a 8.4 egyik fő fejlesztési kérdése), akkor működni fog rendesen. A pgcluster egyébként jobban működött, mint a cybercluster, de az sem volt teljesen rendben.

Mi pont HA-JDBC-vel játsszunk, a következőket tudja. JDBC driver-rel elosztottan írsz n darab
adatbázist, ami elérhető. Ha egy node elszáll, és újra életre kell, akkor megírhatsz egy
merge-ert, ami szépen áthúzza az élő adatbázis(ok)ról az adatot az új node-ra.

Nekünk viszont egy másik esetben arra volt szükségünk, hogy minden adatbázisban ugyanaz legyen,
erre meg a java tranzakciós api nyújtott megoldást.

Tanulság: redundanciára érdemesebb előbb gondolni, és nem utólag behúzni, mert elég nagy
szívás :D

privát szubjektív magánvéleményem, hogy a java adatbáziskezelésétől sírhatnékom van. és vannak benne olyan eszközök (jpa?) amit mintha direkt úgy terveztek volna, hogy szivassa az adatbázisokat, pláne a clustereket.

érdekelne, hogy serialt meg now()-t meg ilyeneket hogy írsz elosztottan ha-jdbc-vel?

( fimikz | 2009. 12. 08., k – 08:35 )

postgresql.at ott van neked kello szinkronizacios szolucio postgreshez. nem ilyen elbaszott trigger-alapu, mint a slony meg tarsai.

mysql replikacioval lattam mar vicces dolgokat. query-based, na (random(), now(), stb)

Jaja, tényleg ott van, csak egy rendesebb adatbázistól úgy összefossa magát, mint az atom.
Márha a cyberclusterre gondoltál. A tárolt eljárások, a random, a serial, meg egy-két hasonló dologtól simán előfordul, hogy az adatbázis másolatai nem másolatok.

A doksiban leírnak minden szépet és jót, aminek a fele is csak feltételekkel igaz. Tapasztalat.

A cyberclustert nem érdemes használni. Forrás: a cyberclustert gyártó cég vezetője. Kifizettünk egy éves supportot, és megkaptuk a jótanácsot.

( marczi | 2009. 12. 08., k – 10:37 )

Én Slony-val replikálok Postgres-t, az előző 3 év alatt mondjuk 4-5x volt olyan, hogy elvesztette a szinkront. Ilyenkor egy újraszinkronizálás úgy 20-30 perc félmillió rekordra. MySQL-nél a master-slave megoldásnál (binlog) érdemes maradni, a master-master megoldást ugyan használjuk, de nem jó eddig vele a tapasztalat, néha nagyon sokáig (értsd: akár órás időtartam) eltérő volt a két gép tartalma.

Igen, Slony-I tényleg megér egy próbát, ha a triggerek miatti limitálás neked nem gond, akkor ez egy elég kiforrott és hivatalosan támogatott - minden külsős megoldás baja az, hogy bizonytalan mértékben késik a támogatás, tehát ős-postgresql-t kell használj esetleg miatta és fél élet munkája felreszelgetni - a frissítésről meg ne is beszéljünk.

Nekem sajnos slony-I nem volt elég és akkor jött az, amit írtam alább.

( cydrk | 2009. 12. 08., k – 11:26 )

Azt ajanlanam amelyikhez ertesz vagy amelyikhez van penzed supportot megfizetni, egyik esetben sem pedig azt amelyiket meg akarod tanulni :)

- Oracle draga es brutalis kepessegei vannak, valoszinuleg oda ahova eleg mysql vagy postgress, felesleges.
- mysql problemas lehet a jovoben a sun+oracle+mysql dolog miatt, fene tudja mi lesz (ertem itt ha vallalatot akarsz ra epiteni)
- postgress-t kicsitsem ismerem.

Talan mysql-t javasolnam, mivel konyen tanulhato, konnyeden kapsz hozza supportot akar itt is. Vannak eleg komoly kiegeszitesek hozza (mmm HA-nak vagy epp infobright engine olap es dataminingra ).
Gyakorlatilag ha tudod mit nem szabad (pl ahogy emlitettek elottem a 2 now() 1 queryben) akkor gond nelkul fog szolgalni teged. Errol van egy jo kis leiras itt xaprb. Ott van meg mysql-hez a maatkit, ha inkonzisztencia vagy performance elemzes gondok merulnek fel.

Csak rajtad all, mindenki azt ajanlja amihez a sajat szive kozelebb huzza imho.

MySQL -el ahogy mar irtak a "tukrozest" 2 fele kep tudod megoldani:
master-slave: Ezesetben csak az egyik irhato (master) es a slave-en minden adat meglesz. "Akarmennyi" slave-ed lehet.
master-master: ezesetben mind2 irhato viszont erosen experimental, hogy konzisztens maradj.

drk

( uid_15541 | 2009. 12. 08., k – 12:22 )

Az ilyen kérdések mindig megindítanak végtelen hitvitákat, nekem X szar, nekem meg Y fagyott és nincs, aki igazságot tegyen.
Ezért ebben nem tudok neked úgysem okosat mondani, mindig lesz rá ellenvélemény, leszólás, hülyevagyöcsém, stb.

Ha a postgresql mellett döntesz, akkor egy kis segítség:

Egy évvel ezelőtt szenvedtem postgresql + pgcluster bereszelésével, akkor született egy kis javítócsomag, amivel ürrepülő vizsga nélkül fel lehet telepíteni az egész motyót és még működik is:
FreeBSD 6.3 amd64:
http://zl.hu/upload/pgcluster/pgclusterz_20080916_0.tgz
FreeBSD 7.0 kiegészítések: http://pgcluster.zl.hu/
Ezekben benne van pár napnyi munka (igazából csak "reszelés" és kísérletezés, debuggolás, tehát semmi nagy durranás kód).

Ez a megoldás ment 6 hónapot, ezalatt produkált összesen egy "befagyást" egy halálra triggerezett rendszerben, tehát akár stabil is lehet egy egyszerűbb szituációban.

( ne0 | 2009. 12. 08., k – 12:25 )

akkor módosítom a kérdést:
van valakinek működő 2 gépes klasztere pgsql v mysql alapokon, ami ha elszáll az egyik, akkor rögtön használható lesz a másik(lehet master-slave, de a slave ne legyen read only master kieséskor)?

( tr1719 | 2009. 12. 09., sze – 00:42 )

Mar tobben irtak ezt a now() dolgot. Mi tortenik akkor, ha a slave eltunik egy orara egy master slave felallasban, es mondjuk az eltunese felenel jon egy query, ami leirja, hogy update valami set datum = now(). Mi tortenik, ha 30 perc mulva felebred a slave? Mit fog kapni a mastertol, es mit kezd vele, illetve O mit ir le? Mondjuk 12.00- kor tunt el, 12.30- kor jott a query, es 13.00- kor kelt fel.

Koszi.

en ugy tudom, hogy nincs semmi baj a now()-val, binlogba mar a master oraja szerinti ertek kerul behelyettesitesre.
szoval a now() replication safe, de a sysdate-rol tudom hogy nem az.
http://dev.mysql.com/doc/refman/5.1/en/replication-features-functions.h…
Unlike NOW(), the SYSDATE() function is not replication-safe because it is not affected by SET TIMESTAMP statements in the binary log and is nondeterministic if statement-based logging is used. This is not a problem if row-based logging is used. Another option is to start the server with the --sysdate-is-now option to cause SYSDATE() to be an alias for NOW().

ettol fuggetlenul meg van egy csomo dolog, amire figyelni kell:
pl. ha olyan modosito query-t futtatsz, ami limitet hasznal, akkor feltetlenul legyen valami kulcs szerint rendezve a query, mert a default rendezes az nem replication safe.

Tyrael

postgresnél azt sem mindig veszi észre a pgcluster meg a cybercluster, hogy tárolt procedúra van a selectben, ami esetleg update-t vagy insertet is végrehajthat,
azt sem mindig veszi észre, hogy a now()-t meg a random()-ot nem ártana egy clustertagon végrehajtani és behelyettesíteni az eredményét, meg voltak még ilyen szívásaim...

Ha "row-based logging"-ot hasznal csak az emeber akkor annak mi a hatranya ?
Gondolom nagyobb az adat forgalom a mastar-slave kozott. drdb -tol az altalaban kisebb -e ?

szerk:
Ha a ket szerver idozonaja ugyanaz, es mixed modot hasznal az ember, akkor milyen hatranyal kell szembeneznie ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A row es statement based replikacio kozti alapveto kulonbseget azzal erzekeltetnem, hogy mondjuk update-elsz egy tablat.
legyen a parancs update mytable set some_column = NULL where id < 100;

A statement based ahogy a neve is sugalja, ezt a statementet kuldi le a slave-re. 1 sor, 1 query viszont feltetelezi hogy eggyeznek a tablaid.

A row based eseten, az osszes sorra ahol a fenti update matchelt, bekerul 1db query a binlogba es pl ugy fog kinezni hogy
update mytable set some_column = NULL where id = 1
update mytable set some_column = NULL where id = 2
update mytable set some_column = NULL where id = 3
etc..

A teljesseg igenye nelkul csak az erzekeltetes kedveert.
Elvileg a mixed ilyen esetekben automatikusan atvalt row based-re.

A row based alapvetoen azert gond, mert sokkal tobb dolga lesz a single-thread replikacionak.

DRBD teljesen mas szinten mukodik. Block device szinten replikalja egy adott particio torteneseit es effektiv nem erdekli hogy milyen alkalmazas fut felette.

drk

( hory v | 2009. 12. 09., sze – 11:16 )

A hagyomanyos dbms-ekkel szopni fogsz. Egyszeruen mindegyiket egy gepes mukodesre terveztek, a replikacio vagy akar alapszintu cluster-es feature-ok csak utolag lettek belehackelve (BTW, ez az oracle-re is igaz!).

Ha tenyleg fontos a kozel linearis skalazodas, az elosztottsag, akkor nezd meg a hadoop/hbase-t. Nem SQL ugyan, de nem is feltetlen baj. Ellenben masszivan elosztott mukodesre terveztek. Ha mond valamit a bigtable szo, akkor tudod, mi ez.