[BSD] Spam filter gyorsan és hatékonyan

[Laszlo Nagy]

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