A tárolt eljárásaimat kénytelen voltam java oldalon megoldani, mivel a MySQL 5-ben annyira várt tárolt eljárásokkal nem tudtam megvalósítani, azt amire szükségem lett volna (nem ad vissza resultsetet).
A sebessége viszont még mindig nem nyűgözött le így kipróbáltam a like '%valami%' és a match stílusú fulltext indexeket is, de ez sem nyert. Állítgattam a keybuffer sizet, ez már jobb eredményt adott. Jobb lett mint a postgresql!
A szerver loadja leesett 1,5-ről 0,7-1-re!
Közben kiderült még néhány turpisság a mysql körül.
Volt egy napi statisztika készítő scriptem, amely 7 millió sort dolgozott fel naponta. Ezen viszont a mysql 5 és 4 is elhasalt out-of memory jellegű hibával. Ezt nem sikerült kikerülni :-(
Vissza postgresql-hez.
Itt is találtam egy hibát ami miatt a statisztikát hibássan készítette el. Egyes varchar-os mezők duplikáltan jelentek meg a statisztikában a 'group by' ellenére.
Irány a postgresl-bug-report lista.
Itt kiderült, hogy a magyar karakterkészlettel van neki is gondja. Ezt a hibát a 8.0.6-os verzióban és a 8.1.2-ben javították.
Upgrade 8.1.2-re
Közben a karakterkészletek keresgélésénél megtaláltam, hogy a Postgresql a default collate-től eltérő varcharos mezőknél nem használja a keresésénél az indexeket csak ha pl. így készítem el:
CREATE INDEX name ON table (colum text_pattern_ops vagy varchar_pattern_ops);
Valamint a postgresql conf-ot is sikerült tuningolnom:
shared_buffers(8KB each)
16000 (~128 MByte)
effective_cache_size
free * 0,8
random_page_cost
2
fsync
=off - mert van szünetmentes tápegység
Így viszont a postgresql loadja esett le 0,15-0,3 közé! :-)
Nálam a postgresql nyert :-)
Így utólag a mysql-es tesztek amik alapján felbuzdultam egy kicsit hibásnak tüntek. Bár végül is ez a próbálkozás vezetett a PostgreSQL normális belövéséhez.
- yoursoft blogja
- A hozzászóláshoz be kell jelentkezni
- 1247 megtekintés
Hozzászólások
Még találtam egy dolgot ami gyorsíthatja a Postgres alatt a lekérdezéseimet:
CLUSTER indexname ON tablename parancsot.
Ez fizikailag is sorbarendezi a tábla sorait amíg nem változik a táblatartalom.
Ez nekem tökéletes, mivel az egyik szerveren max. havonta, a másikon meg naponta változnak a táblatartalmak.
És egy dolgot még elfelejtettem: vacuumdb -f -z. Ezt is naponta futtatom, mivel ez meg a táblákat 'defragmentálja'.
- A hozzászóláshoz be kell jelentkezni
univerzalis eszkoz nincs. vannak szarok, jok. de a jok kozott a konkret problema valasztja ki az arra legalkalmasabbat.;)
ha van idod, akkor jatszogassal havonta/kethavonta egy ilyet, mint most. tuti gyorsabb lesz, az meg hogy melyiket hasznalod mind1.;)
hianyoltam viszont a query plan-ok nezegeteset, hogy azonos-e mindket esetben. na ott lehet meg sokat gyorsitani a dolgon.
Anr - http://andrej.initon.hu
- A hozzászóláshoz be kell jelentkezni
A query planok ugyanazok voltak, ezért indexelgettem őket. :-)
Sőt az volt a furcsa, hogy localban amikor próbálgattam, kb. 50 ms-el a mysql volt jobb. Ha ugyanazt a lekérdezést többször futtattam, akkor is a mysql volt a jobb, gondolom a query cache miatt. Amint viszont konkurens felhasználók véletlenszerű adatokkal futtatták a lekérdezéseket a mysql rosszabb lett, mint ez a szerver loadból is látszik.
Valamint a 7 millió soros táblán képtelen volt a végrehajtani a lekérdezéseimet a mysql. Végül is ez döntött.
Természetesen igazad van, ha optimálisan akarok valamit megírni, több dolgon is ki kell próbálni. Más esetben lehet, hogy a mysql lett volna a jobb.
- A hozzászóláshoz be kell jelentkezni
Ezért van az, hogy biztosról ne állj át neked ismeretlenre.
MySQL-ben 5.0nál jöttek be a storedprocik, hát nem tudnak annyit mint máshol. A delete from-os példába meg a WHERE-nek adhatnál mezőnevet, hogy mégis melyik mező alapján szűrjön:D
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Ok, itt a delete-nél az volt a lényeg, hogy ugyanarra a táblára mint amiből törölsz mysql alatt nem hivatkozhatsz egy alselectben.
- A hozzászóláshoz be kell jelentkezni
Oracle alatt sem megy (bár ott az update/insert volt).
- A hozzászóláshoz be kell jelentkezni