Adatszervezés, adatmodellezés
Sziasztok,
elakadtam, vagyis nem találtam optimális megoldást bizonyos adattárolási és lekérdezési modellre, ebben szeretnék ötleteket, tanácsokat, linkeket kérni tőletek.
Adott egy lista, aminek a változásait kell követnem és később ebből riportolnom.
Példának vegyük az oprendszer taszklistáját. Adott egy PC, ahol látni szeretném, hogy milyen szoftverek futnak, körülbelül a következőt látom:
PID; Program név; Fejléc
110; explorer.exe; "Program Manager"
1002; notepad.exe; "Névtelen - Notepad"
1005; chrome.exe; "Fórum téma beküldése · Weblabor - Iron"
Ezeket adott időközönként lekérem és eltárolom (timestamp és pc-szám is lesz a listához).
A végén egyszerű SQL lekérdezésekkel szeretném megtudni a következő dolgokat:
- adott időpontban milyen programok futottak egy pc-n
- hányszor futott a notepad (ugye PID alapján el tudom különíteni)
- mikor, hol, mennyi ideig, hány pc-n használják a notepad-ot
- PID alapján kimutatni, hogy a PC újra lett indítva (tfh. a PID-et az OS egy folyamatosan növekvő tartományból adja)
- hány dokumentumot (és ezek listáját) szerkesztettek notepadban
Megjegyzés: a konkrét feladat természetesen nem a taszklista rögzítése (ezért kérlek benneteket, ebbe az irányba ne sodródjon el fölöslegesen a szál), de teljesen analóg ezzel a példával.
Szinte biztos vagyok benne, hogy erre már van valamilyen módszertan, mert a követelmények jól megfogalmazhatók és úgy gondolom nem az én fejemből pattant ki először az ilyesfajta adattárolás és lekérdezés ötlete.
Adatmennyiség szempontjából több ezer "PC"-ről és "program"ról beszélünk, akár évekre visszamenőleg, a lekérdezéseknek gyorsnak és percrekésznek kell majd lenniük.
■ elakadtam, vagyis nem találtam optimális megoldást bizonyos adattárolási és lekérdezési modellre, ebben szeretnék ötleteket, tanácsokat, linkeket kérni tőletek.
Adott egy lista, aminek a változásait kell követnem és később ebből riportolnom.
Példának vegyük az oprendszer taszklistáját. Adott egy PC, ahol látni szeretném, hogy milyen szoftverek futnak, körülbelül a következőt látom:
PID; Program név; Fejléc
110; explorer.exe; "Program Manager"
1002; notepad.exe; "Névtelen - Notepad"
1005; chrome.exe; "Fórum téma beküldése · Weblabor - Iron"
Ezeket adott időközönként lekérem és eltárolom (timestamp és pc-szám is lesz a listához).
A végén egyszerű SQL lekérdezésekkel szeretném megtudni a következő dolgokat:
- adott időpontban milyen programok futottak egy pc-n
- hányszor futott a notepad (ugye PID alapján el tudom különíteni)
- mikor, hol, mennyi ideig, hány pc-n használják a notepad-ot
- PID alapján kimutatni, hogy a PC újra lett indítva (tfh. a PID-et az OS egy folyamatosan növekvő tartományból adja)
- hány dokumentumot (és ezek listáját) szerkesztettek notepadban
Megjegyzés: a konkrét feladat természetesen nem a taszklista rögzítése (ezért kérlek benneteket, ebbe az irányba ne sodródjon el fölöslegesen a szál), de teljesen analóg ezzel a példával.
Szinte biztos vagyok benne, hogy erre már van valamilyen módszertan, mert a követelmények jól megfogalmazhatók és úgy gondolom nem az én fejemből pattant ki először az ilyesfajta adattárolás és lekérdezés ötlete.
Adatmennyiség szempontjából több ezer "PC"-ről és "program"ról beszélünk, akár évekre visszamenőleg, a lekérdezéseknek gyorsnak és percrekésznek kell majd lenniük.
off
Tfh WTF? ;) (mit jelent?)
Process id win7 vagy 8 óta random érték, ha jól tudom. Amennyiben valaha dolgod lesz ilyesmivel, ne számíts növekvő értékre!
Tfh = Tegyük fel, hogy
Ja... én egyre angol
Akkor a másik tárgytalan.
PID
MongoDB
Következő a felépítés, hihetetlen mennyiségű input (csak insert, update nem is lesz), az eredmény oldalon legfeljebb szummák és átlagok különféle szűrésekkel.
Jelenleg csak próbálgatásoknál tartunk, de sebesség szempontjából kenterbe veri a MySql-t, az a funkcionalitás, amivel nem rendelkezik, az meg ennél a projektnél nem probléma. (tranzakció, join)
Szerintem érdemes megnézned!
Sajnos az összefüggések miatt
Lehetséges megközelítés
Az állapotváltozásokra eseménykezelők köthetők, ezek végezhetik a statok rissítését. Példa: ha érzékeled egy process leállását, elég akkor mented a session megtörténtét (és hosszát).
Tárolhatod az eseményeket (változásokat) egy jól indexelt táblában így később új kérdésekre is írhatsz queryket úgy, hogy az előfeldolgozást már elvégezted.
Jelenleg én is hasonló
1. nem elegáns: ahhoz, hogy a pillanatnyi állapotot le tudjam kérdezni, a statisztikai adatokat ÉS az aggregáltat is tárolnom kell, ami redundancia.
2. sem a pc-k sem a gyűjtő nem megbízható, azaz gyakori a hálózati kapcsolat megszakadása, eszközök el-nem-érhetősége, így lehet, hogy a memóriában 2 napos állapot van.
Illetve minél kevesebb munkát szeretnék bízni alkalmazáslogikára, eseménykezelőn pl. triggert értettél?
Feldolgozás
Ha van egy SESSION eseményed, aminek van egy kezdete és egy hossza (vagy vége) egy indexelt táblából nagyon könnyen ki tudod szedni azokat a sessionöket, amik az illető időpont előtt kezdődtek, de nem értek még véget. Ehhez nem kell többféle adat. - Megspékelheted geospacial indexszel, hogy ne legyen USING WHERE a vég-időpontok vizsgálatánál.
Ekkor kell egy policyt lefektetni feketén, fehéren, hogyan lesznek kezelve az adott helyzetek, és az aszerinti lekezelés után ugyanolyan rekordokat kapsz, mintha minden szbályosan menne.
Pl: egy paint session elkezdődött 15 perccel az utolsó mérés előtt, ezután 2 napra rá kapsz egy másik mérést. - Ekkor lehet az a policyd, hogy csak a biztosan metörtént 15 percből készül egy ession; vagy lehet az, hogy a paint használatok átlagos hosszával (monduk 20 perccel) könyvelsz egy sessiont.
(Persze lehet egy időtített taszk ami szabályok szerint megkeresi és lezárja az éppen nyitott, de halottnak számító állapotokat).
Ez pedig inkább programozási feladat, mint adatbáziskezelés. Legalább is a relációs adatbázisoknak nem erőssége ez a fejta feldolgozás.
Eseményeket úgy értettem, hogy te találsz ki különböző eseményeket, mint gépújraindítás, megszakadt kapcsolat, elindított program, eltűnt elindított program - amikből építhetők másodlagos események pl. a programhasználat (ahogy egy egymást követő mousedown és mouseup váltja ki a click eseményt).
Bevallom abban reménykedtem,
PID
Egyebkent fogalmam sincs, ki talalta ki ezt a feladatot, de evekre visszamenoleg egy olyan orbitalisan nagy adathalmazrol beszelunk, hogy teljesen eselytelen a gyors kereses. Nem tudom, ki talalta ki ezt a kivalo feladatot, de vagy iskolai pelda es semmi koze egy valos adattarolashoz, vagy valaki nagyon felreertett valamit.
Idézném a nyitóposzt egy
Sosem fogok taszklistát lekérni, nem érdekelnek a PID-ek, oprendszerek, semmi ilyesmi, ezeket csupán a példa kedvéért írtam.
A módszertan érdekel elsősorban.
Akarsz róla beszélni?
Akarok! :)
Az aggregált adatokat lekérdezni millisecundumokban mérhető időbe telhet (annyira onlinenak kell lennie az egésznek, hogy egy ajax kéréssel jsonban jön a brózerbe az adat, amit live frissít majd).
Adatok még nincsenek, azokat kvázi megkapom (realtime, ha a taszkos példánál maradunk, akkor legyen WMI), nekem a többivel kell foglalkoznom.
Beszélgetés közben találod
A gyors reakció idő és a nagy adatbázis kizárja egymást. Tényleg el akarják érni - ezredmásodperc alatt - az elmúlt x évből egy-egy esemény idősorait?
Érthető, ha egy nap, vagy óra eseményeit gyűjtöd a memóriába. Annak az elérése legyen gyors, mert most nem az. A végleges tárolás szerintem külön történet.
Igyekeztem az indító posztban
És a felvetésed alapján lehet, hogy pontosítok, illetve szűkítek: gyorsan csak az aktuális adatokra van szükségem, egy évekre visszamenő idősorra nyilván a realitás talaján maradva kell a reakcióidő.
Egyébként az előbbi kitételt azért tartottam fontosnak leírni, mert nem célom az, hogy az aktuális állapotot események sorozatából kelljen alkalmazásszinten kiszámolni (ami ennél fogva lassú lenne), hanem egy szimpla lekérdezés szolgáltasson adatokat.
Modszertan?
A tasklista valoszinuleg nem a helyes analogia, mert szemmel lathatolag nem erted 100%-ban, hogy hogyan epul fel. Eppen ezert jobban jarnal, ha elmondanad hogy mit is akarsz tarolni.
Közben elkezdtem gyártani
Hasonlóságot véltem felfedezni az add-modify-delete, azaz diff, tehát változáskövetés(kezelés) között, így akadtam két linkre, ami talán segíhet, ezeket még olvasgatom:
http://dataprotocols.org/revisioning-data/
http://www.jasny.net/articles/versioning-mysql-data/
Irritalo
+1