Magamról

Saját fotó
Főiskolai, majd egyetemi diplomamunkáimtól kezdve világ életemben, adatok, adatbázisok, adattárházak (leginkább Oracle) környékén mozogtam. Mostanság adattárházasként, adatbányászként élem napjaimat.

2010. június 22., kedd

Collective Intelligence in Action

Ha már egy szakmai levlista, aktuális threadjének apropóján megemlítettem, akkor ide is beszúrom a (be)futó gondolataimat; gyarlón áldozva a redundancia oltáránál. :)

Milyen megoldást lenne a legcélszerübb használni csak szöveges adatbázisok esetén?

Az egyik probléma a méret, egyrészt milliárdos rekordméretek lehetnek, másrészt ez nagy tárhelyet is igényel. Ez utóbbira azonnali ellenérv, hogy tömöritve kerülnek tárolásra, de nem láttam erröl statisztikát vagy tapasztalati beszámolót, hogy milyen mértékben csökkenti a tárolási kapacitást.

A másik probléma az indexelés, mert értelemszerüen ABC sorba rendezett rekordokról van szó. Ugyanakkor valódi indexelésre van szükség, a "teljes szöveges keresés" és a mesterségesen 255 bájtokra darabolt szöveg indexelése nem jó, szavakra, söt kifejezésekre kell indexelni.

További jellemzö az, hogy ritkán, de akkor nagy tömegben kerül sor adatok bevitelére, majd esetenként újabb mezökre, oszlopokra lehet szükség az újabb definiciók, tartalmi meghatározások érdekében.

Tudom, ezek nem azok a szempontok, amelyek a "hagyományos" adatbáziskezelök esetében felmerülnek, ezért kérdezek ezen a listán.

Az első gondolat a szakirodalomé, pláne, hogy létezik magyar nyelven, elérhető, és korszerű könyv a témában:
Szövegbányászat

milyen mértékben csökkenti a tárolási kapacitást.

Szövege, meg nyelvezete válogatja (így nehéz egyetlen adatot mondani), magam részéről láttam már 90%-os taposású 10%-ra (ráadásul meglehetősen gyorsan) összenyomott TXT-t, de símán lehet ez az összenyomás 30-50% is csak. Azonban tisztán kell látni, hogy két (részben antagonisztikus) dolog mentén kell optimalizálni a gyártóknak/fejlesztőknek (erőforrásminimalizálás, elérésihatékonyság-maximalizálás)

a "hagyományos" adatbáziskezelök

Én azt gondolom, hogy az Oracle, iparági standard a témában (és hozzá eléggé elterjedt itthon is), ami a táblatér-tömörítéstől meg speciális feladatot jól támogató filerendszerektől, a magyar ékezethelyes rendezésen át, az SVM-es szövegbányászatig mindent lefed, jó minőségben. Két probléma lehet vele: (1) ár, azaz köznapian szólva megéri-e, (2) szövegeknél fontos magyar nyelvi specifikumokkal kapcsolatos gondok (pl.: Oracle*Text).

Az nem kérdés, hogy akár Oracle, akár nem, mind a strukturált rész, mind a nem strukturált rész tervezése külön tervezést igényel, a közös részek figyelembevételével. Alapvető fontosságú, hogy kettő "balansza" hogyan alakul, szélső esetekben, nem strukturáltakból kell kvázi 100%-ban strukturáltat előállítani avagy 100%-ban nemstrukturált adatokról van szó a projektben. De persze mixed modell is bőven lehetséges.

sufni-tuning lehetőség

Nyílván egy államigazgatásban, bankban, biztosítóban, stb. nem jön szóba házi barkácsolás, de adott esetben létezik költségkímélő (konkrétan nulla forintos) oprendszer szintű szolgáltatás okos felhasználása; compressed file/folder/partition például a Windowsokban. Érdemes lehet tesztként egy teljes Oracle HTML-formájú help-et (nagyon jó teszt-referencia egyébiránt is, szvsz) compressed és uncompressed folderben megnézni tárfoglalásilag. Meglepően jó a tömörítési hatékonyság, miközben performancia szempontból kvázi teljesen transzparens a tömörítés. Mondjuk milliárdos rekordszámnál (brute force esetben) egy NTFS szerintem kezét feltéve megadja magát. ;)

magyar nyelv nehézsége

Az én tudtommal a legteljesebbkörű készen meglévő _magyar_ megoldás az a kereskedelmi Clementine Text Mining /1 db - amúgy a feladathoz akár elégséges - licence kb. 5 milla + ÁFA, de szívesen veszek bármilyen infómódosítást, pláne árcsökkenést :o))/. Angol nyelvterületen ráadásul van open source lehetőség is (Knime, RapidMiner)-kiegészítő modulok. Amiket persze lehet 'magyarítani' közösségi felhasználásra. ;)

Zárógondolat: projekt költségvetés tervezésekor érdemes pontosan felmérni, hogy milyen készen vásárolt eszközök mennyibe kerülnek pontosan és a bennük lévő fukciók alternatív házilagos lefejlesztése mennyibe kerül, és ekkor milyen előnyekkel meg hátrányokkal lehet számolni. Ez távolról sem lefutott pálya, szvsz, ahol könnyedén lehet ökölszabályokat mondani. Azaz a két véglet (open source/free funkcionalitások integrációja valamint teljes vertikumú kereskedelmi termék vásárlása) között többféle lehetőség van.

Kiegészítés:

Az imént futottam bele, az alábbi ígéretesnek tűnő, friss kiadásúnak mondható, 400+ oldalas, angol nyelvű könyvbe, ami egy informatikusnak különösen szimpatikus szakkönyvkiadó, közismert remek sorozatának darabja, némileg azért (számomra) meglepő módon. Szemet gyönyörködtető számomra, ahogy összeérnek a világban egyes - itt most külön nem részletezett - történések. ;)

Manning: Collective Intelligence in Action



WHAT'S INSIDE:

* Architecture for embedding intelligence in your application
* Developing metadata about the user and content
* Gather intelligence from tagging and build tag clouds
* Introduction to intelligent web crawling and Nutch
* Harvesting information from the blogosphere
* Build a text analysis toolkit leveraging Lucene
* Business intelligence and data mining for recommendations and promotions
* Leveraging open-source data mining toolkit WEKA and the Java Data Mining (JDM) standard
* Incorporating intelligent search in your application
* Building a recommendation engine—finding related users and content
* Real-world case studies of Amazon, Google News, and Netflix personalization.

Nincsenek megjegyzések:

Megjegyzés küldése