Adatbank kialakítása helyi hálózatban

Fórumok

Sziasztok!

Jótanácsra, javaslatra, iránymutatásra lenne szükségem. Ti hogyan oldanátok meg a következő feladatot? Létezik (létezhet) célszoftver a lenti problémára?

Környezet: Zentyal szerver, Windows kliensek

Adott egy probléma, miszerint egy viszonylag nagy adatmennyiséget tartalmazó digitális gyűjteményhez kellene egy katalógust létrehoznom. Az adatok között dokumentumok, fotók, hanganyagok, videók stb. vannak, de jelenleg meglehetősen mostoha állapotban. Ez alatt azt értem, hogy az évek során felhalmozott anyaggal kapcsolatban semmiféle adatkezelési stratégiát nem alkalmaztak a gyakran változó munkatársak, csak hányták bele mappákba a cuccokat összevissza, kilométer hosszú nevekkel ellátva azokat, így iszonyatos mértékű redundancia és összevisszaság uralkodik. Jelenleg ott tart a megbízó, hogy már szinte semmit nem találnak amire szükségük lenne. Az adatok között vannak kapcsolatok, amiket menet közben kellene felderítenem, és helyretennem; egyfajta adatbankot kialakítanom, amiből értelmes információkat lehet kinyerni.
Ezt én úgy képzeltem el -- nem biztos, hogy jó úton haladok --, hogy megpróbálom megvalósítani ugyanazt, mint amit egy normál könyvtár megvalósít, miszerint:
-- A könyvtárban lévő tartalmat csak a könyvtáros (jogosult személy) kezeli, ő helyezi a megfelelő helyre, minden tartalmi mozgásról feljegyzést készít (kartoték szekrény), az összetartozó tartalmakat azonos helyre pakolja, a meglévő tartalmakhoz feljegyzéseket készít stb.
Ennek előkészületeként létrehoztam videótár, audiotár, leltár, adatbank tárterületeket és ezeket a dolgozók elől írási jogosultság megvonásával lezártam, csak kiszedni tudnak tartalmat. A dolgozók kaptak egy nem túl nagy tárhelyet, ahová átmenetileg elhelyezhetik a friss vagy módosított tartalmakat. Az adatgazda felhasználó (a fenti tárhelyekre írási jogosultsággal rendelkező felhasználó) ebből a tárból pakolja a megfelelő helyre a dolgozó által létrehozott tartalmat, létrehozza a tartalomhoz tartozó katalógus kártyát, elhelyezi azt a megfelelő témakörhöz, ellátja azt információval, a fotókat, videókat, hanganyagot címkékkel, leírásokkal.

...és itt jön a probléma: létezhet ehhez a munkafolyamathoz célszoftver? Valamiféle tartalomkezelő szoftver?

A fenti feladathoz jelenleg két különálló szoftverrel kísérletezek, de mivel egyik sem erre lett kitalálva, így hosszútávon elég nehézkesnek tűnik az alkalmazásuk: digikam -- fotók, videók, hanganyagok címkézése; zim notes -- katalógus létrehozása (desktop wiki), információtár.

Sajnos a fenti módszer hátránya még, hogy a további redundanciák kialakulásától sem véd meg...

Remélem érthetően sikerült megfogalmaznom a problémát, és persze köszönöm, ha elolvastad.

Hozzászólások

Léteznek ún. dokumentumkezelő szoftverek, rendszerek. Ezek általában elég horror áron mennek, és mégnagyobb horror, hogy bele kell tölteni a doksikat, mert azért mégiscsak úgy és az lesz benne, amit és ahogyan feltették... Ez anno egy helyen ahol melóztam addig jutott, hogy volt ajánlat, minden volt, csak mikor megvalósítás jött, akkor az irgalmatlan ráfordítani munkára már nem lett volna érdemben erőforrás.

A bónusz, hogy az összes ilyen dokumentumkezelőnek már erős GDPR megfelelőség is kell, illetve ezt átgondolva kell kialakítani a struktúrákat.

