ja radim za mysql tako da mozes da me smatras pristrasnim, ali koristim i pgsql i sqlite dosta tako da mogu da ti dam neki odnos za "jednostavne sajtove" .. za malo komplikovanije stvari je potrebna ozbiljnija analiza i zavisi od sistema do sistema ...

Ako ti trebaju transakcije (na mysql to znaci innodb, na pgsql je to default, na sqlite isto) u zavisnosti od mnogo toga performanse za "standardne jednostavne upite" su prilicno slicne .. (mysql je neznatno brzi). Ako imas mnogo vise DRL (data read) nego sto imas DML (data modifying) mysql je znacajno brzi ako koristis query cache. Ako imas puno update-a qcache ce samo da uspori update znacajno tako da je onda beskoristan. Ako imas kompleksne upite, mysql moze da bude "mnogo brzi" ili "mnogo sporiji" - zavisno od toga "kako te krene" zato sto ima nekih ozbiljnih problema u optimizeru koji ne uspe da nadje uvek najbrzi put za izvrsavanje upita te kompleksni join-i sa subselect-ima mogu da budu mnoooooooooooogo brzi sa pgsql-om nego sa mysql-om. sqlite je tu prilicno "lite" tako da ako ti trebaju kompleksni join-i sqlite ispada iz igre.

Ako ti ne trebaju transakcije, onda na mysql-u imas myisam koji je visestruko brzi od svega sto pgsql i sqlite mogu da ponude, prosto zato sto nemas transakcije. Limitiran si za DML time sto svaki DML lokuje celu tabelu, mada web uglavnom nema znacajan DML load (u proseku web sajt ima 80:20 odnos read write). Ono sto je problem u ovom slucaju je sto, jeli, nemas transakcije ... mysam tabele nisu crash safe i slicno ... ako na primer uradis "delete from t1" i pukne ti taj statement iz bilo kog razloga u t1 posle toga imas "nemas pojma koliko" slogova ... opet - za web, vrlo cesto nebitno, ali je vazno znati da myisam nije crash safe (zato je brz, zato sto ne brine o ACID-u). MyISAM ti dodatno omogucava da indexe za tabele koje su ti cesto potrebne preloadujes u posebno obezbedjen ram za to...

Dakle "jednostavan" odgovor ne postoji ... ako trosis myisam, pravilno konfigurisan mysql je brzi od bilo cega drugog sto danas mozes da nadjes .. sa svim svojim manama koje myisam nosi (nije ACID), ako ne trosis myisam onda tu ima mnoooooogo stvari na koje treba obratiti paznju. Generalno mogu da kazem nezvanicno da novi innodb (koji ce se pojaviti nadam se uskoro u 5.5) ima nevidjena poboljsanja u odnosu na ovo sto je sada dostupno, i da ce sam mysql dobiti dobar boost uskoro (jbg 2 godine ne radimo realno nista, samo popravljamo bagove i krpimo rupe u ljudstvu ... sada smo najzad dobili mogucnost da zaposlimo nove ljude, samo da prodje cela ova integracija sa oraklom i mislim da ce mnoooogo brzo da se vide mnooogo pozitivni pomaci vezano za mysql server)...

Ako nemas replikaciju, myisam je nesiguran ako su ti ti podaci "bitni" .. ako mozes da podneses da ti "zadnjih sat vremena insertovanih podataka ode u vetar" onda ti je myisam super :) ... acid kosta u performansama...

samo je bitno da imas u glavi da

MyISAM != MySQL

