Komplex rendszer, párhuzamosítás
Sziasztok!
Adott egy rendszer, amelynek a lényege, hogy tartalmakat keresünk különböző kereső feltételek mellett, amelyeket a felhasználók definiálnak. Egy felhasználó több keresési feltételt definiálhat.
Egy keresési definiíció a következő képp nézhet ki:
- Korlátlan számú kulcsszó/kifejezés
- Korlátlan számú kód (csak számok)
A kódok és a kulcsszavak közti kapcsolat lehet AND vagy OR (nem egyesével, hanem mint halmazok között, a halmazon belül OR kapcsolat van). A keresésnél be lehet állítani, hogy teljes egyezés számít, vagy tartalmazás is.
Az adatbázis mysql, és a mezők amelyekben keresünk LONGTEXT típusúak. Naponta minimum 1000, maximum 5000 új sor szokott lenni, amelyet "match"-elni kell.
A jelenlegi rendszer működése:
Első user: veszi a keresédi definícióit és végig iterál rajtuk a következő módon:
1. lépés Veszi a tartalmakat, amelyek mezőit split-eli először whitespace-ként, majd végigmegy contains/equals -al a kódokon és kulcsszavakon (tartalomban található szavak szám szorozva a kulcsszavak plusz a kódok számával). Az első találat esetén true-val visszatér (Persze ha AND kapcsolat van beállítva, akkor külön a kódon és külön a kulcsszavakon).
2. lépés a tartalmat fel split-eli írásjelek szerint, majd az előző lépéshez hasonló módon ismét végig megy rajtuk. (A kifejezések miatt...)
3. lépés veszi a következő keresési definiíciót majd ugyan ezt végrehajta az adatbázisnak ezen a során.
Ezt minden egyes sorra megcsinálja, majd meg a következő user-ra.
A kinyert tartalmakat 100-asával perzisztálja egy külön táblába.
Maga a folyamat még kevés adattal és kevés felhasználóval működött, viszont most már használhatatlan, és nincs az a futásidő és memória mennyiség ami elég lenne az alkalmazásnak. (A rendszert átvettem, nem én írtam).
A kérdésem az lenne, hogy milyen módon lehetne ezt a rendszert optimalizálni, esetleg párhuzamosítani.
Java regex-el az egyez adatbázis mezőkre eseleg.
(Indexelő alkalmazás egyelőre nem játszik sajnos, gondolok itt: elasticsearch, lucene index. Gyors megoldás kell, amíg elkészül a teljesen új rendszer, mert ezzel nem érdemes hosszútávon foglalkozni.)
Előre is köszönöm!
■ Adott egy rendszer, amelynek a lényege, hogy tartalmakat keresünk különböző kereső feltételek mellett, amelyeket a felhasználók definiálnak. Egy felhasználó több keresési feltételt definiálhat.
Egy keresési definiíció a következő képp nézhet ki:
- Korlátlan számú kulcsszó/kifejezés
- Korlátlan számú kód (csak számok)
A kódok és a kulcsszavak közti kapcsolat lehet AND vagy OR (nem egyesével, hanem mint halmazok között, a halmazon belül OR kapcsolat van). A keresésnél be lehet állítani, hogy teljes egyezés számít, vagy tartalmazás is.
Az adatbázis mysql, és a mezők amelyekben keresünk LONGTEXT típusúak. Naponta minimum 1000, maximum 5000 új sor szokott lenni, amelyet "match"-elni kell.
A jelenlegi rendszer működése:
Első user: veszi a keresédi definícióit és végig iterál rajtuk a következő módon:
1. lépés Veszi a tartalmakat, amelyek mezőit split-eli először whitespace-ként, majd végigmegy contains/equals -al a kódokon és kulcsszavakon (tartalomban található szavak szám szorozva a kulcsszavak plusz a kódok számával). Az első találat esetén true-val visszatér (Persze ha AND kapcsolat van beállítva, akkor külön a kódon és külön a kulcsszavakon).
2. lépés a tartalmat fel split-eli írásjelek szerint, majd az előző lépéshez hasonló módon ismét végig megy rajtuk. (A kifejezések miatt...)
3. lépés veszi a következő keresési definiíciót majd ugyan ezt végrehajta az adatbázisnak ezen a során.
Ezt minden egyes sorra megcsinálja, majd meg a következő user-ra.
A kinyert tartalmakat 100-asával perzisztálja egy külön táblába.
Maga a folyamat még kevés adattal és kevés felhasználóval működött, viszont most már használhatatlan, és nincs az a futásidő és memória mennyiség ami elég lenne az alkalmazásnak. (A rendszert átvettem, nem én írtam).
A kérdésem az lenne, hogy milyen módon lehetne ezt a rendszert optimalizálni, esetleg párhuzamosítani.
Java regex-el az egyez adatbázis mezőkre eseleg.
(Indexelő alkalmazás egyelőre nem játszik sajnos, gondolok itt: elasticsearch, lucene index. Gyors megoldás kell, amíg elkészül a teljesen új rendszer, mert ezzel nem érdemes hosszútávon foglalkozni.)
Előre is köszönöm!
Solr
Solr / Lucene
"Indexelő alkalmazás egyelőre
A Solr-t kifelejtettem a listából, de egyelőre az sajnos nem játszik.
A bajt az jelenti, hogy rengeteg az egymásba ágyazott ciklus.
Hibernate search-ről valaki
http://www.hibernate.org/subprojects/search.html
Az a hibernate corera épül,
A baj az, hogy a rendszer jelenleg fordítva ül a lovon (ha jól értem, akkor userenként feldarabol mindent újra). Így vagy te átírod az egészet, vagy integrálsz egy kereső cuccot. Én az utóbbit tenném, ez lényegesen egyszerűbb. Bedobálhattok plusz vasat is (ha a kód erre fel van készítve), de az ilyen problémákra nem ésszerű válasz, mert max időt nyersz vele. Ráadásul az integrációhoz képest drágább és bonyolultabb is.
Java-ról beszélünk, és
tomcat-ra nincs lehetőség jelen keretek között (és szükségünk sincs rá, a fentebb lévők szerint.)
Új vas sem játszik, jelenleg is egy vps áll a rendelkezésünkre és egy lokális szerver (ami itt van az irodába és mentésre szolgál)
Akkor szerintem "csak" át
Igen, tudom, azért lenne ez a
A JMS architektúrát a
A több vas lehetősége, és a terhelés kordában tartása miatt. Ha azt mondod, hogy 8 szálon pollozod a queue-t, akkor 8 szál fog tekerni, és nem rogy be a szerver akkor sem, ha valamiért bevágsz hirtelen 1000 sort a db-be, amit le kéne indexelni. A több vasat viszont nem tudom, ahhoz Hibernate searchnek tudnia kéne több mastert, amit nem említ a doksija, vagy csak én nem jutottam el odáig. A slave-ek már csak a keresésnél játszanak (esetedben a user tartalom összerendelésnél), de ott már biztos tudsz terhelést elosztani több vas között akár JMS-sel, akár mással. És gondolom jelenleg ez a nagyobb erőforrásigény, nem a tartalmak indexelése.
text -> integer
az adott kulcsszóhoz tartozó azonosító(k) gyorsan megkaphatók, és az ezekhez tartozó cikkek is.
tulajdonképpen ha úgy tetszik tag-elte az összes előforduló szóval.
Ez úgy hangzik mint az
ezzel az a baj, hogy
azért gondolom egy kisebb