Még az is lehet, hogy valamilyen free változatot hegesztettek volna össze. A free változattal valszin nincs probléma, de mindenképp kell ember üzemeltetni és karbantartani, meg az sem árt, ha van rá támogatás. :) Egy 200 alkalmazottas nemzetközi történetnél azért nem 1MB-nyi adat keletkezik havonta.

Az erőforrás itt is probléma, ráadásul a mindenkori munkatársak képességei is meglehetősen változóak. Ilyen "mágikus" dolgokban mint a GDPR már gondolkodni sem merek, egyelőre addig kellene eljutni, hogy valamiféle "térkép" készüljön a már meglévő adatokhoz, hogy össze lehessen kötni mindazt ami összetartozik. Csodát nem tudok tenni, de képességeimhez mérten megpróbálok rajtuk segíteni... ...nem kizárt, hogy kudarccal zárul a próbálkozás, de egy próbát talán megér.

Ja, azt nem is mondtam, hogy nonprofit a szervezet, majdnem nulla anyagi forrásokkal.

Más: érdekesség képpen a káosz mértékéről: csak a duplikált fotók (projek fotók) kiválogatása és eltávolítása 2,5 évembe került... ...és ez csak a 100%-ig azonos fotókra vonatkozott. A baj tehát nem kicsi...

 a 100%-ig azonos fotókra vonatkozott

Ha 100 % ig azonos a fotó, feltételezem azonos a fájl is. Azok kiszürhetőek gyorsan.

Ha csak ugyanaz a téma, az már nehezebb.  Ha van a képekben metainfo, segithet az is valamennyit. (EXIF viewer)

Mivel eltávolítás előtt ellenőriztem minden fotót, így végignéztem minden találatot. Az Alldup alkalmazás sokat segített!

...és persze nem volt mindig azonos a fájl, volt amikor át volt méretezve, más volt a fájlformátum stb., viszont a tartalom ugyanaz volt (az Alldup a 100%-os tartalmi azonosságot kereste és találta meg az esetek nagyon nagy százalékában).

Szerkesztve: 2021. 11. 01., h – 14:56

A (mar nem)MTA BTK-nal ezzel foglalkoznak, 100TB-os nagysagrendben digitalizalnak mindent is... oket kene megkerdezned :)

Viszont a dolog ott kezd erdekes lenni, amikor feltoltod a metaadatokat is a kereshetoseghez, kulonosen a nem szoveges tartalmakhoz (foto, hang, video). Egyreszt ezt utolag baromi nehez potolni, masreszt nagyon nehezen strukturalhato, hozhato egyseges formara.

Mondok egy peldat: keszitett X.Y fotos 50 eve egy kepet egy szoborrol. Tarolni akartak a fotos nevet es a foto keszitesenek korulmenyeit (ido, hely), a szobor keszitojenek adatait (ki a muvesz, mikor-hol keszitette), es azt is, hogy a szobor kit abrazol. Aztan kiderult hogy tobb kep is keszult errol a szoborrol, de nem mindet ugyanaz vagy ugyanakkor fotozta, es ezeket ossze is kellett kapcsolni, hogy akar melyik info alapjan lehessen keresni a kapcsolodasokat.  De van foto amin tobb szobor is szerepel egyszerre, amiket esetleg kulonbozo muvesz keszitett. Meg van amin nem szobor van stb. Az idopont meg hol napra pontosan tudhato hol csak evtized/szazad szintjen...