dakle mysql ti daje mogucnost da biras izmedju raznih storage engine-a (imas pored MyISAM, InnoDB i jos par manje bitnih, sada i MariaDB, XtraDB ...)
- MariaDB je "crash safe MyISAM" ... na zalost, ocajan storage engine - mnogo je spor i vrlo bagovit :( ... ono sto je dobro je sto Montijev mariadb fork mysql-a ima ODLICAN optimizer (mnogo bolji od sadasnjeg mysql-ovog), sto nije cudo posto je nas ceo optimizer tim presao kod njega u firmu :)
- XtraDB je innodb + google patches + percona patches - ODLICAN fork InnoDB-a, SVAKA PREPORUKA .. jedina "mana" je sto je samo za linux, sto iskreno ja ne vidim kao manu uopste .. trenutno mnogo bolji od zvanicne verzije innodb-a, nedovoljno testiran (mi imamo sve te patcheve + jos po nesto u 5.5 i to ne smatramo GA kvalitetom) ali generalno ODLICAN storage engine


bitno je samo da odaberes pravi storage engine .... i naravno, uvek je zgodno da uporedis performanse sa ostalim sistemima ... Na primer ako ti treba "Spatial Extensions" MySQL je tu jedno 2-20 PUTA sporiji od pgsql-a !!!

EDIT:
http://www.mysql.rs/2009/07/rethinkdb/ zadnji komentar imas spisak storage engine-a .. tu samo fali da je mariadb sad u odvojenoj firmi (monti otisao i odveo developere sa sobom koji su radili na tome) i da je perkona pokrenula innodb fork koji se zove XtraDB

Namerno nisam precizirao koji s kog engine-a sa prelazi (myisam ili innodb) jer ih koristim oba, zavisno od situacije.

Viđao sam na nekim hostinzima da pri kreiranju database mogu pored mysql (default) birati i postgresql i još neki.

Možeš li mi reći (ili pretpostaviti) koje su to situacije kod kojih bi klijent pre odabrao postgresql (ili sqlite)?

Za ostale: i dalje me interesuju tuđa iskustva s performansama.

sta bi "klijent" iskoristio... ne znam, mogu da ti kazem kada "ja" biram pgsql (sqlite je za hosting/web po meni los, ja koristim sqlite kao embeded sql server i za to je #1 open source db sistem, bolji je tu od mysql-a za 10 kopalja) ... dakle ja biram pgsql

1. kada koristim tudju aplikaciju gde developer kaze da podrzava samo pgsql ili gde kaze da aplikacija bolje radi sa pgsql-om
2. kada koristim spatial
3. kada imam komplikovane upite iz preko 10 tabela sa subselect-ima (dakle jedan upit kada je join iz preko 10 tabela)
4. kada portujem aplikaciju sa orakla (pgsql je mnogo slicniji oraklu i mnoooogo je jednostavnije portovati aplikaciju sa orakla na pgsql nego sa orakla na mysql)
5. kada mi treba bolji auditing (od kada sam napisao skript za auditing na mysql-u ovde vise ne koristim pgdsql)
6. kada mi treba bolji auth control nego na mysql-u (mysql grant sistem je na zalost prilicno patetican ... WL za "pluggable auth sistem" postoji, al kad ce biti gotov ..)

Sve ovo sam ovako radio i mnogo pre nego sam se zaposlio u mysql-u :) tako da nisam ni malo promenio misljenje time sto sam se zaposlio u mysql-u (cudno ali, zaposlenjem u mysql-u sam samo nasao mnooogo vise razloga gde mysql ne valja, i saznao mnogo vise stvari koje mysql radi lose ... to iznutra sve izgleda uvek mnogo losije nego spolja :D )

sve u svemu tacka 3 je mnoogo bitna .. tu je pgsql jos uvek 2 koplja ispred mysql-a

p.s. ima dosta klijenata koji su pobegli sa mysql-a zato sto
- ne znaju da mysql != myisam a trebale su im transakcije, crash safe tabele, row locking ...
- uplasili su se sto je SUN kupio mysql (da ce da postane komercijalan ... to su perkona i monti iskoristili da naprave svoje forkove)
- uplasili su se sto je oracle kupio mysql (da ce da se desi ko zna sta, ja sam unutra pa ne znam sta ce se desiti tako da kapiram strah za ulaganje u "nepoznatu buducnost")

