Kis file-ok helyett adatbázis

C/C++

Sajnos nem értek az adatbázisokhoz, lenne egy remélhetőleg könnyen megválaszolható kérdésem.

Az egyik általunk fejlesztett (belső) alkalmazás több ezer vagy tízezer kisméretű file-t állít elő.
Ezek többnyire png file-ok, illetve kis, bináris file-ok. A méretük ilyesmi: 2kbyte, 180kbyte, 50kbyte.

Az írásuk/olvasásuk véletlenszerűen történik.

Igen kényelmetlen ez a sok apró file, szeretném belerakni őket valami adatbázisba. Azonban követelmény, hogy megmaradjon ezek könnyű újraírhatósága illetve törlési lehetősége.

A sebesség kritikus. Nem lehet lassabb, mint a file-írás.

Van valami ötlet, mit kéne használnom? Ja, és C++ interface kéne hozzá.

update:

Nem gondoltam volna, hogy ilyen sok hozzaszolas jon a kerdesfelvetesre.
A use case a kovetkezo: ez egy fejlesztoknek irt tesztapplikacio, ami computer vision algoritmusok fejleszteset segiti.
A bemenet egy video, a kimenet pedig vegyes-salata. Minden bemeneti kepkockahoz tartozik nehany tipusu binaris file: ez lehet kep (png), binaris metadata, ami tartalmaz tomoritett bitmapokat is, valamint text jellegu metadata.

Namost a platform: Windows7 desktop virusirtoval es file-rendszer szintu titkositassal. Egy izmosabb video-gyujtemeny kimenete 2, 3 de akar 20 gbyte is lehet, mindez ilyen apro file-okban.

Tobb szempontbol sem praktikus a jelenlegi megoldas. A rengeteg kis file megoli a felhasznaloi elmenyt. Lehetetlen kollegaknak konnyen megosztani. Ertsuk meg, itt it altal tamogatott ceges cloud/ storage nem lesz. Lokalis megoldasok jonnek szoba.
Hogy megelozzem az felveteseket: a virusirto beallitasait nem fogjak megvaltoztatni a kedvemert. Gyorsabb merevlemezt se osztanak.

A project celja az, hogy a csapatunkban a kollegak kellemesebb korulmenyek kozott fejleszthessenek. Mindenki utalja a tobb Gbyteos konyvtarakat. Ugyanazt egy file-ban elviselnek.

Ami nagyon gyors: egy-egy metadata kiolvasasa, mert a file-nev generalhato.

A tarral az a gond, hogy mi van, ha a kozepere kell irni?
A file-ok hierarchikus konyvtarstrukturaban vannak, already! Es tomoritettek.
SQL: ez nem az a use-case, itt nincsennek query-k.
Lehet, hogy az lenne a legjobb, ha egy nagy file-ban letrehozhatnek egy virtualis file-rendszert?

Az is fontos, hogy a rendelkezesre allo fejlesztesi ido kicsi.

( peterson v | 2017. 02. 15., sze – 16:03 )

Igen, könnyen megoldható.
De mihez kell C++ interface? Az adatbázishoz? C++-al szinte mindenhez tudsz csatlakozni.
---
"A megoldásra kell koncentrálni nem a problémára."

Elég kevés az, ami tényleg hatékony fájltárolásra van kitalálva, és azt gondolom, hogy abból, amit leírtál, egyikre sincs szükséged, a fájlrendszernél jobbat nem fogsz találni (főleg ha egygépes környezetben azt a kritériumodat is érvényesíteni akarod, hogy nem lehet lassabb, mint a helyi fájl-írás).

Ezen a nyomon elindulhatsz (elolvasva a FB haystack papert is, hogy értsd a kihívásokat):
https://github.com/chrislusf/seaweedfs

Idézek a kérdésfelvetésből:

"A sebesség kritikus. Nem lehet lassabb, mint a file-írás."

Szóval annyira azért nem lesz ez neki jó. Amúgy egy rendes (és rendesen konfigurált) FS-nél az egyszerűen nem igaz, hogy "A kisméretű fájlok tárolásának egyik hátránya, hogy a tényleges méreténél jelentősen nagyobb helyet foglal el a lemezen." Persze ez a *jelentősen* szó értelmezésén múlik.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Csavarjunk rajta egyet:
Ezeket a fajlokat halozaton keresztul masolni is szeretned. Mondjuk egy komplett konyvtarat 10k fajllal... :)

Szerintem van ertelme a .zip/tar.gz -nek. Persze feladatfuggo, mint minden.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Könnyen írok neked olyan programot, ami majdnem pont* annyi idő alatt fog átmásolni egy 10k fájlt tartalmazó könyvtárat, mint egy 10k fájlt tartalmazó tart...
BTW, ilyen kitétel fent nem szerepelt. :)

*: minél nagyobb a teljes adatmennyiség, illetve szűkebb a hálózat, annál jobban közelíti

Több szempontból sem feltétlenül igaz, amit írsz:
1. az, hogy mennyivel foglal több helyet, attól függ, hogy az egy fájlban tárolásnál milyen adatstruktúrát használsz. Bőven lehet, hogy a fájlrendszer hatékonyabban megoldja, mint mondjuk egy leveldb.
2. az egy fájlban tárolás sem feltétlenül lassabb, mint a több fájl, sőt. Képzelj el egy olyan speciális igényt, ahol a fájlok mérete maximalizálva van, mondjuk 512 kB, és nem lehet bennük null bájt. A fájlok kiírása egész egyszerűen annyi, hogy a legutolsó 512 kB-on lévő pozícióhoz hozzáappendeled. A fájl azonosítója egy szám lesz (hányadik pozíciónál tároltad). A lekérés pedig egy seek és read.
Ez nagyon hatékony lesz minden szempontból (írás, lekérés, tárolás, a fájlrendszernek nem, vagy alig kell metaadatot módosítania, lekérnie, mikor dolgozol vele)...

Nincs neked véletlenül közöd a postai szkennelt csekkek képének küldéséhez? :)

Ott az volt a "protokoll", hogy egymás után másolták a TIFF fájlokat, 16MB után új fájlt kezdtek (akár félbevágva a TIFF fájlt), majd adtak egy külön TXT-t, amiben soronként egy 100 karakteres számsor volt, benne pozíciótól-pozícióig, hogy mennyi pénz, milyen számlaszámra és a csekk képe melyik fájlban honnan kezdődik és milyen hosszú...

A JSON az igazabol a kommunikacioja nekije :) Ha mondjuk elinditasz egy keresest akkor a hagyomanyos SQL statement helyett JSON-ban formazod meg a keresest es valaszt is igy kapod vissza (konzol eseten termeszetesen. Driverrel persze kiszedheted csak a neked tetszo mezot is a rekordbol (mongoDB nyelven documentumbol...)

( dotnetlinux | 2017. 02. 15., sze – 16:22 )

Szinte bármilyen DB-be belefér, legyen az SQL vagy NoSQL alapú. Az igaz kérdés, hogy a fájlokhoz miként akarsz hozzáférni. A DB-ket alapvetően nem arra tervezték, hogy abban fájl jellegű műveletek (fopen, fseek, fwrite(pos=12, data=XXX), frewrite) végezhetőek. Egyben kapod meg a fájlt, egyben tudod írni, olvasni.

Ami gyorsabb tud lenni, az az indexelt adatelérés: fájl neve (a fizikai fájlrendszer is képes erre), dátum alapján, méret alapján, fájl típus alapján. Amire egy DB igazán jó lenne (kérdés, hogy erre neked szükséged van-e): "Utolsó 10 PNG fájl", "Első 15 januári, nem-kép fájl", "XY gépről származó LOG fájl, ami 150kb-nál nagyobb"

( persicsb | 2017. 02. 15., sze – 16:23 )

Mi a baj a sok apró file-lal?
Miért kell adatbázis? Akarod ezeket a fileokat indexelni, tartalom alapján szűrni, keresni bennük? Mert az adatbázis erre való. Strukturált adatok tárolására, és a strukturált adattáron végzett műveletekre.

Ha az a bajod, hogy sok apró file van, és nem 1 nagy, akkor használj TAR archívumot tömörítés nélkül arra, hogy egy nagy file-ként lássad, és tudj benne dolgozni.
Neked nem adatbázis kell, hanem archívum-formátum.

A legtöbb nosql adatbázis (sőt, a legtöbb akármilyen adatbázis) nem bináris adatok (illetve sajnos úgy általában akármilyen adat) -főleg fájlok- hatékony tárolására van kihegyezve...
Ellentétben a ....
(tada.wav) fájlrendszerekkel!

(persze adott felhasználási mintára azoknál is lehet jobbat csinálni)

( asch v | 2017. 02. 15., sze – 16:53 )

Most van egy kis problémád. Ha adatbázisba teszed, akkor lesz egy nagy :-).

Ne mond mar - tobb ezer vagy tobb 10 ezer osszetartozo adat - barmi legyen is az mar olyasmi ami teljesen jogosan kialt egy adatbazisert vagy valamifele managelt indexelt storage-ert nem csak ugy szetdobalva a lemezen (megha strukturaltan konyvtarakaba is van rendezve.) Ha mas nem elobb utobb az inode-ok fogynak el (en mar lattam olyat)...

Feltetelezem nem a file _tartalma_ az ami neki indexelendo, keresendo stb... A file tartalma nyilvan tartozik valahova a programon belul. Ha mas nem a filenev. Az a hivatkozas lehet a UUID ami indexelheto a tartalom meg a masik mezo. Gondolom nem kepfelismero algoritmusra kell ez a dolog. Es a mongo pl ebben jo. Kapod vele ajandekba a skalazhatosagot, a magas rendelkezesre allast, a tovabbi bovithetoseget... En meggondolnam...

Ott a szmájli a végén. De amúgy fájlok tárolására tényleg a fájlrendszer a legjobb megoldás.

Ebből indultam ki egyébként: "Igen kényelmetlen ez a sok apró file" - gondolom sokáig tart amíg a tallózó kirenderelni. Na most ha adatbázisba teszed, akkor meg külön program kell, hogy lásd miről van benne. Vagy lehet, hogy a backup kellemetlen. Ha adatbázisba teszi, akkor arra is külön tool kell. Bármi is az ami kellementlen 10E fájlban, az biztosan kellemetlen lesz egy adatbázisban is.

Ha még azt írta volna, hogy tranzakciókra van szüksége, vagy keresőindexre. Vagy hogy annyira sok adata van (kiszorozva 2GB-ről beszélünk, ami manapság nem sok). Akkor arra tényleg adatbázis való. Bár kereshetőség miatt 10E nagyságrendnél még lehet, hogy 1xűbb program induláskor beolvasni a címeket egy treemap-be, oszt jónapot.

Tegyül még hozzá azt is, hogy a kérdésfeltevés módjából az látszik, hogy tanácstalan a kérdező. Aki tanácstalan (mint egy kiskösség), az ne kezdjen adatbázist építeni, mert csak még nagyobb baja lesz.

+1. Nagyon jól kezelhető a dolog - anno úgy csináltuk, hogy a tárhelyen előre le lett generálva az n szintű könyvtárstruktúra (minden szinten "00"-től "FF"-ig), a generált kép neve egy hash lett, amiből az első n bájt az útvonalat adta ki.
A fájlok számossága, mérete, tartalma alapján érdemes teszteket csinálni, hogy milyen hash algoritmust, és milyen n-et használva lesz optimális a tárolás/visszakeresés. De lehet specifikusan, video neve, képkocka időpontja, generált fájl tipusa (kicsi, közepes, nagy) alapon is szétszórni a fájlokat - ennek annyi hátránya van, hogy a könyvtárstruktúra nem biztos, hogy előre elkészíthető, azaz a fájlok létrehozása során kell a könyvtárakat is kigenerálni (igen, tudom, egyébként is kell ellenőrizni, hogy az a könyvtár, ahova a fájlt rakja az alkalmazás, létezik-e).

Szerintem semmi gond nincs ezzel, feltéve, hogy összetettebb tranzakció kezelés nem kell, csak egy rollback lehetőség, és garantálható, hogy a rename idejére lock-olva van az elérés. Hasonlóan ehhez láttam már olyant is, hogy nem egy tranzakcióba sűrithető volt a műveletsor, hanem 2-be (user döntés kellett közben), ezért egy temp táblába irogatott, majd a végén átnevezte a táblát a program. Nem elegáns, nem vizsgáltam, hogy okozhat-e törést bármiben a tábla átnevezése, de nem is kellett többet tudnia.

