lassuk<br><br>lix@test:teszt$wget -O - <a href="http://downloads.sourceforge.net/sourceforge/sqlgrey/sqlgrey-1.7.6.tar.bz2">http://downloads.sourceforge.net/sourceforge/sqlgrey/sqlgrey-1.7.6.tar.bz2</a> | bunzip2 | tar xfv -<br>
lix@test:teszt$grep -ir select . |less<br><br>./sqlgrey-1.7.6/sqlgrey: 'SELECT sender_name, sender_domain, src, last_seen, last_seen ' .<br>./sqlgrey-1.7.6/sqlgrey: 'SELECT sender_name, sender_domain, host_ip, last_seen, last_seen ' .<br>
./sqlgrey-1.7.6/sqlgrey: 'SELECT sender_domain, host_ip, last_seen, last_seen ' .<br><br><br>hat igen ahogy sejteni lehetett<br><br>>Az agyatlan SQL lekérdezések okozhatnak gondot, de nem hiszem, hogy egy<br>
>ilyen publikus megoldást ne nézne át pár SQL-hez értő ember is és ne<br>
>javítaná ki, ha gond lenne vele.<br><br>Ezt mire alapozod megis? SQLhez erto ember az ki tud perlben sql selectet irni? <br><br>Kis meretben ez az egesz sqlquery dolog nem fogja lassitani a szervered erezheto mertekben de en nem nagyon engednem ra mission critical mail szerverre ;)<br>
<br><br><br><div class="gmail_quote">2009/7/21 Laszlo Nagy <span dir="ltr"><<a href="mailto:gandalf@shopzeus.com">gandalf@shopzeus.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Molnár Roland wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
István írta:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
jah foleg ha az adat tabla amibol kverizel nagyobb mint a memoria<br>
ahova kesselhetnel<br>
<br>
bele se merek nezni milyen kverik futhatnak mert ha full table scanek<br>
akkor inkabb haggyuk is ezt<br>
<br>
</blockquote>
Még mindig nem értem a problémád.<br>
Ha valaki SQL alapra helyezi bármely dolgát, előtte ép ésszel felméri mi<br>
kell hozzá és olyan vasra rakja. Abban igazad lehed, hogy sufni sql<br>
szerverek valóban tudnak lassúak is lenni, de a cache-ben tárolt adatok,<br>
akkor is ott vannak és van még egy plusz cache mechanizmusod a kernel<br>
filecache-elése fölött, így szerintem még mindig inkább nyersz vele.<br>
Az agyatlan SQL lekérdezések okozhatnak gondot, de nem hiszem, hogy egy<br>
ilyen publikus megoldást ne nézne át pár SQL-hez értő ember is és ne<br>
javítaná ki, ha gond lenne vele.<br>
<br>
Van tapasztalatod már az SQLGrey-jel, vagy csak az SQL irányában van<br>
ellenérzésed?<br>
</blockquote>
<br>
Na csak hogy én is beszóljak. :-) A gép amin ez megy egy kétprocis nyolcmagos Xeon, 24 giga memóriával és tisztességes RAID-del (2GB write back cache, BBU, 8 vinyó RAID 6 ban stb.) Ennek ellenére nem preferálom az SQL-ben tárolást. Programozói szempontból nagyon kényelmes a használata. De van amikor bazi lassú tud lenni. Mondjuk lehet hogy ez a gép elbírná, de nem terhelem szívesen.<br>
<br>
Élő példa: van egy táblánk amiben 4 millió sor van és van kb. 100 oszlopa. Egy sor mérete általában több kilobyte. Név szerinti keresés SQL-ből nem megy jól a következők miatt:<br>
<br>
- seq scan nyilván rossz, minek végignyalni az egész táblát ha csak néhány (kis) mezőben keresünk<br>
- index scan csak akkor jó ha pont azokban a mezőkben keresünk amikre az index van. De változatosak a keresések és nem hozhatok létre sok nagy indexet, mert akkor meg az update-ek lesznek lassúak (meg egyébként is kis/nagybetű érzékenység meg egyéb problémák miatt szinte sose használna index scan-t)<br>
- tsearch2 jó lenne, kivéve hogy kipróbáltuk és a tsearch2 index file mérete olyan bazi nagy lett hogy szintén lassú, valamint mivel bazi nagy az index file ezért a tábla update-elése lehetetlenül lelassult -> ötlet eldobva<br>
<br>
Helyette az van, hogy szöveges állományba exportálunk ki olyan rész adatbázisokat, amik csak bizonyos kategórián belül tartalmaznak néhány adatot, megfelelő módon konvertálva (kisbetűs, csak azok az oszlopok amiket keresünk stb.) és C-ben van írva hozzá egy program ami adott kategórián belül az adott file-t beolvassa EGYSZER és csinál egy kimenetet. Igaz hogy nem "live" keresés, mert közben az eredeti adatbázis változhat, de erre szerencsére nincs is szükségünk. Viszont marha gyors: lemezről szekvenciális read egy kisebb állományra, és mellé egy kis processzorigényű számítás. Szinte semmi memóriát nem eszik, és akkor is gyors ha a beolvasandó file nincs a cache-ben (read buffer size átállítva 2MB-ra, nincs is szükség cache-re...) Ha valaki odáig vetemedik hogy az összes 4 millió termékben akar keresni néhány kulcsszóra, akkor is végez 2-3 sec alatt ami azért nem semmi. :-)<br>
<br>
Ebből is látszik, hogy vannak dolgok amire az SQL az ágyúval verébre. Meg persze vannak olyan helyzetek is amikor nem lehet elkerülni, ha group by-os subselect-es bonyolult lekérdezést kellene from-the-scratch írnom akkor belehalnék. :-)<br>
<br>
Igaz hogy nem próbáltam az sqlgrey-t de a probléma jellege (miszerint csak egyetlen adattábla van és abban is csak 3 oszlop) azt sugallja hogy SQL használata fölösleges overhead. Hmm ha esetleg az sqlgrey-nek van valami extra funckiója amire nekem nagy szükségem van, akkor meggondolnám.<br>
<br>
Üdv,<br>
<br>
Laci<br>
<br>
<br>
<br>
_______________________________________________<br>
BSD levlista<br>
<a href="mailto:BSD@hu.freebsd.org" target="_blank">BSD@hu.freebsd.org</a><br>
<a href="https://lists.hu.freebsd.org/mailman/listinfo/bsd" target="_blank">https://lists.hu.freebsd.org/mailman/listinfo/bsd</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>the sun shines for all<br>