[LUGOS-PROG] MySQL vs. Postgresql

Damir Dezeljin programing at mbss.org
Sat Nov 8 10:47:00 CET 2003


Hi.

Kor prvo bi zelel vprasati, ce kdo ve kdaj bodo zagovori IS na FRI-ju (pa
po moznosti se kak URL za navodila).


Sicer pa se nekaj komentarjev, ki bi jih bilo potrebno upostevati pri
odlocitvi katero bazo se bo uporabljalo (sam dnevno uporabljam MySQL,
PostgreSQL {oz. PostgreS} ter Firebird, sem pa ze uporabljal Oracle {sicer
bolj za ucenje kot kaj drugega}).


Pri izbiri podatkovne baze bi najprej raziskal funkcionalnost, ki jo bom
rabil in seveda kdaj jo bom rabil (npr. ce bom rabil subquery-e v
produkcijske namene cez >=6 mesecev, lahko pri odlocitvi zajames v ozji
krog tudi MySQL; enako velja za Stored procedures in views,...).

Druga skrb bi mi bila varnost podatkov. Popolnoma drzi, da je znotraj
vsake baze podkrbljeno za varnost podatkov. Vendar jaz mislim predvsem na
backup in replikacijo. Pri MySQL-u backup zelo enostavno implementiras
(flushnes baze na disk, naredis read lock ter za tem snapshot mysql
particije(particij) in releasnes lock). Pri PostgreSQL se stvar ze malo
zakomplicira a ne dosti. Vprasanje je tudi potrebe po incremental backupu
(tu bos zelo tezko shajal brez kaksnega snap-in-a za podatkovno bazo ...
lahko pa seveda backupiras samo transaction log, a preden se na tak backup
zaneses, ga vsaj N krat stestiraj).

Naslednja stvar bi bile performance glede na razpolozljiva sredstva ter
arhitekturo programske restive oz. stvari, ki bo uporabljala bazo(e).
Primer bom dal le iz MySQL-a, za druge baze pa sam pobrskaj (hehe, da
stvar le ne bo prelahka ;) ). Pri MySQL-u lahko zelo enostavno nastavis
replikacijo. Problem pri tej replikaciji je, da NI 'multi master'
replikacija. To pomeni, da bral bos lahko iz kateregakoli racunalnika
kamor bos delal replikacijo, pisat pa bos moral v master bazo, kar v
dolocenih primerih uporabe zna biti motece (ampak tudi to bo kmalu pri
MySQL-u implementirano).

Preverit se ti splaca tudi kako se dejansko podatki pisejo na disk in kaj
ti preostane v primeru, da se ti baze pokvarijo (coruptajo). Ne vem zakaj,
a zelo dosti 'expertnih administratorjev' pac napise skripto, ki pise v
doloceno bazo, jo pozene, pol pa povlece kabel za napajanje iz
racunalnika, spet bootne racunalnik in pogleda katera baza je 'prezivela'
oz. katero je najlazje popraviti. Tak nacin testiranja se mi res zdi
povrsen (da nebi se kaj vec napisal). Pac dobro si je pogledati kako se
stvari dejansko zapisujejo na disk in do kaksne mere so operacije
atomicne, ter seveda potrebno je pogledati tudi hardware (ni nujno, da ce
write na disk subsystem uspe, da so podatki ze na disku - cache?!?).

Od narave aplikacije je tudi odvisna izbira. Namrec tisto kar pise v
release note-sih 'almost transaction safe' ali pa 'transaction safe' pri
dolocenih aplikacijah lahko popolnoma spremeni izbiro baze!!!

A, da ne bom predolg, poglej tudi roadmap posameznih izdelovalcev, ter na
katerih OS-ih dela njihova baza, kaksna je razlika med OS-i,...



Pa se komentar o tistem, da bo v MySQL-u dolocena funkcionalnost
implementirana cez N let:
Pred cca. pol leta je MySQL sklenil partnersko pogodbo z SAP. To bo zelo
pospesilo razvoj dolocenih funkcionalnosti, kakor tudi pripomoglo k
stabilnosti in odpornosti njihovega produkta!!!



Zakaj sem tolikokrat omenil MySQL:
Ker sem ga najprej zacel uporabljati. Ko pa sem presel na druge baze, sem
se precej lovil z razlikami.
Primer je avtentikacija ... po mojem mnenju je v MySQL-u za to zelo dobro
poskrbljeno. Stvar je enostavna in ucinkovita. Pri PostgreSQL-u je (spet
po mojem mnenju) to implementirano na bolj 'obskuren' nacin (sicer se
vedno je zelo prilagodljiv del, a je res malo 'cuden', ce ga nisi
popolnoma nastudiral), Oracle pa sploh omenjal nebi ;)


Lp,
Dezo




More information about the lugos-prog mailing list