[BSD] Spam filter gyorsan és hatékonyan

[István]

lassuk

lix at test:teszt$wget -O -
http://downloads.sourceforge.net/sourceforge/sqlgrey/sqlgrey-1.7.6.tar.bz2 |
bunzip2 | tar xfv -
lix at test:teszt$grep -ir select . |less

./sqlgrey-1.7.6/sqlgrey:                  'SELECT sender_name,
sender_domain, src, last_seen, last_seen ' .
./sqlgrey-1.7.6/sqlgrey:                  'SELECT sender_name,
sender_domain, host_ip, last_seen, last_seen ' .
./sqlgrey-1.7.6/sqlgrey:                  'SELECT sender_domain, host_ip,
last_seen, last_seen ' .


hat igen ahogy sejteni lehetett

>Az agyatlan SQL lekérdezések okozhatnak gondot, de nem hiszem, hogy egy
>ilyen publikus megoldást ne nézne át pár SQL-hez értő ember is és ne
>javítaná ki, ha gond lenne vele.

Ezt mire alapozod megis?  SQLhez erto ember az ki tud perlben sql selectet
irni?

Kis meretben ez az egesz sqlquery dolog nem fogja lassitani a szervered
erezheto mertekben de en nem nagyon engednem ra mission critical mail
szerverre ;)



2009/7/21 Laszlo Nagy <gandalf at shopzeus.com>

> Molnár Roland wrote:
>
>> István írta:
>>
>>
>>> jah foleg ha az adat tabla amibol kverizel nagyobb mint a memoria
>>> ahova kesselhetnel
>>>
>>> bele se merek nezni milyen kverik futhatnak mert ha full table scanek
>>> akkor inkabb haggyuk is ezt
>>>
>>>
>> Még mindig nem értem a problémád.
>> Ha valaki SQL alapra helyezi bármely dolgát, előtte ép ésszel felméri mi
>> kell hozzá és olyan vasra rakja. Abban igazad lehed, hogy sufni sql
>> szerverek valóban tudnak lassúak is lenni, de a cache-ben tárolt adatok,
>> akkor is ott vannak és van még egy plusz cache mechanizmusod a kernel
>> filecache-elése fölött, így szerintem még mindig inkább nyersz vele.
>> Az agyatlan SQL lekérdezések okozhatnak gondot, de nem hiszem, hogy egy
>> ilyen publikus megoldást ne nézne át pár SQL-hez értő ember is és ne
>> javítaná ki, ha gond lenne vele.
>>
>> Van tapasztalatod már az SQLGrey-jel, vagy csak az SQL irányában van
>> ellenérzésed?
>>
>
> 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.
>
> É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:
>
> - seq scan nyilván rossz, minek végignyalni az egész táblát ha csak néhány
> (kis) mezőben keresünk
> - 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)
> - 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
>
> 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. :-)
>
> 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. :-)
>
> 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.
>
> Üdv,
>
> Laci
>
>
>
> _______________________________________________
> BSD levlista
> BSD at hu.freebsd.org
> https://lists.hu.freebsd.org/mailman/listinfo/bsd
>



-- 
the sun shines for all
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://datacast.hu/pipermail/bsd/attachments/20090721/17ca1973/attachment.html>