za ove prve, sta reci .. za ove druge i trece, mislim da su perkona i monti dovoljno jaki da orakle ne moze nista lose da uradi mysql-u tako da je strah neopravdan ...

Koristio sam sve pomenute baze, ali jednostavan zakljucak nemam.

SQLite obicno koristim za jednostavne aplikacije, manji broj tabela, manji broj slogova. Nekako sam 'ubedjen' da malim sajtovima (uradjeni u cms-u ali imaju promenu jedanpu godisnje) SQLite predstavlja logican izbor. Brojac poseta koji sam napravio koristi sqlite iz razloga sto je to bio lite server - brzi odgovor uz minimalno zauzece memorije. Uz to, neverovatno je portabilan.

Mysql moze lepo da se optimizuje i da ima odlicne performanse. Obicno ga koristim sa kesiranjem upita i izlaza. O njemu je Bogdan rekao dovoljno.

Postgres koristim odavno, jos iz vremena kada mi je vracao netacne upite (ko zna zbog cega, mozda sam i ja gresio). Zahteva striktnu sintaksu ( ne mozes int upisati kao '1' vec kao 1, slicno vazi i za bool i ostale...). Uglavnom ga koristim kada klijenti to traze.

Nemam iskustva sa direktnim poredjenjem mysql-a i postgresa po pitanju performansi.

mali off-topic



to generalno "ne mozes" nigde ... mysql '1' za int polje vidi kao implicitni kast tako da radi toInt('1') i automatski za to polje ne koristi index posto ne mozes da indexiras rezultat funkcije te je '1' za int greska i na mysql-u ..



sto se tice performansi ... mislim da je DRUPAL (odlican CMS sistem) dobar za benchmark nekih opstih stvari ...

http://2bits.com/articles/benc...rformance-using-drupal-5x.html

nisam citao uopste rezultate (sad cu bas da procitam) .. vidim da nije ni svez mysql ni svez pgsql ali kapiram da su radili koristan test pa verujem da ce ti znaciti sta su napisali

EDIT: procitah :( poredili su MyISAM sa pgsql-om .. nije fer poredjenje, nisu poredili innodb, samo su pokazali ociglednu stvar (da je engine bez ACID-a brzi od engine-a sa ACID-om)
imas isto http://tweakers.net/reviews/64...1-vs-amd-opteron-pagina-7.html ali opet sada tu koriste stari mysql (u 5.1 i 5.5 je sredjen problem sa scalingom ako se koristi innodb plugin)

Savetujem ti takodje da pitas isto na pgsql forumu, siguran sam da ce da dobijes mnogo vise odgovora :)

_{[Ovu poruku je menjao bogdan.kecman dana 07.05.2010. u 00:09 GMT+1]}

Na FB-u ima dosta dobra grupa MySQL@FB ili tako nekako... Uglavnom puno korisnih testova i dokumentacije...

Nego zaboravili ste replikaciju koju Postgre dobija tek u verziji 9 (još u beti koliko sam upućen) ili u starijim verzijama preko nekih patcheva...

ne treba od ovoga praviti sad amiga vs pc .... coveka zanimaju realno performanse "za jednostavne upite" ... ako krenemo da navodimo koji sta kako radi odosmo u advocacy

Tačno.

Ovo sa testom Drupala je moglo biti konačan odgovor da je izmereno za innodb.

Ovde sam našao nešto zanimljivo:
http://www.randombugs.com/linux/mysql-postgresql-benchmarks.html
http://www.ebrueggeman.com/blog/php-mysql-performance/

sto ne napravis test sam ... instaliras drupal, mysql i pgsql :) ....

mene zanima kako ce da se ponasa, napravicu ja ujutro test pa cu da bacim rezultate :)

evo ga .. drupal 6.14 + pgsql 8.3.8-2

1 thread:



5 threadova


20


sad ce odma isto to i za mysql sa innodb-om (necu myisam ni da poredim)