mondjuk tény, hogy pl a command line max hosszát pl azt hiszem nem (legalábbis régen tuti be volt égetve valahova a kernelbe, lehet azóta már fejlődött a tudomány), kétségtelen, hogy tud meglepetést okozni valamennyire már rutinos kollégáknak is, mikor először kapnak mondjuk egy rm ./* ra megnyugtató kerepelés helyett egy "argument list too longot" vagy valami hasonlót az arcukba, lehet hogy a find . -type f|xargs valami már kényelmetlenségnek számít. (tudom tudom, -exec)

Hát ahol 10M fájl van *egy* könyvtárban, ott valami keményen el van kefélve a tervezéssel. De természetesen ha még egyszer be tudsz oda jelentkezni, akkor ez a probléma fájdalommentesen orvosolható. (Esetleg akkor van gáz, ha gyorsabban jönnek létre az új fájlok, mint amilyen tempóban a find|xargs rm törölni tudná.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

persze. De lássuk be hogy ez alapvetően KeyboardChairInterfaceError. Bár ott valami egyébként el volt baszva, az egy szokásos rendszerben el se indult volna, mert a glob kibontva üti az ARG_MAXot (ez most nálam 2M körül van, és ha jól értem ez karakter), uh simán visszajött volna, hogy ezt így nem.

nekem valami halványan rémlik, hogy egyszer láttam ilyet. De lehet hogy csak valakit, aki állította, hogy látott. :)

(ulimitet viszont nem is olyan régen láttam elfogyni valami javban írt enterspájz vacak alól. Mondjuk az egyébként is egy böszmenagy trágyadomb volt, ez volt a legkisebb vicc benne.)

Na jó, de a Un*x rendszereknek mindig megvolt az a szépsége, hogy ha nagyon akartad, akkor bárhol, bármikor tudtál olyat csinálni, hogy ha szögbelövőt adtak a kezedbe, akkor ha nagyon akarod avval bármikor lábon tudd lőni magad.

Csak ugye van az a fránya Common Sense, hogy az embernek valahogy nem jut eszébe ilyet csinálni, mert tudjuk, hogy az fájni fog és jobbára nem szeretjük ha fáj. :D

Annyira nem kell elbaszni... A "Multiterabyte UFS" nevű csodafeature-rel szoptunk a múltkor: 1TB feletti UFS esetén kötelező ez a formátum, a maximum inode sűrűség pedig 1MB/inode! Azaz a 2TB-os fájlrendszeren max. 2 millió fájl lehet... na ebbe beleütköztek szegények. És ha megveszekedsz, akkor sem tudod feljebb vinni az inode-ok számát (én meg voltam annyira hülye, hogy lementettem velük, hogy majd a news megoldja... hát nem oldotta meg).

( uid_720 | 2017. 02. 15., sze – 20:14 )

Én az Aerospike-ot választanám (kulcs-érték adatbázis, gyors, mint a villám).
De jó lenet bármilyen KV store, előnyben persze azok, amelyek byte[]-ként tárolják az "értéket". Emlékeim szerint a Voldemort ilyen. Még érdemes megnézni: Hazelcast, Riak.

--
Fuszenecker Róbert

( dap | 2017. 02. 15., sze – 21:07 )

Mit jelent az, hogy "kényelmetlen" a fájlrendszer?

( uid_6201 v | 2017. 02. 15., sze – 21:34 )

Fájlokat szeretem fájlrendszerben látni, azt is többszintű mappastruktúrába szétkenve.
A napi differenciális backup és visszaállítás könnyebb, mint a feleslegesen több 10 GB-osra hízlalt SQL tábla esetén.

Tud valaki arra jó módszert, hogy ha a 10 GB-osra hízlalt SQL tábla egyetlen 50 kB-os fájllal változik, akkor a backupra csak ez az 50 kB-nyi differencia íródjon ki?
És ilyen differencia mentő megoldást Mongó esetén?

A Windows Backup standalone szerverekre való mentési megoldás és azok közül is az egyszerűbbek közül való.
Aki azt használja, gyakran nem rendelkezik sok szerverrel illetve az az egy max két darab nem ritkán mostoha körülmények közt van elhelyezve. Oda a szalag nem való, mert nincs elég tisztaság hozzá.

Üdv,
Marci

So what?
Gyakran semmi koze az MS-nek hozza. Ellenben az ntbackup tudott szalagra menteni, szoval dolgoztak azon, h azt a feature-t ne tudja.

Egyebkent amit irtal bullshit. Evekig mentettem szalagra azzal a szarral a legotvarabb irodakban. Teljesen jol tette a dolgat. Volt egy MS termek, ami meg hasznalhato is volt a maga modjan.

( Zsugabubus | 2017. 02. 15., sze – 21:51 )

Ilyen erősen változó méretű, több tízezer fájlt valami Object Store-ba raknék inkább, ha a fájlrendszer nem jó. Amazon S3, vagy helyben Swift, Ceph Radosgw, ezekben egyszerű a tárolás/törlés/lehívás (gyakorlatilag http GET, PUT, DELETE). Mondjuk ezek közül a swift ugyanúgy fájlokban tárolja, szóval azzal gyorsabb nem lesz (bár az XFS, amit ajánlanak alá, jól elboldogul sok fájllal).

( Zahy v | 2017. 02. 15., sze – 22:00 )

Fejtsd ki, hogy mit jelent az, hogy kényelmetlen kezelni ezt a sok fájlt.

Én is a fájlrendszerben való tárolást javasolnám, esetleg valami a mostanitől eltérő névkonvencióra átállva, mélyebb könyvtárstruktúrával. De mivel erről (sem) tudunk semmit, ez inkább vaktában lövöldözés, mert nem tudjuk mi a bajod.

Ja, és *jelenleg* milyen FS-t milyen létrehozási és mountolási paraméterekkel használtok?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( cherockee v | 2017. 02. 16., cs – 10:03 )

Első kérdés: mit jelent a "kényelmetlen", miben az, mi a probléma, amit meg kéne oldani?

- Lassú az elérés? Mivel éred el őket, milyen formában (egyesével vagy listázva)?

- Keresni akarsz köztük? Kényelmesebbnek hangzik, de a fájlok tartalmában akarsz keresni, vagy csak file nevekben, vagy van egyéb adat hozzájuk? Ha igen, ez most hogy van tárolva?

- Véletlenszerű elérés esetén általában a fájlok egyesével vannak irva, vagy csoportokban (png miatt kérdőjeles, de példaként: valamit hozzáfűzöl több fájlhoz)?

- "... tízezer kisméretű file-t állít elő." - per nap, per óra, per mennyi idő? Jelenleg mekkora a mérete?

A fentiek meghatározzák, hogy a file rendszer jó-e, vagy valamilyen funkció kell még amit jelenleg nem tud, és ezt egy SQL, vagy noSQL adatbázis oldja meg. Példák: ha milliós fájl számról van szó bőven lehet, hogy adatbázis kellhet, de ha nem kell keresés-indexelés-..., gyakorlatilag csak a mennyiség kezelését kell megoldani, akkor lehet érdemesebb egyben kezelni az összetartozó fájlokat, valamilyen archivum fájlba pakolni őket (elérésüknél fontos, hogy egyben változnak-e).

( kisg v | 2017. 02. 16., cs – 10:26 )

Szerintem is több adatra lenne szükség, hogy mi a gond a fájlokkal. 100000 db 180kb-s fájl az kevesebb mint 20G. Ez simán elférhet akár buffer cache-ben vagy ZFS ZIL-ben egy 64GB RAM-os szerveren. Ha key -value storeként használod a fájlrendszert (pl. a fájlnévből számolsz ki könyvtárnevet, hasonlóan pl. a Githez), akkor nem hiszem, hogy bármely DB gyorsabb lenne, mint közvetlenül a fájlrendszerre írás (amik a tranzakciókezelés, query planning és egyéb nyalánkságok után _szintén_ fájlokba fogják eltárolni).

Aha,


RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage). You can configure different save points where an RDB is produced (for instance after at least five minutes and 100 writes against the data set, but you can have multiple save points). However you'll usually create an RDB snapshot every five minutes or more, so in case of Redis stopping working without a correct shutdown for any reason you should be prepared to lose the latest minutes of data.

Hát aki adatbázisnak használja, annak egészségére.

A másik, meg hogy akkor is in-memory database, szóval az egész ott lesz a RAM-ban. Nagy adattömegnél ez nem járható.

"Egy izmosabb video-gyujtemeny kimenete 2, 3 de akar 20 gbyte is lehet" - ez az info eddig hianyzott. Igen, valoban nem realis elvaras, hogy fejlesztoi gepen ez fusson.

A data loss ebben a usecase-ben szerintem nem igazan relevans, legalabbis itt most nem banki tranzakciokrol beszelunk (de egyebkent igazad van).

A plusz infokkal a MongoDB pl. mindjart nem is tunik annyira agyuval a verebre megoldasnak.

( vl v | 2017. 02. 17., p – 00:43 )

A sebesség kritikus. Nem lehet lassabb, mint a file-írás.

Akkor fájlokban akarod tartani. Annál csak lassabb tud lenni bármi más.

Ha nem elegendő a fájlrendszer által biztosított metaadat-tárolás (ugye kb. a fájl neve/könyvtára/dátuma a max.), akkor lehet mellé rakni egy adatbázist, amiben a fájlok adatait tárolod, és mindegyikhez beírod a path-t, ahol a fájl tartalma van.

Érdekességként: "This study shows that when comparing the NTFS file system and SQL Server 2005 database system on a create, {read, replace}* delete workload, BLOBs smaller than 256KB are more efficiently handled by SQL Server, while NTFS is more efficient BLOBS larger than 1MB. Of course, this break-even point will vary among different database systems, filesystems, and workloads. "

Tassadar hivatkozta meg a másik ilyen topikban.

Üdv,
Marci

érdekes... főleg, hogy az adatbázis is az ntfs fájlrendszeren van tárolva, legfeljebb bufferelés segíti.
A másik pedig, hogy a fájlok tárolására készített típus esetén a fájl nem az adatbázis része, csupán hivatkozást tartalmaz a fájlrendszerben létrehozott tartalomra. Az adatbáziskezelő pedig elfedi ezt. Szóval, amikor betesz egy fájt, akkor létrejön a fájl a fájlrendszerben és az adatbáziskezelő valamilyen algoritmus alapján hivatkozást tesz rá a rekordba.

" a fájlok tárolására készített típus esetén a fájl nem az adatbázis része, csupán hivatkozást tartalmaz a fájlrendszerben létrehozott tartalomra."

Tisztázzuk, miről is beszélünk. A hivatkozott cikk idején (SQL Server 2005 beta) létezett az Image mezőtípus (SQL Server 2000), meg a varbinary(max) (SQL Server 2005). Ezeknél a file az adatbázis része.
Csak SQL Server 2008 óta van FileStream, SQL Server 2012-ben pedig az azt kiterjesztő FileTable.
A Remote Blob Storage pedig SQL Server 2008 óta érhető el Feature Packben.

Üdv,
Marci

( Elbandi v | 2017. 02. 17., p – 02:08 )

leveldb, vagy valami hasonlo gyors key-value tarolo.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( bucko | 2017. 02. 17., p – 06:41 )

Feltenném az 1Ft-os kérdést: Windows vagy egyéb?
Pótkérdés: Milyen gyakran kell írni/olvasni?

( pampipudli | 2017. 02. 17., p – 08:16 )

En siman subdirectorykat csinalnek a kezdobetu alapjan a filerendszerbe es kesz. Esetleg elso ket betu alapjan. Ez konnyen kezelheto programbol es gyorsitja a listazast. Ext filerendszer eseteben pedig azert erdemes figyelni az inode-ok szamara.

( _Franko_ v | 2017. 02. 17., p – 12:11 )

"A sebesség kritikus. Nem lehet lassabb, mint a file-írás."

Ez most így semmit nem mond. Mi lesz később a fájlrendszerről beolvasott adattal? Biztos, hogy fájl beolvasása a leglassabb a teljes folyamatban? Milyen SLA van és mi alapján?

( blackluck v | 2017. 02. 17., p – 12:48 )

Fantasztikusak az ilyen topikok, valaki bedob egy kisse elborult otletet/kerdest, alig leirva a hasznalhato infokat, amire raugrik 20+ forumozo az otletekkel meg kerdesekkel hogy segiteni probaljon csak a topiknyito tunik el vagy erdemben nem reagal...

( Replaced | 2017. 02. 17., p – 13:39 )

sqlite+blob

kedves forumtarsak johogy nem hbase-t ajanlanak mar...

--
NetBSD - Simplicity is prerequisite for reliability

Azt próbálom megérteni, hogy minek berakni egy bináris fájlt az SQL táblába, ha egyszerűen 1-on-1 kapcsolatban áll egy adatbázis sorral, és ennyi kell neki. Se keresés, se listázás, semmi, csak álljon rendelkezésre. Sebességgel már elgondolkodtattak fentebb, illetve ha lenne bármi összetettebb funkcióra szükség akkor megint felmerülne egy relációs adatbázis.

Ok, nem volt teljes a megfogalmazásom: azt mondod, hogy nincs különbség, mindegy, hogy 300 karakteres szöveg, vagy 30 Mb-os binary fájl, rakjuk be az SQL-be, még akkor is ha majdnem 100%, hogy nem kell keresni a fájlok tartalmában, nem lesz felhasználva összetett lekérdezésekben, csak egyesével? Fentebb még az is vita tárgya, hogy a mongodb csak json-ra vagy minden egyébre is való, ezért nem látom át. Esetünkben ha tényleg 1-to-1 kapcsolatom van, mi előnye van az adatbázisnak a fájlrendszerrel szemben?

Semmi ilyesmit nem írtam. Azt kérdeztem meg, hogy miért tilos kategorikusan bináris adatokat (=fájlokat) relációs adatbázisban tárolni. Az, hogy mekkora méretű és felhasználású bináris adatot ténylegesen hol tárolunk, az adatbázisonként is változik, feladatfüggő is és persze az igény is változhat.

"Esetünkben ha tényleg 1-to-1 kapcsolatom van, mi előnye van az adatbázisnak a fájlrendszerrel szemben?"

Ha egy csomó adatnak 1-to-1 kapcsolata van relációs adatbázisban is, akkor miért nem tárolsz milyen ilyet fájlrendszerben?

Továbbra is keresem azt a felhasználást, ami a témanyitóhoz hasonló, fájlok amiknek a tartalmát nem kutatjuk, csak teljes irás és teljes olvasás történik, tényleg csak annyi a lényeges különbség, hogy SQL táblába kerültek a fájlok és nem fájlként érjük el őket, mert a fentiekben maximum a kényelmet látom igazolnak (naplózást és auth. feladatokat nem ide venném, az megoldható db nélkül is).

(lehet tévesen irtam abba a szálba, ahol az elhangzott, hogy kategórikusan tilos fájlokat sql-be tölteni, de egyelőre nem látom cáfolatát)

Nyilván nem tilos, mivel akkor nem lenne rá támogatott lehetőség. Régen én is tartottam képeket mysql-ben, majd egy frissítéssel kivettem onnan őket és csak a meta adatok maradtak ott. Nem bántam meg.
Ha neked az tetszik tedd be az egészet egy sqlite db-be. Próbáld ki.

Hátránya:
-A db-hez tartozó program nélkül nem tudsz belenézni a fájlokba.
-Sqlite mannagerrel is csak hexa -ban tudod olvasni és írni az adatot. Bár ez érzékeny adatok esetén egy egyszerű titkosítással akár előny is lehet.
Előnye:
-Egy fájlban van minden. Bár ez is nézőpont kérdése lehet hátrány is. A feladattól függ amiről nem sokat tudunk.

Akkor te azt mondod, hogy érdemes úgy gondolni a közvetlen file kezelésre, mint kerülendő, körülményes és nehéz megoldásra? C-nél magasabb szinten levő programnyelvekre is érvényes szerinted ez? Gondolok itt azokra a programnyelvekre, ahol a file kezelés már bőven egyszerűbb mint C-ben (a programozó számára), támogatott és tesztelt az erre kitalált library-ja.

Nem a fájlkezelés a nehéz. A hibatűrő és konzisztens fájlkezelés a nehéz. Ha akarsz tranzakciókat is, főleg úgy, hogy a tranzakción kívüli szálak a régi állapotot lássák, a tranzakcióban lévő szálak az új állapotot lássák és tudj két fázisú commit-ot is, na, az már valami. És akkor nem beszéltünk egy szót se arról, hogy mindezt legalább két példányban, mert ugye egy géppel nehéz értékelhető rendelkezésre állást biztosítani.

Akkor mondhatjuk azt, hogy ha van tranzakciókra szükség, akkor DB, ha nincs, akkor fájlrendszer? Mert ez nekem a fentieknek nem mond ellent, illetve nem tiszta a leirásból, hogy az irás mit jelent, van-e szükség tranzakciókra, de ha jól sejtem erre is lehet válasz az, hogy "nem baj, majd lesz/lehet, jobb ha van már most".

"Akkor mondhatjuk azt, hogy ha van tranzakciókra szükség, akkor DB, ha nincs, akkor fájlrendszer?"

Nem. Akkor is meg kell mérni és végig kell gondolni, hogy megéri-e a bináris adatot pusztán a gyorsaság miatt külön kezelni a többi adattól. Beleértve azt is például, hogy legyen konzisztens a mentésed...

> Nem a fájlkezelés a nehéz. A hibatűrő és konzisztens fájlkezelés a nehéz.

En igy szoktam szerver oldalon fajlt kezelni:
fajlnev-datum-verzio.md
ln -s fajlnev-datum-verzio.md fajlnev.md

Ha valtozas tortenik:
fajlnev-datum2-verzio2.md
rm fajlnev.md
ln -s fajlnev-datum2-verzio2.md fajlnev.md

Nekem ez meg mindig eleg volt. Utkozes kizart, minden lepes atomic.

Olyan nalam meg nem fordult elo, amikor egy csokor fajlt kellett egyszerre modositani,
es az volt a tranzakcio maga. De ha ilyenbe futnek akkor a tranzakcio
egy bejegyzes lenne egy adatbazisba, hogy mely fajlverziok tartoznak ossze.

A backup megoldott, a szinkronizalas is "nagyjabol".
Bar itt mar elojonnek furcsa esetek (corner case).

Az in-place fajlmodositastol (hello outlook (2003,2007,2010,2013) .pst fajlkezeles!:)
ova intenek mindenkit. Azzal csak megegeti az ember magat.
Nincs is szebb annal, amikor egy 12TB-os .pst fajl hibas lesz aramszunet miatt:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

ln -sf nem atomic.
Az pontosan rm; ln -s

lasd: http://stackoverflow.com/a/1466570

megj: mondjuk en programnyelvbol hivom meg, a linux parancsok csak szemleltetes. De ott is kulon torlom.
Mondjuk mashogy nem is lehet:
https://nodejs.org/api/fs.html#fs_fs_symlink_target_path_type_callback

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem csak arra gondolt, hogy ha valóban parancssori eszközökkel csinálnád, akkor gyorsabb lenne ezt a két lépést egy paranccsal végrehajtani, mint kettővel. (Egyszerűen azért, mert a két lépéseshez kell két db fork+exec, + unlink + symlink, míg az egyparancsoshoz csak egy fork+exec +unlink+symlink.) Nyilván nem lesz atomi, de lehet hozzá közelíteni próbálni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

csak az utokor szamara: "atomicra "torekedni" nagyon veszelyes.
A problema okat nem szunteti meg (ie atomic modositasok), viszont az idoablakot leroviti: sokkal ritkabb bug es meg nehezebb debuggolni.

Szoval atomic muveleteket osszevonni (es igy mar nem atomic) nem a legjobb strategia. Meg ugy sem hogy ennel a konkret peldanal nem tudnek ertelmes hibakezelest javasolni az rm es az ln -s koze. ((amit ne lehetne utana megcsinalni).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ha már utókor: nem értek veled egyet. Ha nem tudod elkerülni a problémát, akkor dokumentáld le, hogy problémát okozhat; minimalizáld a probléma előfordulásának valószínűségét; kérdezz meg okosabb embert arról, hogy ki kellene-e egyáltalán kerülni ezt a problémát ilyen valószínűséggel, és ha igen, akkor hogyan. De hagyni a picsában szarabbul, hááááát ....

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

miert lenne szarabb?

En szerintem atomic muveleteket nem szabad osszevonni. Hibakezeles lehetosegetol esel el.

Most "szarabb" erre a konkret peldara vonatkozik, vagy csak ugy altalanossagban?

Ha erre, akkor egyik este osszeszedem a (hiba)lehetosegeket es valaszolok erdemben.

Van alkalmazasom, ami ilyen elven mukodik(meg a backup is symlinkbol all, amit a remote rendszer amikor letolt mar a tenyleges fajlt kapja)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Attól szarabb, mert - mint ahogy te is írtad - nagyobb esély van a hibára. És ha nagyobb a valószínűsége, akkor valószínűleg többször fog is hibázni. Azaz mondjuk az én megoldásom 10 évente egyszer, a tied meg minden évben. Viszont ha valaki ezt biztonsági hibaként fogja fel és erre építi a támadását, akkor kb mind a két megoldás esetén hamarabb bedönti a rendszert, mint hogy észrevennénk.
És valóban, az atomi műveleteket ne vonjuk össze, csak akkor ha egy másik atomi művelettel kiváltható.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

idealis esetben a hiba mindig le van kezelve valoszinusegtol fuggetlenul.

Igy tok mindegy, hogy mlyen gyakori, ha a rendszer fel van keszitve ra.

Az atomic muveleteknek pont az a lenyege, hogy a race conditiont eszre tudod venni, hiba eseten vissza tudsz lepni.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

OK. Tehát ezek szerint abból indulunk ki, hogy tudjuk, hogy ez (egyik sem!) nem teljesen korrekt művelet, és le van kezelve a hiba. Ebben az esetben megint ugyanoda jutottunk. Az eredeti megoldás szarabb, mint a zeller által módosított, mert több erőforrást használ. Ebben az esetben fogjuk fel erőforrásoptimalizálásnak.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"Azaz mondjuk az én megoldásom 10 évente egyszer, a tied meg minden évben."

A visszatérő hibáknak azért van egyfajta immunitás növelő funkciója, mint az emlékeztető oltásoknak... ha évente egyszer előkerül, akkor a szervezet képes azt lekezelni, mert emlékszik a megoldásra. Ha ritkán jön elő, akkor egyrészt nincs emlékezet, másrészt a kollektív tudat is erősen sérülhetett a fluktuáció által. Szóval a hibát akkor javítsuk, ha az tényleg javítja és valóban fájdalmat csökkent. Csak a szépsége és a statisztika kedvéért ne javítsunk hibákat.

Amit írtam, ott volt a végén: "... javítjuk a hibát". Másrészt *szerintem* az egyszer csinálja szarul vs tízszer csinálja szarul esetén nem az általad ellenjavallt statisztika okán, hanem az általad javasolt fájdalomcsökkentés miatt "javítunk".

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Attól még nem feltétlen kell javítani, ha fáj. Akkor kell javítani, ha üzletileg is megéri. Feltéve, ha nem hobbiprojektről beszélünk. Ha tízszer ritkábban jön, akkor nem tudtad javítani, csak ritkítottad az előfordulását és egy ismert üzemeltetési kockázat helyett egy bizonytalan mértékű üzemeltetési kockázatot lőttél a jövőbe... :)

"Utkozes kizart, minden lepes atomic" az lehet hogy utkozes kizart, de azt nem tudod garantalni, hogy a linkek egyszerre jonnek letre, ergo, johet olyan keres, hogy az egyik fajlbol mar az uj van a masikbol meg a regi. Persze ha osszetartozo fajlokrol beszelunk, de amugy meg mi a francnak lenne egy tranzakcio.

-
Go konkurencia kezelés gyorstalpaló

nalam tobb fajl egyuttes verzioja nem kellett meg.
De ha lenne ilyen kovetelmeny, akkor lekerdeznem a fajlok verzioit is, es osszevetnem hogy mely tranzakciohoz tartoznak. ( elvileg a legutolsohoz, igy teljesitmenykieses se nagyon van)

(fajlok verzioja: hova mutat a symlink)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( mhmxs v | 2017. 02. 17., p – 14:50 )

Vegtelenul leegyszerusitve:

a) kod -> fajlba iras, kod -> fajlbol olvasas
b) kod -> adatbazis -> fajlba iras, kod -> adatbazis -> fajlbol olvasas

Szoval b) nem lehet gyorsabb mint a). Azzal lehet trukkozni, hogy az adatbazis memoriaban tart bizonyos fajlokat, ami valami statisztikai alapon tortenhet. De ha tenyleg random a fajl olvasas, akkor vagy minden memoriaban van, vagy az adatbazis ugyanugy egy fajlbol fogja olvasni a tartalmat. Nem mondom, hogy nem valhat be egy adatbazis, es lehet, hogy konnyebb lesz kezelni a fajlokat, de, hogy gyorsabb nem lesz az nagyon valoszinu.

-
Go konkurencia kezelés gyorstalpaló

Arról semmit. Arról az a teszt mond valamit, amit linkeltem, egészen addig, amíg az ellenkezőjét nem támasztod alá.

A kettőt összerakva pedig az jön ki, hogy nem az MSSQL gazdálkodik paranormálisan jól az erőforrásokkal (értsd: kis méretű fájlokkal gyorsabb, mint a fájlrendszer), hanem az, hogy az NTFS gazdálkodik mérhetően rosszul a kis méretű fájlok esetén.

"az a teszt mond valamit, amit linkeltem"
Az csak rólad, sajnos. Egy reverse engineeringgel készült nem is teljesen hibátlan és stabil driveren mért teljesítményből következtetni másik platformra!?

Amúgy meg hagyd el már. Pontosan tudom, hogy tudod, hogy a filerendszerek nem hasonlíthatók össze 1db leíró adattal. Van feladat, amire ez lehet a jobb és van, amire az. Hagyjuk, mert Számodra kínos ha folytatjuk...

Üdv,
Marci

"Az csak rólad, sajnos."

Nyilván az NTFS nem lehet rossz. Szerintem kevesebb lojalitás bogyót kellene bevenned és kicsit kitágulna meg színesedne a világ. :)

"Egy reverse engineeringgel készült nem is teljesen hibátlan és stabil driveren mért teljesítményből következtetni másik platformra!?"

Mert erre utal az is, hogy egy adatbázis rendszeren át gyorsabb a kis méretű fájlok kezelése, mint direktben a fájlrendszerről. Erre a következtetésre ügyesen nem reagáltál, mintha kínos lenne a valóság. Hm?

Még mindig nem mondtam semmit az NTFS-ről, hiába próbálsz itt  csúsztatni. 

"egy adatbázis rendszeren át gyorsabb a kis méretű fájlok kezelése, mint direktben a fájlrendszerről. Erre a következtetésre ügyesen nem reagáltál, mintha kínos lenne a valóság. Hm?"

Én nem ismerek olyan szabályt, hogy a filerendszernek kell gyorsabbnak lenni az adatbázisnál, mert különben a filerendszer rosszabb más filerendszerhez képest. Ha pedig nem hasonlítunk, ha nincs mérce, akkor nincs jó meg rossz sem. Miért égeted magad?

Üdv,
Marci

Nincs csúsztatás, két benchmark van:
- az NTFS lassabb kisebb fájlok kiszolgálásában, mint az MSSQL
- az NTFS lassabb kisebb fájlok kiszolgálásában, mint más fájlrendszerek

"Én nem ismerek olyan szabályt, hogy a filerendszernek kell gyorsabbnak lenni az adatbázisnál, mert különben a filerendszer rosszabb más filerendszerhez képest."

Nincs "mert különben". Két független benchmark van, ami ugyanazt a gyengeséget hozza eredményként, csak valami becsípődött Nálad a témával kapcsolatban.

"Miért égeted magad?"

Ez egy jó kérdés. Gondolkodj el egy kicsit a dolgon Te is, hogy mi mellett és miért kardoskodsz... :)

mhmxs odáig egyszerűsítette a kérdést, ahol a poszméhek már nem tudnak repülni, a kenguru pedig nem létezhet, mert több energiát fogyaszt az ugrálás, mint amennyit megszerezhet a táplálkozással. Végtelenül leegyszerűsíteni nem mindig vezet helyes eredményre...

Kihagyta a modellből ugyanis, hogy bár mindkét esetben lemezre írás/olvasás történik végül, de az egyik esetben ez kevés fájl, amihez élő handle van (az adatbázis fileok), míg a másikban minden rekordhoz egy, ráadásul meg sincs nyitva.
Így ha adatbázisban van a blob, jó eséllyel annyi a teendő, hogy kikeresi, hogy a diszken hol vannak a szükséges lapok és beolvassa őket. Ha filerendszeren, akkor erre rárakódik rekordonként a file megnyitásának (handle létrehozás) költsége.
További különbség, hogy a filerendszernél a fileok lemezen való tárolásának legkisebb egysége a cluster, míg adatbázis esetén az egyes rekordoknak nem kell clusterre igazítva lenni.
Induljunk onnan, hogy nincs a memóriába belapozva egy rekord sem. Gondolatkísérletként nézzünk a cluster-méretnél sokkal kisebb rekordokat. Adatbázis esetén egy cluster beolvasásával jópár rekord a memóriába kerülhet, míg filerendszernél csak egy. Utóbbi esetében tehát adott számú rekord beolvasása sokkal több lemezművelettel is járhat.

Ez a két kiragadott példa megmutatta mhmxs modelljének túlegyszerűsítő voltát.

Üdv,
Marci

Miközben igazad van, de a valóság ennél bonyolultabb. ;)
Van az a mennyiségű rekord, amikor figyelembe lehet venni egyéb szempontokat.
Pl. a fantasztikusan jó eredményt adó btree esetén sokan elfelejtik, hogy a fa mélységének megfelelően lépkedni kell az ágakon a levélig. Ennek alapján (adott rendszeren) sikerült már a btree+RDBM sebességéhez képest két nagyságrenddel gyorsabb keresést készíteni.
Amit leírtál, annak alapján használtak a rendesebb adabáziskezelők raw volume-ot. Ezzel a egyszerre kiküszöbölhető a filesystem overhead és a filesystem tranzakció és cache is. Mert ugye az adatbázis jobban tudja mi a saját tranzakció/cache elvárása. Ezzel szemben manapság az adatbázis -> filesystem a divi, hiszen a gépek és a diszkek gyorsak...aztán jön a koppanás.

De van másik DE is! A file írásról sem szabad valami elvont dologként beszélni. A valóságban a "file" alatt ott csücsül még 3-4 layer, amelyek együttesen határozzák meg az egyes műveletek sebességét. Rendszer válogatja, de néha döbbenetes eltéréseket lehet mérni. És itt a használat módja a domináns és nem az, amit az egyes benchmarkok állítanak.

"A valóságban a "file" alatt ott csücsül még 3-4 layer, amelyek együttesen határozzák meg az egyes műveletek sebességét."

Szerinted az adatbázis alatt hány réteg csücsül?

"Amit leírtál, annak alapján használtak a rendesebb adabáziskezelők raw volume-ot. Ezzel a egyszerre kiküszöbölhető a filesystem overhead és a filesystem tranzakció és cache is."

Nézd, én továbbra is tartom, hogy ha a fájlrendszer lassabb, mint ugyanazon a gépen legjobb esetben is egy driver-en, socket-en, majd több absztrakciós szinten keresztül elért adatbázis, akkor ott nem az adatbázis a paranormálisan gyors, hanem a fájlrendszer nem alkalmas apró fájlok kezelésére. Lehet ezt csűrni és csavarni, de nincs nagyon értelme. Egyébként érdemes utánaolvasni az INDX Buffer fájl működésének és megérteni, hogy miért gyenge a sok és kicsi fájl kezelésében az NTFS. Aztán esetleg térjünk vissza a témára.

Több mindentől függ. Inkább írni akarod, inkább olvasni akarod, inkább felülírni akarod, inkább módosítani akarod, kell-e sparse fájl, mennyire apró, mennyire sok... és így tovább. Ha van use-case, arra tudsz teszteket csinálni, teljesen más fájlrendszer lesz a legjobb a különböző használati esetekre. Nincs kedvenc fájlrendszerem, operációs rendszerem és architektúrám, mérek és döntök a feladat függvényében.

Most az én érveimet ismételed. Ezt írtam:
"Pontosan tudom, hogy tudod, hogy a filerendszerek nem hasonlíthatók össze 1db leíró adattal. Van feladat, amire ez lehet a jobb és van, amire az. Hagyjuk, mert Számodra kínos ha folytatjuk..."

Én azt kérdeztem, hogy Linuxon ext4-nél is előfordulhat-e Szerinted, hogy a fájlrendszer lassabb, mint ugyanazon a gépen legjobb esetben is egy driver-en, socket-en, majd több absztrakciós szinten keresztül elért adatbázis? NTFS-re ezt ki tudtad jelenteni általánosságban, maradjunk ext4+Linux-nál is ugyanezen a részletezettségi szinten, azt kérem.

Üdv,
Marci

Igen, előfordulhat, mert vannak esetek, amikor az ext4 nem elég gyors kis fájlokra és ha a paraméterezésével nem sikerült nagyobb teljesítményt elérni, akkor másik fájlrendszert választunk a feladatra. Egyszerűen van, amire az ext4 nem a legalkalmasabb fájlrendszer, lásd sok benchmark a témában.

Hogy az adatbázis alatt hány réteg csücsül(het), azt pont a következő sorban idézted. ;)
Az NTFS-t nem szükséges bemutatnod. Pont a sok fájl+sok dir jelenséget vizsgáltam meg XP-től 2008 szerverig. Mégpedig azért, mert egy certified expert kolléga feltalálta a fájlok 16^5 struktúrában tárolását. Ez 10k esetén még nem gond, de felette rohamosan és permanensen növekszik a buffer cache, amit a továbbiakban nem lehet visszanyerni. Innentől kezdve a lassulás a legkisebb gond!
Persze részedről angyali naivitás azt hinni, hogy csak sok kis fájl okoz gondot. Kaptam egyszer egy kisebb diszket filmekkel. (NTFS, paging és indexelő szolgáltatás kikapcsova, és volt elegendő memória) Másoltam, másoltam, de már a tollam kezdett hullani... Majd ugyanazt linux alatt 2-3x gyorsabban átmásoltam. Tehát az NTFS semminek a tárolására sem optimális. :) Leginkább windows alatt. Az meg csak feltételezem, hogy épelméjű ember nem használ más rendszer alatt NTFS-t.

Ja, és igazad van. A sebességért tényleg nem az absztrakciós réteg a felelős, hanem az esetlegesen hozzá tartozó fizikai struktúra. Alapeset pl., ha 511 vagy 65537 blokkmérettel dolgozol - de ez csak pl!

Kicsit elkestem a valaszolassal, szoval most ide. El tudok kepzelni olyen csillagallast, ahol adott feladatra optimalizalt adatbazis jobban teljesithet, mint mondjuk a feladatra nem optimalizalt/alkalmas fajlrendszer, valoszinuleg ezert is irtam azt, hogy "de, hogy gyorsabb nem lesz az nagyon valoszinu". De itt csatlakoznek a kollegahoz, hogy ha egy rohadt bonyolult adatbazis jobban teljesit mint egy faek egyszerusegu fajlmuvelet, akkor valoszinuleg nem az adatbazist sikerult jol megirni, hanem a fajrendszert sz@rul (ertsd nem valo adott felhasznalasi esetre). De tok jo, en lecsupaszitottam a problemat, mas hozott konkret merest hasonlo felhasznalasi modra, emberunknek amugy sincs sok valasztas fs teren, es meg az ntfs-t is fikazhattuk kicsit. Mindenki jol jart :D

-
Go konkurencia kezelés gyorstalpaló

Szépen levezetted, hogy miért lassabb az NTFS fájlrendszer kis fájlok esetén, köszönöm. :)

"Ez a két kiragadott példa megmutatta mhmxs modelljének túlegyszerűsítő voltát."

Nem, ez azt mutatja, hogy mennyire erősen meg akarsz magyarázni olyan dolgokat, amelyek nem igazán magyarázandóak. Néha meg kell állni és el kell fogadni a tényeket.

Azt hiszem ezek után nem tudok mást tenni, minthogy véglegesen beletegyelek az "eleinte hozzáértőnek látszó, de agyatlanul lojális sales ügynök" dobozba. Sajnálom.

"Szépen levezetted, hogy miért lassabb az NTFS fájlrendszer kis fájlok esetén, köszönöm. :)"

Ne haragudj, de ezt nem kellett levezetni, hiszen ez volt a kiinduló állítás: kis blob fileok esetén az SQL Server a gyorsabb az NTFS-nél. Amúgy azt mutattam meg, hogy mhmxs modellje miért hibás.

"erősen meg akarsz magyarázni"

Nézd, Te kérted, hogy mhmxs hozzászólásától nézzem végig a szálat. Megtettem és rámutattam, hogy miért helytelen a szálnyitó hozzászólás.

Mi az, ami nem magyarázandó? Mi az a tény, amit nem fogadtam el? Mit sales-eltem éppen agyatlanul lojálisan? Nekem olybá tűnik, hogy semmilyen gyártó semelyik termékéről nem beszéltem.

Üdv,
Marci

Jegyezzük fel e szép eseményt!
6 hozzászóláson keresztül erőlködtél, hogy mondjak valami olyat, ami alapján rám akaszthatod az "eleinte hozzáértőnek látszó, de agyatlanul lojális sales ügynök" címkét.
Miután erőfeszítéseidet nem koronázta siker, nem csüggedtél: mondtad, csak úgy, alap nélkül.

Üdv,
Marci

"ó eséllyel annyi a teendő, hogy kikeresi, hogy a diszken hol vannak a szükséges lapok és beolvassa őket" marmint miutan felepult a kacsolat a klienssel, aki elkuldte a credentialt, aztan kikereste a usert, eldontotte van-e jogosultsaga hozzaferni az adathoz, aztan lefuttatta a query elemzot, abbol kitalalta melyik tablaban van a fajl, aztan eldontotte a feltetel szerint melyik index tablat hasznalja a kereseshez, aztan kiolvasta az indexbol, hogy hol van a tenyleges adat, amit aztan kiolvas a diskrol, majd bepakolja a result setbe. Csak ennyi a dolga. Jo tudom egy connection poolloal az elso harom lepes "kihagyhato", de azert csak ott van.

"cluster-méretnél sokkal kisebb rekordokat" csak kerdezem, hogy ennek merete nem konfiguralhato? Mi van akkor ha a fajlrendszert a felhasznalasi modra hangolod?

"egy cluster beolvasásával jópár rekord a memóriába kerülhet" jol ertem, hogy sok kicsi fajlt olvasni lassu, ezert olvassunk sok nagyobbat?

-
Go konkurencia kezelés gyorstalpaló

Egyrészt ez nem kis méretű fájlok olvasásáról és írásáról szól, másrészt 2013-as cikk, az általam linkelt cikk meg 2015-ös.

Egyszerűen a fájlrendszereknek megvan a maga erőssége és gyengesége, más célokra jó az ext4, a ReiserFS, a ZFS, az UFS, az XFS és az NTFS (lásd a linkelt teszten belül és úgy általában a fájlrendszerek eltérő eredményeit különféle tesztesetekre). Ezen lehet sokat pörögni, hogy az NTFS a fájlrendszerek kvintesszenciája, csakhogy olyan fájlrendszer nincs, amelyik minden feladatra a legjobb. Neked ez azért lehet furcsa, mert nincs választékod fájlrendszerből...

"lehet sokat pörögni, hogy az NTFS a fájlrendszerek kvintesszenciája" Ne készíts nekem szalmabábot, kösz. Semmit sem mondtam az NTFS-ről.

Ellenben kezdettől azt mondom, hogy az Általad citált teszt és az állításod közt nincs kapcsolat; nézd csak vissza. Lejjebb kifejtettem, hogy a használt NTFS driver teljesítménye miatt gondolom így. Most bemutattam, hogy valóban, azt ntfs-3g teljesítménye 2013-ban siralmas volt a kereskedelmi driverhez képest. Mi is igazolja, hogy 2015-re az ntfs-3g teljesítménye megtáltosodott? Ha ezt nem tudod igazolni, fogadjuk el, hogy nagyjából hasonló lehetett a FUSE driver teljesítménye. Ebből következik, hogy valóban nem lehet a Phoronix tesztből az NTFS-re (Windowson) következtetést levonni. Ezt kívántam megmutatni.

Üdv,
Marci

"Ne készíts nekem szalmabábot, kösz. Semmit sem mondtam az NTFS-ről."

Miről is beszélünk? Továbbra is van két állítás:
- az NTFS lassabb kisebb fájlok kiszolgálásában, mint az MSSQL
- az NTFS lassabb kisebb fájlok kiszolgálásában, mint más fájlrendszerek

Azóta jössz változatos mindenfélével, hogy miért nem igaz a második, de egy small files benchmark-ot nem tennél ide cáfolandó.

Mit akarsz kihozni? Azt, hogy kis fájlok kezelésére használjunk MSSQL-t, mert jobb, mint az NTFS és implicite minden más fájlrendszernél jobb az NTFS kis fájlokra? Ez nem szalmabáb, hanem konkrétan ez jön át a hozzászólásaidból...

"Mit akarsz kihozni?"

Nézzük vissza:
TE> Lehet, hogy az NTFS nem a legjobb fájlrendszer? :)
TE> Ó: http://www.phoronix.com/scan.php?page=article&item=linux-40-hdd&num=3
ÉN> Ó! Linuxon lassú az NTFS, tehát (Windowson) szar. Régebben igényesebbnek tűntél.
TE> Nosza, hol a fájlrendszerteszt, ami az ellenkezőjét bizonyítja?
ÉN> Én semmit sem állítottam itt az NTFS-ről, ergo nincs mit alátámasztanom.
ÉN> Csupán meglepett, hogy mennyire össze nem függő dolgokat voltál képes leírni.
[...]
TE> mi mellett és miért kardoskodsz... :)
ÉN> Én csak melletted kardoskodom, azért, mert ez a szál nem vall Rád.

De még egyszer megismétlem, mit akarok kihozni: őszintén meglepett Tőled egy ennyire szakmaiatlan megszólalás.
1) "az X nem a legjobb fájlrendszer" - Sületlenség. Nincs olyan, hogy "legjobb fájlrendszer". Feladatok/problémák vannak és arra megoldási lehetőségek.
2) A FUSE driveres Phoronix teszt továbbra sem mond semmit a Windows NTFS teljesítményéről. Tehát 1)-es állításban ha fikarcnyi értelem is lenne, 2) akkor sem támasztaná alá.

Ez a színvonal Tőled, megdöbbentett. Semmi mást nem kívántam mondani.

Üdv,
Marci

"Ez a színvonal Tőled, megdöbbentett. Semmi mást nem kívántam mondani."

Hát eléggé rosszul és elég hosszan sikerült... és még mindig nem sikerült hoznod egy pici tényt se, csak a (rejtett) személyeskedést. Amit mindig sikerül hoznod, szóval én egy cseppet sem lepődtem meg.

> Miről is beszélünk? Továbbra is van két állítás:
> - az NTFS lassabb kisebb fájlok kiszolgálásában, mint az MSSQL
> - az NTFS lassabb kisebb fájlok kiszolgálásában, mint más fájlrendszerek

Ahh, hagyjuk a csudaba:

Az NTFS lassu.

Btw, az megvan, hogy egy-egy node.js projektet nem lehet torolni, mert a path tul hosszu? (node_modules a node_modulesban)

Elotte at kell nevezni... Noh, ez az igazan gaz...;-D

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Először bevallom, egy aprócskát csúsztattam: Természetesen aix alatt, bár ez triviális.
Ez után már egyszerű a válasz - jön a következő csúsztatás - aix alatt bármilyen feladathoz lehet hangolni a diszk alrendszert. Félreértés ne essék, ezt nem úgy olvastam valahol, hanem esetenként különböző igények szerint alakítottam a diszkeket, és mindig sikerült elérni - az adott körülmények között - a maximális sebességet.
Maga a jfs2 csak egy vfs driver, tehát önmagában nem lehet "dícsérni". Olyan marhaság, mint a "legszebb piros szín" megjelölés. Helyette mondhatod, hogy X festő Y festményén milyen gyönyörű(ek) a piros szín(ek).
Tehát, ha azt mondod FS, akkor az legalább 20-50 paramétert jelent a valóságban.
Ennek ellenére vannak alapvető előnyei:
- az oprendszerbe integrált
- az oprendszer ismeri - külön raid nélkül - a 3x tükrözést, stripe-ot, hot spare-t stb.
- a jfs a kis fájlokat az inode-ban tárolja (mint az ext4)
- több féle tranzakciót a feladatnak megfelelően konfigurálhatsz a performance/biztonság szempontok szerint

Szóval rengeteg olyan paraméter/fogalom létezik, ami linuxon egyáltalán nincs!

Little kis story: Egy maildir típusú backupot kellett elővennem, ami eredetileg linux jfs-en volt. A gépben meg csak egy pici ssd. Csináltam mindenféle, az eredetinél nagyobb fs-t, de nem fért fel. A végén jfs-t csináltam ugyanarra a területre, és ráfért. :)

( gthomas | 2017. 02. 17., p – 21:38 )

LevelDB, RocksDB, illetve hasonló beágyazott adatbázisok.
De a sima SQLite is nagyon jó lehet - nem a leggyorsabb, de a legmegbízhatóbb!

Biztos, hogy ugyanarra gondolunk?
https://docs.openstack.org/developer/swift/overview_architecture.html
"The Object Server is a very simple blob storage server that can store, retrieve and delete objects stored on local devices. Objects are stored as binary files on the filesystem with metadata stored in the file’s extended attributes (xattrs). This requires that the underlying filesystem choice for object servers support xattrs on files. Some filesystems, like ext3, have xattrs turned off by default.

Each object is stored using a path derived from the object name’s hash and the operation’s timestamp."

SQLite: tranzakció biztonságos kezelése.

LevelDB: gyors, kevés helyet foglal (tömörít).

Amúgy én a fájlokat Camlistore-ban tárolom (camlistore.org, deduplikál, jövőbiztos), adatbázisban csak a camlistore-os címe van a fájl neve mellett.
Illetve egy régebbi megoldás volt hogy tar-ba tettük a fájlokat, ennek az indexe van LevelDB-ben.

Jó megoldás lehet a seaweed-fs, de az nem deduplikál, pedig az sokat számít - többet, mint a tömörítés!

Mert az a cél, hogy 100 év múlva is olvasható legyen: egyszerű, dokumentált sémát használ JSON-ban, és minden ilyen, az egy blob-ot kivéve ami az, ami: adat.
Minden tartalom-címzett, a tartalom hash-e a címe.
A tárolandó fájlt felbontja változó méretű (Adler32 rolling hash) darabokra, ezeket letárolja. Ezek címeit (=hash-eit) elteszi egy json listába a fájl egyéb adatai mellé, hogy ez a tartalma.
Ha ez a json túl nagy lenne (16Mb a darab limit), akkor felbontja, azokat tárolja, és ezekről a darabokból lesz a fájl tartalma...
Tehát egy fát épít, így akármerkkora fájlok tárolhatók.

Nincs felülírás, append-only a dolog.

( zeller | 2017. 02. 19., v – 22:35 )

A megoldás tehát a jelenlegi komponensek minimális módosításával, gyorsan, jelentős teljesítménynövekedést hozzon. Ez természetesen lehetséges - a három paraméterből legfeljebb kettőt kiválasztva.

Ne sarkitsuk ki.

Legfokepp azt szeretnem tudni, hogy mi lenne a legjobb alternativaja a kis file-oknak...

Aztan meglatjuk, hogy mi az, amit meg is valositunk.

A 'jelenlegi kompononensek minimalis modositasa', mint feltetel nem all fenn. Annyira nem bonyi a rendszer, a file a sok nem a kod. Nem akarok agyuval verebre, ennyi.

Ne sarkitsuk ki.

Legfokepp azt szeretnem tudni, hogy mi lenne a legjobb alternativaja a kis file-oknak...

Aztan meglatjuk, hogy mi az, amit meg is valositunk.

A 'jelenlegi kompononensek minimalis modositasa', mint feltetel nem all fenn. Annyira nem bonyi a rendszer, a file a sok nem a kod. Nem akarok agyuval verebre, ennyi.

Gondolom a windows-os share performanciája az egy könyvtárba strukturálatlanul behányt pártízezer fájl esetén az olajbányász béka ülepe alatt van. Ezen nincs mit csodálkozni, így működik... (Megnyitja a könyvtárat, és máris végignyálazza az összes benne lévő fájlt, először a jogosultságokat, utána magát az állományt, hogy ha-szükség-lenne-rá tudjon róluk infót mondani...)

Az egy nagy fájl eseténe z elmarad, ellenben az összes, megosztott használatból eredő ütközést, problémát, meg később várhatóan jogosultságokat is az adott alkalmazásnak kell lekezelnie, ami sql-es irány esetén sem lesz pöcc-röff egyszerű...

Azért Marcinak ez a hozzászólása ad valami tippet. Én úgy gondolom, hogy a megosztó gép a VHD-kat ossza meg - amibe ő egyébként lokális diszkként felcsatolva ír. (Mondjuk azt nem tudom, ezt egyszerre meg lehet-e csinálni - azaz látni X:\a.vhd -ként és Y: -ként is.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( mrceeka v | 2017. 02. 20., h – 02:07 )

Fontos lenne jobban érteni, mit jelent, hogy a rengeteg kis file megöli a felhasználói élményt.
Egy konkrétumot emeltél ki: Lehetetlen kollegaknak konnyen megosztani.

Ha csak ennyi a nehézség, arra akár megoldás lehet a fileok .VHD beli tárolása és diszk-ként bemountolása a Disk Managementben: https://blogs.technet.microsoft.com/virtualization/2009/05/14/native-vh…

Hogy megérthessem, mennyit javít ez a helyzeten és milyen jobb lehetőségek vannak, kérem, részletezd a mindennapi problémákat.

Üdv,
Marci

( cherockee v | 2017. 02. 20., h – 10:46 )

"A project celja az, hogy a csapatunkban a kollegak kellemesebb korulmenyek kozott fejleszthessenek. Mindenki utalja a tobb Gbyteos konyvtarakat. Ugyanazt egy file-ban elviselnek."

Kéne a pontos felhasználást ismerni. Van egy központi tárhely, ennek a tartalmát töltögeti le sok fejlesztő, és itt a gond, hogy a letöltés körülményes, jobb lenne egy nagy fájl? Akkor viszont vagy valamilyen changelog kéne, vagy minden frissitésnél egész fájl letöltés lesz.

Ha tudod ird le részletesen, mi milyen vason, milyen elérhetőséggel tárolódik, mit csinálnak a fejlesztők, honnan, min keresztül, mit töltenek le (egészet vagy jól behatárolható részeket, akár nagyobb mappákat is, de csak részeket), mivel töltik le, ...

( b | 2017. 02. 20., h – 12:51 )

zip file, én mindig így szoktam. Esetleg sqlite, de inkább zip mert azt lehet enkódolni könnyen és minden tudja olvasni. Én mindig nagyon vegyes környezetben dolgozom.

--
GPLv3-as hozzászólás.

A zip azért jó, mert az ékezetes fájlnevek kezelése - a kb 20 éve létező kváziszabvány ellenére - baromi szarul volt implementálva még kb 2 éve is. Szóval ha egyáltalán felmerül a heterogén környezet, akkor lehetőleg ne.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( khiraly | 2017. 02. 21., k – 02:38 )

ha jol ertem a feladatot:

bemenet: .mkv fajl

kimenet: ugyanabban a konyvtarban 2GB-20GB 2-130kB meretu fajlok plusz az eredeti .mkv

szamszerusitve: 10 000-10 000 000 fajl
(2GB 130k fjalokkal, vagy 20GB 2k fajlokkal)

egy film max 2 ora, 25 kepkockaval: 7200*25= 180 000

Az en *egyszeru* megoldasom az lenne, hogy a generalt fajlokat a filmben 10 mpkenti konyvtarba dobalnad szet.
Azaz 10*25= 250 kepkocka tartozna egy konyvtarba.
kb. igy:
0m00s-0m10s
0m10s-0m20s

Igy a keltkezett fajlok mennyisege legrosszab esetben(10 millio fajl) is 40ezerben van maximalizalva.

Ha ez nem eleg, akkor ezeket a konyvtarakat .zipelnem, es programbol nyitogatnam meg.
Persze ha muszaj, kezzel(=segedeszkpz nelkul) is meg lehet nyitni.

Alapvetoen KISS, foleg a masodik s:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Zsugabubus | 2017. 02. 21., k – 10:46 )

Lehet, hogy az lenne a legjobb, ha egy nagy file-ban letrehozhatnek egy virtualis file-rendszert?

Csinálj egy nagy fájlt, rá mkfs, majd mount -o loop :D

fokozzuk meg: mindezt windows alatt loopdevice alternativaval (vhd). ;-P

Basszus mrceeka mar javasolta. Mar egy jot trollkodni se engedik az embert...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( uid_720 | 2017. 02. 22., sze – 10:29 )

Sokan sok jó dolgot javasoltak.
Most érdemes lenne egy mérést összerakni:

* fájlrendszer
* RDBMS megoldások
* NoSQL megoldások
* saját, memória alapú cache

témakörben. Egyik összeállítás sem bonyolult.

--
Fuszenecker Róbert

A tárolás ésszerűen megválasztott - konfigurálható méretű - konténerekben. Kivétel a nagy méretű fájlok.
Tartozik hozzá egy index, amiben a keresendő jellemzők és pointerek vannak. Egyes fájltípusok tar.gz formátumban igény szerint.
Igaz, ez egy backup rendszer. Fejlesztők akkor használják, hogy egy adott rendszer adott logjából (mondjuk napi 12GB) meg szeretnének nézni egy intervallumot. Várakozási idő nincs, pedig a kiszolgálást shell és awk (no, jó - egy kis C is) végzi.
Itt a tárolás lényege a tömörítés. Ebből következően az olvasás mindig gyorsabb, mint a diszk. ;)
A keresés 99%-ban az indexben történik. Az index text, de tetszőleges nem sql adatbázisban is lehetne.

A tervezés a 16^N dir típusú, igen népszerű, de nagyon lassú tárolási mód ellenében készült. Így a fájl és dir mennyisége alacsonyan tartható, azaz nem lassítja a rendszert. A másik előny, hogy lényegtelen a tároló sebessége.

Maga a rendszer végesállapotú automata, és teljesen automatikus. Jelenleg 128 ügyvitel rendszerről/16 szerverről gyűjt irdatlan mennyiségű logokat, tranzakció logokat, adatbázis mentéseket, és a data store-t (szkennelt dokumentumok, stb.), összesen 10-12 féle adattípust.
A gyűjtés kvázi-online, azaz 5-10 perc késleltetéssel kerülnek az archivumba a gyűjtemények. A rendszer tranzakciót is kezel, ezért nincs elveszett adat.

VAN a rendszerben sql is, amibe gyakorlatilag az index kerül bele mégegyszer: 1db gyűjtemény=1 sor.
Ezt jól le lehet kérdezni a webes programozóknak. ;)

Ha leálítjuk legalább néhány órára a rendszert, akkor elkezdi fokozott tempóban behozni a lemaradást. (Elméletileg 1:600000 is lehet a dinamikus sebességnövekedés. Ez olyan mint a dinamikus kontraszt. :)))
Ilyenkor több ezer tranzakció csücsül az adatbázis cache-ben, mert a rendszer erőssége az, hogy nem használ sql-t, ezért gyorsabb is nála. :-D

Természetesen a hálózat maximális terhelése és az archiválási idő is paraméterezhető.

Szóval ez nem a topicnak megfelelő feladat és tárolási mód. Ennek ellenére biztosan kialakítható lenne egy optimum némi józan paraszti ésszel. Inkább a feladatot kell megfogalmazni és számolgatni.
Ebben az backup rendszerben <1000 dir és kb. 6000 fájl tárolja a 30M entitást. A maximális dir mélység a mount pointtal együtt csak 3.

Elöljáróban nem ez volt az első ilyen rendszerem, hanem a Mátyás király bicskája típusú továbbfejlesztéseket is figyelembe véve a tizensokadik. Ezek az adatgyűjtő rendszerek kezeltek tudakozó/telefonkönyvi ügyfél- és járulékos adatokat, számhordozást, telefonközpont cdr és alarm rekordokat, tarifáltak, vagy számlázást készítettek elő, ügyfélszolgálatot láttak el forgalmi adatokkal - a többit már elfelejtettem. :) Maga a technológia úgy 24 éve keletkezett. Fő jellemzői:
- végesállapotú automata vezérlés és teljesen automatikus működés
- tömörített adattárolás - soha nem volt elég a diszk
- a végesállapotú gép kissé eltér a tankönyvi megoldástól, mert a működést az adatfajta is meghatározza
(Ez nem nagy durranás: Más adatokra más feldolgozást kell futtatni, de egyes esetekben a feldolgozó folyamat is más lehet.)
- ksh (bash), awk C, és gzip, ssh, trickle - meg néhány alap unix utility

Az alapfeladat max. 100 komplex ügyviteli rendszer szószátyár naplóinak, mentéseinek az archiválása + a fejlesztők kiszolgálása, ha valamilye gond van valamelyik ügyfélnél. Az "előd" egy ifjú titán által írt java program volt, amely néha leakadt, de 600kb xml konfigurációból dolgozott. Ez utóbbiból készítetem 12 sort az adatbázisba (a 12 adattípushoz), meg 5-6 paramétert. Ja, ez a program napi egyszeri mentést tudott készíteni, ha nem szállt szét. Ezzel szemben az új rendszer szinte "az utolsó pillanatig" menti a mentendőket, tehát baleset esetén könnyebben visszaállitható a sérült kliens. Ehhez meg kellett oldani a tömörített adattovábbítást is. A végeredmény olyan, hogy szinte észrevehetetlen a hálózati forgalom, ezért munkaidőben is működhet, nem zavarja a felhasználókat. Ha mégis, akkor át lehet paraméterezni, de ez csak kétszer, lassú adsl kapcsolátnál fordult elő.

Az adattárolás alapja a logokra kihegyezve: RFC1952
Alesetek az 5 perces ciklusidő alatt
- nem keletkezett semmi
- egy sor
- több sor
- >64MB - ez paraméterezhető, hogy a log ne kannibalizálja az erőforrásokat, illetve hátha van magasabb prioritású feladat is - Ebben az esetben az 5 percnél sűrűbben keletkezhet ilyen job.
Az így begyűjtött chunk-ok a konténer végére kerülnek. Kiolvasáskor egy seek után egy stream-ként kerülnek az adatok egy filterbe - ha szükséges, de lehetőség van egy vagy több chunk kitömörítés nélküli kiolvasására is.

A problémák, gyengeségek:
- Hosszú a fejlesztés ideje, bár ennek 90%-a inkább a specifikáció hiánya.
- Az ősidőkben kidolgozott lock mechanizmus, ami exkluzív diszk lock-okat használ. Ezt éppen most dolgozom át, mert >100 (ami ugye a specifikáció volt) kliensnél már jelentősen lassult a rendszer. Azaz nem végez az 5 perces köridő alatt.
- Az előbbihez tartozik az is, hogy a "profi linuxos" ide kevés. Viszont elég, ha rám hallgat. ;)
- Szintén ide tartozik, hogy a lock megoldás gyilkosa a 4k advanced format, részben az új diszkek miatt is szükséges az átdolgozás. Ez több, mint 20 év után nem olyan nagy szégyen. ;)
- Merev a rendszer. Gyakorlatilag a bevasalt folyamatok végrehajtására készült. A folyamatokat azért nem olyan nehéz módosítani, de ilyen rendszerekhez gyakorlatilag ketten értünk.
- Mint említettem, ez éppen inkrementális backup (+ a régi mentések automatikus takarítása) feladatra készült. Ennek ellenére biztosan megfogalmazható az "akármire is alkalmas" megoldás.

Természetesen a világon léteznek hasonló, szabadon konfigurálható és tetszés szerint kialakítható megoldások. Úgy 15 éve találkoztam eggyel, ami mindent tudott. Az apróbb hátrányai közé sorolnám, hogy valószínűleg a paraméterezéshez is legalább az én tapasztalatom kellet volna, meg az ára is néhány 100 misi körül mocorgott.

Ha a fájlrendszer index+adatblokkok, akkor ez tényleg tekinthető a fájlban megvalósított fájlrendszerként is. ;)
Ha meg a nagyságrendeket nézzuk, akkor kb. annyi fájl van, mint ami a topicnyitó feladatban. Viszont a tárolt chunk darabszám 4-5 nagyságrenddel több, miközben ez a tény ennek a rendszernek tökmindegy. :)
Ráadásul több mint 8 éve működik.

Nem ez a különbség.
A fájlrendszeren tárolt 1000 fájl 1000 directory entry-t és 1000 fájlt jelent, ahol a keresést a fájlrendszer végzi.
Ha adatbázisban tárolod, akkor az adatbázisnak megfelelő, egy vagy több fájl/raw volume (soha nem partíció) tartalmazza az 1000 fájlt valamilyen rekordszerkezettel, és az adatbázis kezelő végzi a keresést.
Nálam n konténer+index n+1 fájlban van tárolva, és saját program végzi a keresést*. A keresés után egy open() és egy seek() rendszerhívás után lehet olvasni.
Ha nem világos, akkor kérdezz nyugodtan.

*Ebben a rendszerben egy text fájl az index és egy egyszerű awk script a "keresőmotor", mert így is elég gyors. Nagyobb elvárások esetén egy saját adatbázisba kerülnének az indexek.

Nekem ugy tunik arrol van szo, eloadtad hogy nalad nem filerendszer adatbazis stb formaban vannak tarolva az adatok, hanem meroben maskent.
Am megis ugy fest ugyanazokat a lehetosegeket hasznalod csak nem egyszeruen csak egyet kozuluk hanem azok kevereket aminek hasznalatahoz csinaltal egy rendszert ami kezeli.
Valoban nem egy szokvanyos megoldas amit leirtal, igy tekintheto elteronek azoktol, de alapjaban ugyanazokat az elemeket hasznalja ha jol ertem a mukodest.

Aham... van pontos dokumentáció, ami 90 szazalékban hiányzik és különben is csak ketten értenek hozzá. Hány ilyen gányolt dolgot láttam már...

"Hosszú a fejlesztés ideje, bár ennek 90%-a inkább a specifikáció hiánya."

"A folyamatokat azért nem olyan nehéz módosítani, de ilyen rendszerekhez gyakorlatilag ketten értünk."

Úgy látom, mániád a lekicsinylő félremagyarázás. Ez sem az én hibám.

A 90% annyit tesz, hogy a projekt rám eső részét képtelen voltam elkészíteni, mert a specifikáció el nem készítő SENIOR FEJLESZTŐK szartak az egészbe. Ekkor egy kisebb felkészültségű kolléga felfogván a helyzetet összeszedte a szükséges infókat. Ez úgy +5 hónapba került. Az így előállt dokumentációt visszacsatolva már csak a seniorok trehány rendszerét kellett gatyába rázni és néhol körbeprogramozni.
Vagy mire gondoltál? Biztosan nem tűnt fel, hogy a rendszer már 8 éve hibátlanul és automatikusan működik?

Bizony, csak ketten értünk hozzá. Talán a gagyi rendszer és az én hibám az is, amikor pl. a C#, PHP, Java -és még sokáig sorolhatnám - zsonglőr koléga egy hét meló után lelkendezve jelenti, hogy sikerült pár kilobájtny text állományt beolvasnia?! Méghozzá úgy, hogy minden bájt bejött és pont az, amit elküldtem neki, meg még ki is tudta írni ugyanazt! Egy ilyen zseni bele tud nyúlni bármibe is?
Egy rendszer átadásakor - az én nyomásomra, mivel általában nem olvasnak dokumentációt, hiába van - néhány napos oktatást szoktam tartani. Ilyenkor a megrendelő tátott szájjal alszik. ;) Ha megkérdezem, hogy érthető volt-e minden, arra a legpozitívabb válasz ennyi volt: Nem mindegy? Holnapra úgy is elfelejtem! No, ő üzemeltet.
A rendszer által megvalósított folyamatokat javarészt szerződések írják le. Ha valaki nem ismeri a dokumentációt (ami van) és a szerződést sem, akkor hogyan tudná módosítani azt?
A dokumentációt általában fejből tudom. Support hívás esetén először ilyet szoktam válaszolni: Látom, a 37. oldal 4.1.2 pont második bekezdést nem olvastad el. ;)
Szerinted ettől gagyi egy rendszer?

Szerintem meg mindenki hülye, aki nem járt a Holdon! Így is meg lehet ítélni a dolgokat.

Éppen tegnap söröztünk.
- Én a föld alatt közelítettem meg a sörözőt.
- A kolléga az útvonalamra merőlegesen, a föld felett, de a busz útvonalát nem kersztezve, azzal párhuzamosan.
- Én ittam pálinkát, ő meg evett - hátha valamelyik mérgezett.
:)

Ne aggódj! Üzembe helyezés után
- van dokumentáció
- a feladat pontosan és hibátlanul megvalósítva
- a dokumentációban a paraméterezés és indítás ismertetése után mindig szerepel ez:
"... működése automatikus, ezért a rendszer karbantartásakor történő indításán és leállításán kívüli üzemeltetői beavatkozás csak ..."
A virágnyelvet félretéve: Ne nyúlj hozzá mert eltöröm a kezed!

"... működése automatikus, ezért a rendszer karbantartásakor történő indításán és leállításán kívüli üzemeltetői beavatkozás csak ..."

Persze... innen szaglik, hogy mennyire fos... :D

...szívesen megkérdezném erről az üzemeltetőket is, mondanál elérhetőséget?

"Úgy látom, mániád a lekicsinylő félremagyarázás. Ez sem az én hibám."

A lekicsinylő félremagyarázás jellemzően a Te hibád, lásd a két bekezdésnyi ömlengést és kicsit korábban a több bekezdésnyi leírást, amiben mindenki kivétel nélkül kontár balfasz, egyedül Te vagy az, aki mindent jól csinál... és közben leírsz egy rendszert, amire próbálsz marhára büszke lenni, pedig az csak összegányolt dolgok lazán csatolt halmaza, amit elsőként szoktak kidobni az első adandó alkalommal. Ilyenkor az jön át, hogy Te magad vagy a kontár balfasz, csak még nem vetted észre... :/

Ezeknek az állításoknak a java része nem derül ki a szövegből. Finoman szólva "messzemenő következtetéseket vonsz le" - a semmiből.
Nem mindenki kivétel nélkül. Ha valakinek nem működik a dolog, nekem meg igen, az miért ne lenne kontár?
És ha nekem meg működik, akkor mit csinálok rosszul? Főként ahhoz képest, akinek nem működik?
összegányolt dolgok lazán csatolt halmaza
Ez nekem olybá tűnt, hogy a megvalósítás pontosan követi a feladat igényeit. Indoklás a következőkben.
amit elsőként szoktak kidobni az első adandó alkalommal
Biztosan ritkán járt arra az adandó alkalom. :D
Az első rendszeremet 19 év után szinte azonnal kidobták. (Ezt a barátommal ketten írtuk.)
Pontosabban a vég előtt 8 évvel egy új projekt miatt már leszerelték. A valóságban meg se állt, csak azonnal rendeltek egy illesztést a tendernyertes rendszerhez. Ami állítólag már az én rendszeremet is kiváltotta. :)))
A harmadik rendszeremet is kidobták 14 év után. Egyszerűen nem bírták tovább! Ez egyébként egy lazán összegányolt főközponti számlázást végző gányolás volt. Már, ha ismered az ilyen gányolásokra vonatkozó törvényi/jogszabályi előírásokat. (A "főközpont" egy 3 telephelyes országos rendszer volt. Nem akarok részleteket írni.)
Az utolsó rendszerem még csak 8 éves, erről büszkélkedtem, pedig csak néhányszor több adattal dolgozik, mint a korábbiak.
Az eddig működött/működő kb. 14 rendszerem összesen kb 160 évet futott, automatikusan, az üzemeltetőknek nem sokat munkát okozva.

Vajon Te mivel büszkélkedhetsz azon kívül, hogy alapos indokkal lekontárbalfaszoztál? :-P

"Ezeknek az állításoknak a java része nem derül ki a szövegből. Finoman szólva "messzemenő következtetéseket vonsz le" - a semmiből."

Nyilván. Lássuk:
"mert a specifikáció el nem készítő SENIOR FEJLESZTŐK szartak az egészbe"
"már csak a seniorok trehány rendszerét kellett gatyába rázni és néhol körbeprogramozni"
"Bizony, csak ketten értünk hozzá."
"pl. a C#, PHP, Java -és még sokáig sorolhatnám - zsonglőr koléga egy hét meló után lelkendezve jelenti"
"az én nyomásomra, mivel általában nem olvasnak dokumentációt, hiába van"
"Az "előd" egy ifjú titán által írt java program volt, amely néha leakadt, de 600kb xml konfigurációból dolgozott. Ez utóbbiból készítetem 12 sort az adatbázisba (a 12 adattípushoz), meg 5-6 paramétert."
"a "profi linuxos" ide kevés. Viszont elég, ha rám hallgat"

És a többi. Mindenki kontár balfasz, kivétel nélkül, csak Ti ketten nem. Na, ilyenkor van az a valóságban, hogy Ti ketten vagytok a kontár balfaszok, a disszonanciát a mondavilág és a valóság között pedig ilyen lekicsinylésekkel igyekeztek palástolni. De tegyünk egy próbát, adj egy neveket, akiket megkérdezhetek a leszállított rendszerről.

"Biztosan ritkán járt arra az adandó alkalom. :D"

Akkor szokott jönni az első adandó alkalom, amikor eltűnik rendszer hírhedt szerzője és kiderül, hogy a király teljesen meztelen, az általa adjusztált és bőszen védelmezett rendszer egy üzemeltethetetlen és dokumentálatlan spagettikód halmaz, amit azért nem dobnak ki azonnal, mert csak az hónapokba vagy évekbe telik, mire kibogozzák a szálakat, hogy mit és miért csinál, illetve hol lehet elvágni az egyéb rendszerekkel való kapcsolatokat.

"Vajon Te mivel büszkélkedhetsz azon kívül, hogy alapos indokkal lekontárbalfaszoztál? :-P"

Miért is kellene faszmérőst játszani? Ha nagyobb rendszert tettem már össze, akkor elkussolsz, vagy mi az, ami miatt erre feltétlen szükséged van?

Nem érted. Emagyarázom.
Amiket idéztél az sajnos történelem. Tényleg megtörtént, így történt, ezek voltak a tények.
Amit leírtam, az éppen ennek a rendszernek a elkészítés közben szerzett negatív tapasztalatok kivonata. Pontosan az a szörnyű benne, hogy mennyi dilettáns és trehány ember után kellett szart lapátolni.
Ebből normális ember nem azt következteti ki, hogy mindenkint kontár balfasznak tartok. Szerencsére dolgoztam kiváló szakemberekkel is, akik emberileg sem voltak utolsók.

Mindenkit ilyen kontár balfasznak tartasz, hogy idézem: Akkor szokott jönni az első adandó alkalom, amikor eltűnik rendszer hírhedt szerzője és kiderül, hogy a király teljesen meztelen, az általa adjusztált és bőszen védelmezett rendszer egy üzemeltethetetlen és dokumentálatlan spagettikód halmaz, amit azért nem dobnak ki azonnal, mert csak az hónapokba vagy évekbe telik, mire kibogozzák a szálakat, hogy mit és miért csinál, illetve hol lehet elvágni az egyéb rendszerekkel való kapcsolatokat.
És ez 19 év után derül ki?

Bocsánat, erre a hozzászólásodra is itt válaszolok.

Sajnos itt a fórumon, sem a fórumon kívül rendszerek, üzemeltetők adatait nem adhatom ki. Talán nem hallottál róla, de ezek az információk az "üzemi titok" kategóriájába tartoznak.
Ennek ellenére egy automatikusan működö rendszer helyes minősítésere nem biztosan helyes kifejezés a "fos". Legfeljebb még nem láttál olyat. ;)

Semmi faszmérősre nem gondoltam. Tudom, naív vagyok, de arra gondoltam, hátha valami értelmeset is válaszolsz a pocskondiázás helyett. Hát nem jött be. :(

Ha már itt tartunk, megemlíteném, hogy alpári stílusod kifejezetten szórakoztat. Sajnos még nem vagy a csúcson - megelőztek. A nyertes az a huptársunk, aki egy - egyébként témába vágó - József Attila idézetre a maga művelt iskolázott és inteligencs módján így szólt hozzá: meg vagy te baszódva?

"Amiket idéztél az sajnos történelem. Tényleg megtörtént, így történt, ezek voltak a tények."

Így igaz, teljesen hiteles, hogy mindenki kontár balfasz volt...

"Szerencsére dolgoztam kiváló szakemberekkel is, akik emberileg sem voltak utolsók."

Tudom, olvastam, amikor írtad, hogy összesen ketten értetek mindenhez is.

"És ez 19 év után derül ki?"

Ó igen, éveken át lehet visszafelé lapátolni a lóba a szart, láttam én már ilyet, a legdurvábbat 9 éven át nem sikerült kidobni, pedig évente nagyjából 500 milliós veszteség volt belőle.

"Sajnos itt a fórumon, sem a fórumon kívül rendszerek, üzemeltetők adatait nem adhatom ki."

Ó, igen, de sajnos titkos. Ultimate érv.

"Tudom, naív vagyok, de arra gondoltam, hátha valami értelmeset is válaszolsz a pocskondiázás helyett. Hát nem jött be. :("

Mit akarsz hallani? Azt, hogy napi 20 millió tranzakciót és 30-50 GB adatot toltam be adatbázisba? És öt éven át kellett ezt megőrizni? Igen, ez 30 milliárd sor és 50 TB adat egy szimpla adatbázisban. Még csak erőmű se kellett hozzá, egy CPU mag megoldotta, pedig munkaidőre esett a terhelés nagy része és ez még nem is volt egy nagy rendszer. De volt már ennél nagyobb és kisebb munkám is. És?

A terhelés az egy dolog, az a nagyobb baj, hogy architekturálisan iszonyúan és messziről bűzlik az a csodaszép rendszer, amit nagy odaadással leírtál. Túl sok ismertetőjegyét hordozza az elbaszott rendszereknek és egyre újabb és újabb részleteket fedsz fel, amelyek ezt csak megerősítik, mindezt nyakon öntöd egy "én vagyok az egyedüli fasza gyerek" mentalitással és az egészen a koktélcseresznye az, hogy egyébként szigorúan titkos minden részlete.

Egy picit olyan hallgatni, mint amikor a szomszéd hülyegyerek azt próbálta beadni, hogy egy ukrajnai haverjával DDoS támadták az orosz titkosszolgálat szerverét... te is ilyesmivel nyitottál, hogy fantasztikusan egyedi rendszered van, aztán kiderült, hogy az a rendszer nem unique hanem csak custom. :/

Már mindent értek.
Teljesen felesleges ennyit írnod. Elég, ha annyit írsz hogy nem hiszed el, vagy egyszerűen csak hazudok.
Bár nem szokásom, de ha így gondolod, nekem tökmindegy.

Végre elárultál valamit a saját tevékenységedről is. Már korábban kiderült, hogy valószínűleg más profilban dolgozol. Ugyanis egyetlen mondatban leírtam a rendszer működési elvét, de számodra ez kínaiul volt, és átsiklottál felette. Tehát nem ismered, nem is hallottál arról a technológiáról, amivel dolgozom.
Valamihez nem érteni egyáltalán nem szégyen. Írtam több száz sor sql-t, de valószínűleg arra sem méltatnál, hogy kiröhögj. Én meg ahhoz nem értek. Nem nagy ügy.

Nem tar az, hanem gz vagy tgz. Az RFC1952 egy kicsivel 1970 után keletkezett. ;)
Az idők meg változnak, nagyon régen nem divi a nine track! (Ez egy költői kérdés: Már ha tudod minek a rövidítése a tar.) Ha már olvastad az RFC1952-t, akkor kiviláglik belőle, hogy nem igazán tud 1440 fájlnevet eltárolni, a tar meg tud. Meg azt is tudja, hogy két sql szerver verzió között nem kell az új formátumra migrálni. :)))

Miközben mindenről győzködlek, árud el milyen problámát látsz ebben a megoldásban, vagy mi a kérdésed?

"Persze a módszer egyik fentivel sem egyezik."
Innentől olvasd. Te fájlrendszerben tárolsz adatokat, egy saját formátumban.
Ennek analógiája mondjuk egy tetszőleges beágyazott KV store (vagy a tar, egy külső indexszel), szóval az egyik fentivel sem egyezik nem teljesül.
A tar egy konténer formátum, a gz nem az. De ezt nyilván felesleges magyarázni olyannak, aki tudja, minek a rövidítése a tar, és olvasta az RFC1952-őt. :)

BTW, a tar szerintem inkább akroníma, mint rövidítés, de ezen már tényleg nem fogunk összeveszni.

Fájlrendszerben tárolok? Ezt itt leírtam miért nem. Ebben az esetben a fájlrendszer egy mellékes tényező. Minden további nélkül feloszthatnám a diszket 250MB-os darabokra, és a konténer méretét 200..250MB-ra választva nem lenne különbség. Az a lényeg, hogy pl. a fájlrendszer vs. sql tárolásnál az adott tárolási módra jellemző utasításokat használom a tárolásra és keresésre. Itt meg sem sql sem fájlrendszer specifikus dolgokat nem használok. Ezt nem is magyaráznám tovább, csak ha nem érted.

Saját formátumban tárolok? Bár hájjal kenegeted a májamat :-), de sajnos sem a tar, sem a gzip formátumot nem én találtam fel. A konténerek egyértelműen tar (tgz) és gzip formátumban vannak, és az ennek megfelelő parancsokkal kezelhetők. Ez a lényeg.
Ami nem szokványos, de adódik a használat módjából, hogy ezek nem a megszokott módon keletkeznek. A konténerhez a file.[t]gz >> (hozzáadódik), csak előtte feljegyzem a méretét és még néhány jellemzőt róla. Ahogyan és ahova feljegyzem, az megint lényegtelen a tárolás szempontjából.

Mottó:
Itt nálunk világhírű!
(Lenni, vagy nem leni/Mel Brooks 1983)
A gzip is egy konténer formátum, csak nem tárolja a fájlnevet. Ezért tudtam készítettem rá egy index helyreállító programot. (Ami megsült szerver mellé kiválóan fogyasztható. :( ) Innentől kezdve, - hogy legyen mit kipihenned hétvégén, - foglalkozzunk a tgz kommutatív tulajdonságaival! :-)
Míg a (tar+tar+tar+...)gz nem indexelhető a fenti módon, a tgz+tgz+tgz+... indexe megegyezik a fenti formátuméval, azaz a gz+gz+gz+... indexével. Tehát az indexelt gz formátum - itt nálunk - univerzális. A különbség csak annyi, hogy egyik esetben a chunk egy "darab" stream, a másik esetben egy tar.

Nincs ebben semmi "merőben másként". Bájtokkal operálok. ;)
Amiről azt gondolod, hogy nem egy szokványos, az valójában szabványos és standard.
Nem kell hozzá sql szervert üzemeltetni, érzéketlen bármilyen frissítésre és verzióváltásra. (Miket beszélek! Az utóbbiak linux esetén egyszerűen nem így vannak.) A shell script, awk és néhány sor C "hordozható" és időtálló. Lehetővé teszi, hogy ugyanarra a feladatra 10-20 évig ugyanaz a rendszer működhessen.
Tehát nem szokványos, mert alapszinten dolgozok. Ez a szép a unix-ban, hogy nem nagyon kell rá programot írni, hiszen minden benne van már vagy 50 éve.

Azert olykor eleg ellentmondasos fogalmazol :)
Felvezetoben azzal jossz a te megoldasod nem hasonlit egyik megszokottra se de mindegyiktol jobb, majd kiderul valojaban ugyanazokat a megoldasokat hasznalja, csak nem "hagyomanyosan" ezek egyiket hanem egy kevereket azokbol.
Az is szerepelt leirasban, hogy sql-t hasznal, most meg hogy nem kell hozza sql szerver (oke lehet pl. sqlite-ot hasznal, de nem azt sugallja).
A lenyeg ahogy eloadtad meg leirtad majd ahogy probalod most vedeni enyhen zavaros es nekem ugy tunik felesleges.

Legfeljebb humorosan, csak kevesen értik. ;)

Felvezetoben azzal jossz a te megoldasod nem hasonlit egyik megszokottra se de mindegyiktol jobb, majd kiderul valojaban ugyanazokat a megoldasokat hasznalja, csak nem "hagyomanyosan" ezek egyiket hanem egy kevereket azokbol.
Bizonyára igazad van. Hiszen az sql szerver is ugyanazt az open/close/read/write/seek rendszehívásokat használja. Valószínűleg memóriában meg diszkre dolgozik, sőt lock-olni is tud. Tehát tökugyanaz.Bár nem tudom feltűnt-e, hogy senki nem ugrott nekem, hogy a 30M mentett álomány semmiség, mert az ő rendszere még ennél is többet tud tárolni, sőt nála sincsen semilyen performance gond, miközben 128 helyről 12 féle állomány ment garantált időn belül. Szóval csak van valami, amit nem pont úgy csinálok. ;) Tehát a ez az izé valami teljesen más, mint egy sql szerver. (Az sql szerver csak kiragadott példa!)

VAN a rendszerben sql is, amibe gyakorlatilag az index kerül bele mégegyszer: 1db gyűjtemény=1 sor.
Ezt jól le lehet kérdezni a webes programozóknak. ;)
Komolyan elmagyarázzam? Az sql szerver leállítása esetén is működik minden. Az sql csak azért van, hogy a web interfész (a rendszer <1%-a funkcióban) programozói jobban érezzék magukat. Ezen kívül tartalmazza az egyes munkaterületek konfigurációját, amit egy szkripttel lekérdezek (egyszer az életben), és a saját formátumra alakítom. A konfigurációs felület - amihez semmi közöm - már egy jó ideje nem működik. Ebből is látszik, milyen nékülözhetetlen eleme a teljes rendszernek. :D
Ráadásul egy fájl begyűjtése, megcsócsálása alatt átlagosan be sem tudom jegyezni az sql-be az egy sor indexet, avagy logot. Azaz a rendszer lényegesen gyorsabban dolgozik, mint az sql szerver. Bármilyen feledatra használnám, mindig várakozni kellene.

Ééés itt az utolsó tőrdöfés: Mindez egy Core i3, 4GB memória és 14TB bruttó (8db) diszken megy.

"Hiszen az sql szerver is ugyanazt az open/close/read/write/seek rendszehívásokat használja. Valószínűleg memóriában meg diszkre dolgozik, sőt lock-olni is tud. Tehát tökugyanaz"

Azert ennyire ne legyel mar hulye. A felvezetesed alapjan en is azt hittem, hogy valami nagyon egyedi formatumot hasznalsz, de kiderult, hogy tar+gz az egesz, ebben aztan semmi egyedi nincs. Nem az a problema, hogy ezt hasznalod, mind a ket formatum regota bizonyit, robosztus, agyontesztelt, csak ne add elo magadat.

"Ráadásul egy fájl begyűjtése, megcsócsálása alatt átlagosan be sem tudom jegyezni az sql-be az egy sor indexet, avagy logot. Azaz a rendszer lényegesen gyorsabban dolgozik, mint az sql szerver. Bármilyen feledatra használnám, mindig várakozni kellene"

Ajanlom neked olvasmanykent a messaging rendszerek mukodeset, es a mikroszervizes architektura felepitesenek megvizsgalasat. Hint: NEM kell varakozni.
--
Blog | @hron84
Üzemeltető macik

Nem is tar+gz, csak gz konténer. A formátum nem egyedi, de ezek szerint elismerted, hogy nem rossz.
Nem hiszem, hogy hasonló megoldást láttál volna - ezért egyedi.
Valószínűleg nem látod át a feladat nagyságát. Ezért azt gondolod, hogy bárhogyan könnyedén meg lehetne oldani.
mikroszervizes architektura
Alacsony növésű szerelőkre gondolsz? :D
Remélem fájt!

Nem mondtam, hogy várakozni kell. Csak kelleNE, ha az sql szerverre bíznék bármit.
Komolyan mondom, nem értem mire gondolsz. Az adatgyűjtés tranzakcióit nem az adatbázis kezeli, mert lassú. Ezalatt pontosan azt értem, hogy mialatt begyűjtök, ellenőrzök és mondjuk konténerbe helyezek 4500 fájlt, azalatt az adatbázisba legfeljebb 1500 sort tudok beírni. Egy-egy fájl begyűjtése/ellenőrzése/konténerbe helyezése 4-5 lépésből áll, ami szintén tranzakció. Ezeket már végképp nem bírná elviselni az adatbázis.

Szóval ehhez miért kellene bármilyen üzenetet kezelni? Elég két cache. Az egyeket feldolgozza az adatbázis, a másikba ír a rendszer, aztán cserélünk.

Némi érzelmi töltéssel fűszerezve tőlem az adatbázist leállíthatod, felrobbanthatod stb., de ezzel a működést nem tudod befolyásolni. Pont ez a lényeg, hogy az operációs rendszeren kívül (ami nem csak linux lehet) semilyen függőség nincs. Minek kellene egyéb elemeket belekeverni?

Hidd el, nem mondál semmi újat! Dolgoztam már tizenéve is pl. SOAP, MQ Series környezetben. Ponosan tudom miről beszélsz (el is olvastam), és pont a Mikroszervíz architektúra az, amire itt nincs szükség. Ez csak egy backup rendszer néhány apróbb extrával.

Biztosan én nem tudom mi az a FAT, bár ha bájtokat lehet tárolni vele, akkor talán hasonlít. ;) Bár úgy gondolom, teljesen másképp működik. Hiszen, ha ugyanígy működne, akkor nem lenne lassabb.
Mekkora ötlet! Egyszer kipróbálom loop-ra, aztán appendálok hozzá valamit. :D
Az az érzésem, egy-egy kiragadott szó mellett nem igazán látod át a rendszert. Ezzel más is így van, talán éppen ezért vagyok gyorsabb.

Nem értem mi a problémád ezekkel a nyelvekkel. Ha minimum Java lenne, akkor csendben maradtál volna?
De komolyan!

A nyelvekkel semmi problémám. Csak éppen egy filetárolásra szolgáló dologra lehet írni: kernel drivert, FUSE drivert, ezernyi más dolgot, de nem, oldjuk meg gányolással és legyünk rá büszkék. Hát, én nem lennék rá büszke, mert baromira nem mérnöki megoldás. Gányolás ezerrel.

Mázsás kő gördült le a keblemről, hogy nem a "java biztonságos" szlogennel szórakoztattál! ;)
Ok, nem mérnöki megoldás.
Lécilécci meséld már el, hogy egy gzip stream-re milyen filesystem passzol.
Úgy mérnökileg. ;)

Mellékesen megemlíteném, hogy ez a tárolási formátum eléggé szabványosnak mondható. Ha valami újat találnék fel, akkor meg az lenne a baj.

Ezek pusztán kommunikációs protokollok, abszolút nem garancia az, hogy a bennük átvitt adatok bármilyen szabványnak megfelelnek és azok tárolása bármilyen szabványnak megfelel.

Ez most nagyjából olyan, mintha a beérkező iratokat iktatás gyanánt papírgalacsinba gyűrve valamilyen saját szabályrendszer szerint a hátad mögé dobnád, majd arra a kérdésre, hogy ez amúgy melyik iktatási szabványnak felel meg, annyit válaszolnál flegmán, hogy a postai borítékon a címzés szabványos volt...

A rendszered szempontjából mindegyik kommunikációs protokoll, mert nem implementálod ezeket, hanem felhasználod, hogy beszélj egy meglévő rendszerrel.

Attól nem lesz _szabványos_ a rendszered, hogy _használ_ szabványos megoldásokat. Attól lesz szabványos a rendszered, ha _implementál_ szabványokat vagy iparági megoldásokat.

Tehát, ha ez a backup rendszer a gzip program futtatásával állít elő szabványos gzip formátumot, akkor csak használom.
Viszont, ha a rendszert megírom egy nagy spagettikódba, azaz implementálom benne a gzip formátum előállítását, akkor szabványos lesz, mert nem csak használtam.
Világos!
Ez az első esetben kommunikációs protokoll, míg a másodikban szabvány implemetáció.
Értem!

Engedd meg, hogy felttételezzem: Nem az általad idézett szabvány az egyetlen és egyedülálló és potolhatatlan stb. adattárolás a világon!
Ha eddig eljutottunk, még abban is állapodjunk meg, ha pl. nincs soap, akkor is beszélhetünk még valamiről!

Először nem teljesen úgy értettem a "szabványost", ahogy gondoltad (ez még körül is van írva a hozzászólásomban), de elolvasván az Abstract-ot rájöttem valamire. Minek kontent menedzser egy kenyérpirítóra, ha nem az? ;) Ez a rendszer még ezen fogalmak szerint is szabványos.
Ha eltávolítod az összes szoftvert, az adatok tárolása akkor is szabványos.
Ha browser csatlakozik hozzá akkor is szabványos, megfelel az fenti rcf-kben leírt adatformátumoknak.
Talán kivétel (ez csak példa), hogy egy lekérdezést bele lehetne ültetni egy soap héjba, de erre nem volt igény. Ha megtettem volna, akkor akár beszélhetnénk a kontent menedzser interfész részleges implementációjáról. No, meg örülnénk is, csak mindössze egy a hiba: Ez nem kontent menedzser. Ebből a nézetből egy teljesen más célú kötött rendszer.

A lefontosabb a gzip, amire úgy 1994-5 körül váltottunk. Pontosan akkor amikor már volt PC DOS alá is bináris.

"No, meg örülnénk is, csak mindössze egy a hiba: Ez nem kontent menedzser."

Ami úgy néz ki, mint egy CM, úgy viselkedik, mint egy CM, az egy CM. Ha tetszik, ha nem.

"Ez a rendszer még ezen fogalmak szerint is szabványos. Ha eltávolítod az összes szoftvert, az adatok tárolása akkor is szabványos."

Nem, semmi szabványos nincs az adatok tárolásában, se a kommunikációban, se az interfészekben, se az architektúrában. Semmi. Szabványos eszközöket _is_ használsz, azokból sem túl sokat és túl jól... annak sok értelme nincs, hogy szabványosított kalapáccsal ütöd be a csavarokat... nem implementálsz szabványokat, helyette jön a folyamatos bullshit, hogy mennyire egyedi és megismételhetetlenül összetett, ugyanakkor pedig mennyire végtelenül egyszerű és korszakalkotó. Közben pedig dehogy, az egész egy custom megoldás, csak azért, mert nincs túl sok affinitásod se az adatbázisok kezeléséhez, se a szabványos interfészek használatához...

( _Franko_ v | 2017. 02. 22., sze – 10:41 )

"Hogy megelozzem az felveteseket: a virusirto beallitasait nem fogjak megvaltoztatni a kedvemert. Gyorsabb merevlemezt se osztanak. A project celja az, hogy a csapatunkban a kollegak kellemesebb korulmenyek kozott fejleszthessenek."

Ööö... izé... ilyenkor ott kell hagyni a helyet a picsába.

Itt most ebben a fórumban rászántunk a problémára, a megoldásra és a vélemények ütköztetésére 250 hozzászólást, ami ránézésre három embernapnyi munka, az a legolcsóbb mérnöki óradíjjal is simán van 100-150 ezer forint, ennyit megtakarítottunk az adott cégnek. Ne legyél már annyira lojális, hogy ha már aktívan akadályoznak a munkádban, mert az üzemeltetésnek és a gazdasági területnek úgy sokkal kényelmesebb és olcsóbb, akkor még ennek ellenére magadra veszed a helyzet fusiban való megoldását is... széllel szemben nem lehet hugyozni, csak szarni...

Ugye ez meg mindig egy kenyelmi szempont (ugyanis a "kollegak" unjak, hogy lassan listaz az explorer:)

Itt a kerdeto leginkabb egy magic keyt szeretett volna (registry bejegyzes formajaban lehetoleg) amitol az explorer megtaltosodik...:)

Igazabol a legbanalisabb megoldas neha a legjobb: far managert probaltak mar? Az gyorsan listaz...

Egyebkent szellel szemben vigyazni kell, allekonysagtol fugg...;-)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Noha alapvetően én is így gondolom, de hol lett az leírva a *kérdező* *által*, hogy tényleg az a problémaforrás, hogy a pár százezer fájlt tartalmazó könyvtárak lassan listázódnak? (Mármint hogy ők ezt érzik bajnak.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"egy alkalmatlan rendszer, ésszerűtlenül használva, tervezés nélkül."

En nem itelkeznek ilyen gyorsan. Az, hogy Windows 7 kerult felhasznalasra, siman lehet adottsag is, ha a feldolgozo szoftver nem fut mason (van olyan cucc, ami Windows Server verzion el se indul, csak nagy ganyolasok aran). A mappaba valo kihanyas szinten lehet egy adottsag.
--
Blog | @hron84
Üzemeltető macik

Hatrany, de akar olyan hatrany is lehet, amivel nem lehet mit kezdeni, mert maga a rendszer tizensok eve lett fejlesztve, amikor mindezek a szempontok nem hogy fontosak nem voltak, nem is leteztek.

Amire ra akartam vilagitani: ha ez nem elbokes eredmenye, hanem adottsag, akkor vajmi kevesse lehet a mostani uzemeltetest/fejlesztest felelosse tenni a korabbi dontesek hibaiert. Erre probaltam utalni azzal, hogy ne itelkezz elhamarkodottan.
--
Blog | @hron84
Üzemeltető macik

Nem tudom, hogy az-e. De mivel nincs sem pro sem kontra bizonyitekunk erre vonatkozoan, nem lehet kizarni ezt a lehetoseget sem. De eleve, regi vagy pusztan csak oroklott rendszernel nem fair a mostani fejlesztoket/uzemeltetoket hibaztatni a regebben elkovetett hibakert. Igen, valaki valahol hibazott, de ez mara mar adottsagga valt, ezzel kell egyutt elni es tervezni. Tudod, mint a korrupcio itthon.
--
Blog | @hron84
Üzemeltető macik

A korrupció az renben van. Azaz dehogy! ;)
Szóval elismerted, hogy csak feltételeztél. Ezt nem rovom fel hibának, hiszen én is csak zsigerből utasítottam el a windows-t.
Ebben az esetben engedd meg, hogy én is - hosszú, alapos tapasztalat birtokában ;) - feltételezzek!
Itt egy saját fejlesztésű rendszerről van szó. Nem akarok kirekesztő, rasszista, stb. lenni, sőt nem tartok mindenkit hülyének sem. DE! Láttam már "saját fejlesztésű" programokat, meg windows programozókat is. Szakmailag és a józan ész szerint az lenne a szbály, hogy fel kell mérni a foltozgatás vs. újratervezés várható eredményét. Ebben az esetben inkább arra hajlok, hogy dilettáns munkáról lehet szó, és már egy "féldilettáns" megoldás is jobb eredményt adna.

"Itt egy saját fejlesztésű rendszerről van szó."

Vagy egy olyanrol, amit egy beszallitoval fejlesztettettek le, amely beszallito mar nincsen.

Az ujratervezessel megint az a baj, hogy nem tudjuk, valojaban
1) mit csinal a program
2) megvan-e jelenleg a cegnel az a fajta tudas, ami a szoftver javitasahoz/ujramegalkotasahoz szukseges

--
Blog | @hron84
Üzemeltető macik

( sigellef | 2017. 02. 22., sze – 15:16 )

Egy nagy fájlt hizlalni, meg dolgozni egy nagy fájlon, nem hiszem hogy kényelmesebb, mint a sok apró fájl. Még mindig jobb az ésszerűen elnevezett fájlokat ésszerűen strukturált könyvtárszerkezetbe rendezni. A gányolt adatmennyiség adatbázisfájlba pakolva is gányolt adatmennyiség marad. Mégjobb, ha jön egy szektorhiba az adattárolón, és a 100GByte-os adatbázisfájl megy a kukába.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( hrgy84 | 2017. 02. 22., sze – 16:06 )

En ilyenkor keritenek sort egy meetingre az IT vezetovel, a rendszergazdaval es a CEO-val, es vazolnam fel a fennallo helyzetet, illetve azt, hogy az adott megkotesek menten ezt a problemat esszeruen megoldani nem lehet. A kovetkezo megoldasok jonnek szoba:

- Ha lehetseges, modositani a fajlokat foso appot, hogy ne fosson fajlokat, vagy strukturalt formaban tegye ezt
- Fejlesztessel (nem kevessel) elo lehet allitani egy olyan webes alapu rendszert, ahol a kepekrol/videokrol keszul egy tok masik, fuggetlen rendszren egy preview, maga a digitalis szemethalom csak a webszerverre van felcsatolva, es amikor kell, akkor veszi elo konkretan azt az egy fajlt, amire szukseg van. Ha minden kotel szakad, PHP-ban egy ilyen rendszer - megfelelo tudas mellett - ket-harom het alatt osszerakhato.
- A penzes megoldas meg az, hogy az egeszet valami ertelmesebb storage-ra kikoltoztetni, aminek ertekelheto sebessege is van, nem manok hordjak benne a biteket.

Mindettol fuggetlenul a virusirto beallitasait modositani kell, nem a ket szep szemedert, hanem azert, mert ha egy eszkoz akadalyozza a munkavegzest, akkor azt vagy ki kell dobni, vagy moresre kell tanitani.
--
Blog | @hron84
Üzemeltető macik