Az mar csak hab a tortan, hogy ezek a digitalizalando kepek negativok formajaban szekrenyekben voltak meg, a metaadatok meg jobb esteben kockas fuzetben, rosszabb esetben idos muveszettorteneszek fejeben. Es ez csak egy szuk terule a sokfele digitalizalando cuccbol... evekig kerestek ra celszoftvert, egyedi fejlesztesekrol is volt szo, aztan vegul feladtak :(

Szerintem nagyon jo uton jarsz, hogy nem leegyszerusiteni es meguszni akarod, hanem komolyan beleasni magad. Az Alfresco majdnem tokeletes megoldas de nem plug-and-play. Nezd onnan, hogy olyan specialos domain tudasod lesz ami mas teruleten is hasznos lesz kesobb. 

Az ennyire speciális tudást hajára kenheti az ember, mert nem lesz hozzá nyitott pozíció egy munkahelyen sem, amikor a szükség épp úgy hozná. Minden specialista legnagyobb fejfájása ugyanez: értsen valamihez kurvára, ássa bele magát evekig/évtizedekig h. ő legyen a legnagyobb expert-je a témának. Aztán 1x csak kibasszák a jelenlegi munkahelyéről, és ott áll csupasz seggel: na most hová menjen? Ha nagyon rétegigény van arra a tudásra, akkor böngészheti majd hónapokig-évekig a profession.hu-t, mire akad egy megfelelő lehetőség. 

Míg (egy jó) generalista 1 héten belül talál magának másik munkahelyet.

Míg (egy jó) generalista 1 héten belül talál magának másik munkahelyet.

En is pont erre gondoltam, mikor ezt irtam:

… ami mas teruleten is hasznos lesz kesobb.

Azok a kollegak akik ezzel foglalkoztak, utana mas szemlelettel alltak hozza kisebb, egyedi fejlesztest igenylo dokumentum-kezelest erinto feature-oknek tobb szoftverben is. Csipobol kiraztak olyan megoldasokat ami utan a megrendelok a 10 ujjukat megnyaltak. 

Amit kihagytam: ha nagy az adatmennyiseg es/vagy nagyon dinamikusan novekszik, akkor erdemes object storage-ot alatenni. En anno egy Openstack Swiftet terveztem es implementaltam az orszag legnagyobb kozgyujtemenye ala. Ott nem Alfresco volt hanem egyedi fejlesztes, de jo valasztasnak bizonyult ebbe az iranyba menni. 

Nem növekszik dinamikusan, így ez a része nem gond. Amit most még problémának látok, hogy az Alfresco és az OpenKM is úgy tűnik fizikailag is behelyezi saját adatbázisába a fájlokat, ami nagyon szimpatikus megközelítés -- bevallom ilyesmit kerestem --, viszont jelenleg nem lesz akkora tárterületem, ahová ezt az adatbázist el tudom helyezni. Jelenleg kb. olyan 6TB adat van, amit rendezni kellene. A fenti logikából kiindulva lenni kellene még minimum ugyanennyinek, hogy legalább a meglévő cuccokat rendbe tudjam tenni. Ennyi viszont nincsen. Max. 2TB szabad lemezterületem van, és a mysql szerver is a rendszerpartíción van, és itt a hely még ennél is kevesebb.

De fantasztikus jó ötletek jöttek eddig! Köszönöm!

Az Alfresco a betöltött dokumentumokat az FS-ben tárolja, a konfigurációban megadott útvonalon. A DB-be csal a hivatkozások, metaadatok kerülnek.

Mondjuk szerintem olyan adatot DB-be tenni, amit DB-n belül sosem használunk, nem túl jó ötlet, de nyilván vannak, akik ezt máshogy látják. Még érvek is vannak mellette: elegendő csak a DB átemelése és az összes adat átjött. De mondjuk egy ilyen megoldáson a különbözeti mentés megvalósítás pöttyet nyögve nyelős lehet.

Ha ennyire limitált a vas akkor szerintem csak egy funkcionális demót (proof-of-concept) vállalj be.

Mondjuk azt, hogy letesztelitek a rendszert 1000 dokumentummal de az mindent fog tudni.

Ha tetszik a menedzsmentnek akkor meg kell venni alá a megfelelő vasat (innentől már jól becsülhető lesz hogy mi kell) és utána lehet beletolni az egészet.

Gábriel Ákos

Alfresco-t ajánlom én is. Nem kis munka lesz.

Gábriel Ákos

Két dolgot dobnék be ide:

Az egyik a Perkeep (volt Camlistore): https://perkeep.org/ - hosszú távú adattárolásra lett kitalálva, az adatmodellje nagyon flexibilis (JSON), persze fájltárolásra is jó, a weboldalról vannak jó prezentációk linkelve. Viszont ez nem tud mindent, ami neked kell, legfőbb baja, hogy egyelőre személyes használatra van kitalálva, nincs benne multiuser megoldás.

A másik az OwnCloud, ami ugye arról volt ismert leginkább, hogy a NextCloudot ebből forkolták, és egy PHP alapú open-source Google Drive alternatíva.

Én nem is ezt a legacy verziót ajánlgatnám, hanem az új, szerényen "Infinite Scale"-nek becézett változatot, ahol vettek egy nagy levegőt, és kb. nulláról újraírták / írják az egészet Go-ban (A frontendet már korábban átírták modernre Vue.js alapon). Storage backendnek tud használni lokális fájlokat, vagy a CERN-ben kifejlesztett és használt EOS rendszert. Ugyan hivatalosan "Tech Preview" állapotban van, de a CERN-ben nemrég kezdték el a saját privát cloudjukban élesben használni 12 PB adattal: https://owncloud.com/news/owncloud-infinite-scale-live-at-cern/

Akármit is csinálsz, először azt kell kitalálni, hogy a jövőben hogy dolgozzanak, hogy az új fájlok / adatok már megfelelően legyenek tárolva, tehát a rendetlenség ne termelődjön újra. A legjobb, ha a rendszerbe bele lehet ellenőrzéseket építeni, hogy pl. ki legyenek töltve a kép metaadatok, ne töltsön fel dupla képet, hogy nevezze el a fájlokat ... stb. 

Akármit is csinálsz, először azt kell kitalálni, hogy a jövőben hogy dolgozzanak, hogy az új fájlok / adatok már megfelelően legyenek tárolva, tehát a rendetlenség ne termelődjön újra. A legjobb, ha a rendszerbe bele lehet ellenőrzéseket építeni, hogy pl. ki legyenek töltve a kép metaadatok, ne töltsön fel dupla képet, hogy nevezze el a fájlokat ... stb.

Igen, ezzel egyetértek! Erre találtam ki az adatgazda felhasználót és azt az egy szem minimális tárterületet, ahová a normál felhasználó adatokat helyezhet el, hogy az adatgazda innen emelje át az adattárba a cuccokat. Az adatok addig nem kerülhetnek az adattárba, amíg nincsenek megfelelő metaadatokkal ellátva... ...ennek részletei kidolgozás alatt vannak és megvizsgálom még az eddig javasolt alkalmazásokat is.

A redundanciára sajnos szerintem nincs jó megoldás és ez kicsit aggasztó. Ha a felhasználó letölt az adattárból egy anyagot, mókol benne valamit, esetleg átnevezi, átméretezi és visszatöltésre átadja az adatgazdának... ...hát azt az adatgazda biztosan nem fogja észrevenni.

Az alldup-ot időnként le tudom futtatni dokumentumokra és képekre is, de biztos, hogy nem fogom folyamatosan mások szemetét takarítani... ...itt majd a felhasználókat kell érthető és betartható adatkezelési utasításokkal ellátni.

A metaadatok kötelező jellegű kitöltése egyszerre jó- és rossz ötlet. Jó ötlet azért, mert így kikényszerítésre kerül a metaadat kitöltése - rossz ötlet azért, mert nem szükségszerűen áll rendelkezésre az összes metaadat a doku létrejöttekor.

Maradjunk Alfresco vonalon, úgyis sok utalás volt már rá. A modell definiálása során mondható adott metaadatra, hogy kötelező, azonban alapértelmezett konfiguráció használata esetén ez csak annyit jelent, hogy ha egy dokumentum kötelező metaadatai nincsenek kitöltve, akkor az Alfresco a dokumentumra felteszi a sys:incomplete aspektust, ezzel jelezve, hogy a kötelező metaadatok kitöltöttsége hiányos - és ennyi. Hát ezzel így sokat nem érünk, konfiguráljuk át az Alfresco-t, hogy a kötelező meták kitöltése nélkül ne lehessen feltölteni dokumentumot, módosítani aspektust. Ez megoldható. Innen kezdve a rendszer nem engedi, hogy kötelező metaadat kitöltetlen maradjon. Viszont innen kezdve kiscsillió utility fejre áll. Az Alfresco-hoz adott Share felületen lehetséges fájl feltöltés, akár több is egyszerre, de az így feltöltött fájlok tipizálása már csak akkor megoldható, ha az adott típushoz se közvetve-, se közvetlenül nem tartozik kötelező metaadat! A Share felület alól Aspektust is csak akkor vehetünk fel, ha nincs benne kötelező metaadat. Már pedig itt ez lenne a lényeg. Csak a Share felületen a metaadatok kitöltése külön lépésben történik meg - viszont a kötelezőség kikényszerítésével a két lépéses kitöltés lehetetlenné válik.

Subscribe, érdekes.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Szerintem ez ott indul, hogy AI.

ugyanis 6 terrabájt adatot visszamenőleg a büdös életben nem fogsz felcímkézni kézzel sehogy, akkor se, ha az 4K-s videókból áll valami RAW formátumban. Az az adat igazából - nincs.

egy rm -rf parancs kiadása után pontosan annyi esélyed van megtalálni, mintha azok a munkatársak, akiknek felrakáskor nem volt energiáuk felcímkézni, és inkább felmondtak, most a felmondott munkatársak helyetti felcimkézés lehetetlensége miatt mondanának fel.

na viszont a kérdés pont az, hogy mire keresel: mikor kell az adat? Mi lesz a viszonyítási pont, egyáltalán kinek és mikor kell?

a múltkor egy egyetemi szerverről kellett megmentenünk fél terra adatot mert haldoklott. A legújabb fájl is 4 éves volt. 

Megkérdeztük, kinek mi kell belőle.

aztán lekapcsoltuk a szervert és kész.

Senkinek nem kellett róla semmi.

még meg van a gép de azóta se keresett rajt senki semmit.

Adtunk egy excelt (mint directory listing) amibe be kellett jelölni h hova másoljuk. Senki nem jelölt bele semmit, egy hónapig heti egyszer pingeltük meg két meetingen elmondtuk szóban.

A gépre se lépett be senki, nem változtak a linux “stat” adatok.

Maximálisan egyetértek, de mégsem ennyire egyszerű sajnos...

Biztos vagyok benne, hogy a nagy része adatszemét és archiválandó (vagy épp  törlendő) cucc, de mivel azt az adattárat használják jelenleg is (jelenleg egy szem munkatárs, de ez a szám igen változó volt az elmúlt években, és annak főnöke [jómagam külsős vagyok]), így a lekapcsolás nem jöhet szóba.

Pont azért kellene valamiféle "térképet" készítenem és összehoznom az összetartozó cuccokat, hogy legalább az értékes dolgokat ki lehessen bányászni a sok hulladék közül (mert van benne érték egyébként, csak random helyeken).

A munkatársak nem lusták voltak, csak nem mondta el nekik senki mit és hogyan kell csinálniuk a digitális anyagokkal, ezért mindenki a saját képességei szerint tette a dolgát, sem szerver, sem jogosultság kezelés, sem semmi nem volt. Ráadásul a "főnök" sincs a helyzet magaslatán e téren... ...meg nonprofit a szervezet, meg pénz sincs, meg a munkatársaknak sem az irodai munka a fő profilja, meg kovid is van... ...meg még ezer a probléma, de ezt érzik ők is, ezért kértek segítséget.

Egyetlen pozitívuma a dolognak, hogy nincs határidő a feladattal kapcsolatban, de valakinek muszáj elkezdenie, még ha nem is én leszek az aki befejezi. Őszintén szólva már azt is eredményként tudnám elkönyvelni, ha az alapokat sikerülne beton stabilan lefektetni, hogy a jövőbeni új projektanyagok már helyesen legyenek kezelve (ez jelenleg kidolgozás alatt áll).

Úgy nézem itt nem is elsősorban IT probléma van, hanem projektmanagement.

Az első lépés az, hogy tisztázni kell mi a cél, mikorra, mennyiből, kikkel kell megcsinálni.

Azaz el kell indulni Ádámtól-Évától, struktúráltan. Aztán majd jönnek szépen sorban a kérdések és azokra a (jó-rossz) válaszok.

Gábriel Ákos

A kérdés minden adattárral szemben első körben nem a belegyömöszölés, hanem a kivét.

Minden adattár tulajdonképp ezen kettő egyensúlyán múlik: ha túl sok energia betenni valamit, akkor nem lesz benne adat, mert onnan kerülik meg, ha meg nem tudom értelmesen keresni, akkor meg adatszemetes lesz belőle, berakja, két hétig emlékszik rá hogy ott van; de aztán annyi.

Az első kérdés az ilyenkor mindig felhasználóinterjúzás: mit próbáltál kiszedni? Mi kellett a napi munkádhoz? Mi alapján próbáltad keresni? Milyen jogszabály követeli meg, hogy valami meglegyen, és amikor azt ellenőrizték legutoljára, mit kerestek?

 

Könnyen lehet, hogy egy ügy valójában csak 1-2 hónapig érdekes, vagy akkor van aktív szakaszban. Kivétel pl. az építkezések, azok évekig aludhatnak, aztan hirtelen jön egy újabb aktív szakaszuk (építési engedély vs használatbavételi).

A GDPR miatt egy csomó felvételt 3 év után így-is-úgy-is törölni kell (ha felismerhetőek az emberek akár hang alapján), vagy irogathatod 3 évente az emailt hogy ugye még mindig tárolhatjuk. Mondjuk hogy egy dokumentumfilmmel vagy egy koncertfelvétellel mi van, azt nem tudom, nekünk ugye kísérleteink vannak meg interjúink…

Namost a fontos, hogy a REÁLISAN szükséges dolgokat derítsük ki: a “ha lenne toronyóralánc, kéne-e” jellegű kérdések nagyon el tudják vinni a fókuszt, és hirtelen ott vagy, hogy megígérik, hogy majd valami távoli jövőben egy meg nem nevezett személy rendet fog rakni, meg innentől mindenre felaggatnak száz metaadatot, csak tudjon gondolatolvasással keresni. Az az időpont sose fog eljönni, és már a betanításon az első rekord is max 96 metaadattal megy be, a második max 10-zel, harmadik rekord pedig sose lesz.

Utána pedig, ahogy itt a kollega kifejtette, munkafolyamat, ún SOP (Standard Operation Procedure), amit általában valami wiki-szerűségen tartanak, jobb helyeken egy screencast videóval, tipikusan loom-ból (vagy zoom/teams) felvéve.

csak aztán azt is frissítgetni kell, meg ellenőrizni, hogy passzol-e a valósághoz, meg betartják-e…

Szerkesztve: 2021. 11. 04., cs – 01:30

Nézőpont kérdése, de én tudom ajánlani a "sima" Nextcloud-ot is, mi használjuk ~400 user, ~5TB tárterület, és nincs vele gond, üzemeltetése sem igényel különlegesen extra tudást (Apache/PHP/Mysql/Mariadb alapú).

Tud címkézést is, és előre beállított feltételek mentén történő, fájl-feltöltéskor automatikus címkézést is.

Egyszerű, de nagyszerű.