evo ga mysql (na zalost drupal nema foru da prebaci sadrzaj u drugu bazu pa sam za mysql kreirao nove strane ... isti djavo samo su strane u mysql-u nesto sitno vece (oko kilobajt))

1 MyISAM (kreten pravi tabele kao MyISAM tek sam sad skonto, sad cu da ih prebacim u InnoDB)


20 (myisam)






INNODB
1


5 InnoDB


20 InnoDB


toliko od mene .... obrati paznju da je MySQL sa default configom, sa ugasenim query cache-om (posto ne znam kako se nesto slicno pali na pgsql-u pa reko da budu ravnopravni) ... ja mogu sigurno da ubrzam mysql za ovo min 20% a najverovatnije jedno 60% u odnosu na ove rezultate ... pgsql verovatno isto moze dodatno da se optimizuje ... al ovo su dakle i za jedan i za drugi neke default vrednosti (osim sto je mysql-u ugasen query cache koji ne bi napravio test validnim posto bi mysql iskesirao sve rezultate i nista ne bi ni pitao tabele)

btw, ta test masina je neki stari E6850 na 3ghz i 8G rama sa mnogo nekih wd black sata diskova u raznim konfiguracijama ... (i mysql i pgsql su drzali datu na 4x1T wd black u raid0 a sve to formatirano xfs-om dok je php drupalov na 2x1T wd black u raid1 konfiguraciji pa to formatirano kao xfs) sa fedorom 10 ...

upravo gledam ove rezultate (malopre sam samo copy paste) .... innodb je za ovaj odnos upita (prva strana ima 20tak read upita i 1 write ako sam ja dobro video) isto brz koliko i myisam, deluje mi da je ovde sporiji php nego baza ...

ne znam koliko je validan test .. ali realno drupal da bi prikazao ovu naslovnu stranu napravi dosta upita (mnogo vise nego sto bi ja to napravio da sam ga ja radio)... puni neku log tabelu (dakle ima i insert) .. radi i neke update ... sve u svemu .. "komunicira sa bazom" ... bilo bi lepo kada bi neko napravi oneki malo ozbiljniji test ... tipa sa nekim cms sistemom koji je "pun" (a ne koji ima 5 strana kao ovaj test koji sam ja sad pravio) pa da pusti neki benchmark nad celim sajtom (ne samo nad jednom stranom) ... no, od mene dosta :D ... koga zanima, moze da potrosi vreme na benchmark :) a ja cu mu biti zahvalan ako rezultate podeli sa nama ostalima :)

Šta da kažem,
Bogdane KRALJU.

Hvala na vremenu i trudu za ovo.
Sam se verovatno ne bih upustio u testiranje jer pgsql ne poznajem dovoljno, pitanje je dali bih ga i instalirao kako treba.

Detaljniji test od ovoga mi ne treba. Temu sam i započeo da bih saznao kako se ponaša ozbiljniji portal na drugim bazama, a drupal je za mene sasvim dovoljno ozbiljan.

Mislim da Drupal nije neko merilo za brzinu, posto je isti pravljen za MySQL inicijalno, sto znaci da su upiti optimizovani za MySQL a podrska za PostgreSQL je dodana naknadno. Takode po meni ne bi trebalo nikako da se uzima MyISAM jer to i nije prava transakciona baza. Znaci u obzir bi dolazilo poredenje InnoDB vs. PostgreSQL.

Evo nekih linkova, jest da su malo stari, ali :
LINK 1 i LINK 2

Neko ce reci da to nije MySQL 5.1 ali nije ni PostgreSQL 8.3, koji je doneo 20% brizne u odnosu na PostgreSQL 8.2. Takode tu je i 8.4 koji je opet doneo dodatna ubrzanja u odnosu na 8.3.

Dalje treba uzeti u obzir sta treba ta baza da radi. Ako poredimo proceduralne jezike, po meni, PgPlSql je daleko mocniji od MySQL-ovog proceduralnog jezika.

Toliko od mene

pgsql takođe ima mogućnost da se koriste funkcije pisane u C-u koje su još brže za izvršavanje.
http://www.postgresql.org/docs/8.4/static/xfunc-c.html
nisam siguran da li tako nešto mysql ima.

ono što meni smeta kod postgresqla jeste sistem privilegija, koji mi malo djeluje kao overkill i x puta mi je digao pritisak jer nije radio onako kako je trebalo da radi. prvenstveno mislim na pg_hba.conf

miroslav, i mene zanimalo sta ce da se desi

michaelk, ako pogledas bolje, zadnja 3 testa su sa INNODB-om, ne sa myisam-om (kada sam pustio vec test provalio sam da sam zaboravio da prebacim tabele u innodb pa sam pustio rezultat cisto neka ga kad ga vec ima) ... sve tabele su prebacene u innodb, za to da je bolje optimizovan za mysql, ne znam sta bi reko, prilicno su isti upiti za prvu stranu ... generalno, test "nije neki", ali ima na netu bar 1000 strana mysql vs pgsql da cita ko god oce danima :D

sto se linkova za skaliranje tice ... pgsql se skalira MNOOOOOOOOOOOOOOGO bolje od 5.0 i 5.1 .. to niko ne spori .. ako pogledas gore ja sam iste linkove postovao .. 5.5 se skalira "skoro ko pgsql" ali mislim da je i tu i dalje pgsql bolji ... no na 4 jezgra masini to i nije bas znacajno ..

tyler, mozes da pises funkcije u c-u i na mysql-u :) .. ali mislim da to bas i nije deo koji zanima coveka koji je postavio pitanje .. sto se tice tog overkila sa privilegijama, mysql ima PATETICAN auth sistem i to mu je ogromna mana i jedna od stvari na koju mnoooogo klijenata (sto ovih za pare, sto onih free) kuka. Nadam se da ce pluggable auth biti uskoro (sa podrskom za active directory, ldap, radius...) ... e sad, sto se tice pg_hba.conf moje resenje za to je webmin :D

bogdan.kecman,

posto mi se cini da imas ponajvise iskustva

zanima me koliko "slozenu i obimnu bazu" SQLite moze da posjeduje


ne mogu nigdje da nadjem neko poredjenje...
features su mi ok, ne trebaju mi ni transakcije niti neke slozenije opcije osim samo pohrane podataka

ali me zanima znaci do koje velicine i slozenosti baze je SQLite prihvatljiva opcija za desktop poslovnu aplikaciju

ako mozes kroz neki "primjer" po svom iskustvu??

hvala velika

iskreno - NEMAM POJMA

po mom iskustvu - ja sam sqlite koristio samo i iskljucivo za cuvanje configa aplikacije. Dakle par stotina parametara u 2-3 tabele i to je to, jednostavan PK read/write.

Imam gomilu klijenata koji koriste sqlite i koji ga koriste za isto to - dakle za cuvanje kojekakvih parametara. Nikad nisam video aplikaciju koja koristi sqlite kao "ozbiljnu bazu podataka" .. Mozes reci da "nisam imao gde to da vidim" posto radim za MySQL ali, moji klijenti koriste i pgsql i firebird i mssql i oracle i db2 i svasta jos .. za razne stvari i u raznim kombinacijama .. i kao sto rekoh - sqlite korise isto kao i ja sto ga koristim - ako ima vise od 10 parametara u config-u, embedujes sqlite u aplikaciju i cuvas config u njemu.

Slobodno postavi ovo pitanje na "nadforumu" gde imas mnogo vise korisnika sqlite-a, mozda ti neko da primer gde se sqlite koristi za nesto vise / za neku vecu bazu koja radi sa sqlite-om. Ovde su primarno mysql korisnici koji generalno nemaju veliku korist od sqlite-a.

ok, hvala velika...