Sziasztok!
Hosszabb távon tervezés céljából gyűjtögetek információt, ki mit hallott-látott ebben a témakörben.
A problémakör röviden: Adott nagyságrendileg 20-25TB adat, ami sok-sok kis fájlból áll össze. A fájlok mérete a párszáz Kb-tól mondjuk 20-30Mb-ig terjed. Számosságukat tekintve ebben a pillanatban 33 millió fájlról beszélünk. Ez a mennyiség okos könyvtárstruktúrával még a kezelhető szinten mozog, de a jövőben ez nőni fog és már most is hatalmas gondot okoz egy-egy fsck, netán egy fs hiba. Úgy fogalmaznék, hogy kockázati tényezőt látok az FS alapú tárolásban lassan. Még amellett is, hogy az említett fájlrendszert kvázi replikáljuk, tehát egy 2 napos fsck esetén be tud állni a replika kiszolgálni az éles rendszereket.
Ezeket a fájlokat jelenleg http-n szolgáljuk ki (internal), úgy h. az alkalmazás tudja mit kell letöltsön egy index DB alapján.
Olyan megoldást keresek vagy képzelek el, ami:
- DB szerű (MongoDB pl?), nem fájl szinten érhető el, nem 33m fájlban tárol
- Elosztottan tárol (Nem szeretnék azért egy 30TB-os blob-ot, mert ugyanaz a veszélye mint a jelenlegi megoldásnak
- Illeszthető könnyen JAVA környezetbe, tehát van hozzá official konnektor, semmi tákolás. Az sem hátrány ha más nyelvekhez van hozzá illesztés, pl. Python/PHP
- Optimális esetben akár FS szinten is leképezhető, de ettől el tudok tekinteni, ha jó kliensek léteznek hozzá
- Replikálható (master-slave módon elégséges, de ha van jobb az sem hátrány)
- Esetleg a "blobokon" kívül meta adatokat is képes tárolni, így a fájlokból néhány adatot akár előre ki is nyerhetünk és kereshetővé válhatnak meta adat szerint is, plusz ezzel kiszedhető lehetne a mostani DB réteg.
- Az adatelérés lehetőség szerint legyen gyors, de az adatok betöltése nem túl komoly performanciával történik, ezért jelenleg is RAID6 NL-SAS-on van a cucc
Köszönöm h. végigolvastad, hátha lesznek jó tippek :)
Zoli
Hozzászólások
Bármelyik elosztott fájlrendszer, object store vagy block store jó erre, ne adatbázisban gondolkodj, hacsak nem ad az adatbázis olyan plusz feature-t, ami amúgy is kellene.
Szóval: Ceph, GlusterFS, MinIO, Longhorn, Rook és társai. Mind kicsit másképp működik, érdemes megnézni a workload-ot, hogy melyik a legjobb neked.
https://iotguru.cloud
Ez már nem SOHO hanem inkább SME kategória szerintem. Büdzsét és megoldást (szoftver és hardver) is így kellene keresni hozzá.
Gábriel Ákos
Ez szerintem hozzáállás és pénz kérdése, nem pedig méretfüggő dolog...
https://iotguru.cloud
Alapvetően egyetértek. Szerintem van egy méret ami kijelöli a soho tetejét, ez pedig szerintem kb az.
Az SME alja pedig ez alatt kezdődik, igazából bármilyen kicsi dolgot lehet SME hozzáállással kezelni (csak nem gazdaságos).
Gábriel Ákos
A thread-re válaszolva: A CEPH ebben a méretben nem túl gazdaságos és nem is túl gyors, azt elvetettem már a saját tapasztalataim alapján. Elég sok node kellene hozzá hogy "megérje".
Alapvetően igen, belenylunk az SME-be és nem is annyira a pénz a kérdés, sokkal inkább az h. felesleges hülyeségre ne költsük el, ezért gondoltam h. mielőtt bármiben is elkezdek gondolkodni, körbejárom a kérdést alaposabban. A jelenlegi megoldással sincs tulajdonképpen baj, csak hosszabb távon szeretnék valami olyat ami megbízhatóbb, skálázhatóbb is és persze _esetleg_ a DB-t is kiváltja valamilyen formában.
Ezért írtam a többit is, hogy érdemes megnézni többet és a workload függvényében választani egyet. CEPH lehet akár erre is megoldás, de nyilván te tudod a részleteket.
Egy object store abban tud segíteni, hogy nem lesz több tízmillió apró fájl, hanem csak néhány nagy és agyonverhetetlen: erre vannak kitenyésztve, erre érdemes használni őket.
https://iotguru.cloud
A CEPH-nek kb hol van az optimuma? (Sebességben)
Nem 2 node-nál :)
A saját tapasztalat az h. 12 full ssd szervernél már egész tűrhető. De még az is egy kicsike setup, 3-as replikával pl.
És természetesen 10G bonding linkekkel, stb.stb. A network is egy horror volt hozzá 4-5 éve.
4 szerver, 1Gbit belső háló, HDD, relatíve alacsony terheléssel (kisebb fájlok írogatása időnként) szopóroller?
Az, a HDD es a Gbit miatt is. Ha csak object storenak kell (tehat nem VMeket raksz ra), "jatszos", es esetleg raksz ele egy varnish-t, akkor kiprobalhatod, de sok jora ne szamits.
4 szervert futtatok prodban NVMe-vel es 25Gbitel, ez onmagaban nem ordogtol valo, kis elore tervezes, es semmi gond vele.
Egyébként miért kell a CEPH alá vastag háló? Ha a user mittomén szerkeszt egy 2 MB-os fájlt, akkor pontosan mi az a magic, ami miatt 1G-s háló nem elég ezt a módosítást syncelni a node-ok között?
Ha nem mission critical és ráérsz várni, akkor nem kell. Akkor kell, ha kell a nagy sávszélesség és alacsony latency.
https://iotguru.cloud
Ha ez a usecase, hogy egy user szerkeszt egy 2MBos fajlt, es raer, akkor ahogy _Franko_ mondja, eleg. Ezert mondtam, ha csak object storenak akarod hasznalni jatszosba, akkor probald ki. Ha mindezt VM-ek ala akarod hasznalni, akkor mar keserves elmeny lesz az egesz, mert nem egy irast akarsz lekuldeni egy db UPDATEnel, egy apt upgrade-nel, stb., hanem sok sok kicsit. Minden egyes irasnal osszeadodnak a stacked latency-i es mire visszakapod az irast a VM-be kiteped a hajad. Ezekbol a retegekbol a halozatra van befolyasod, meg a diszk sebessegere, ezeken kell javitanod, a ceph kod meg olyan amilyen, azzal nem tudsz mit csinalni:D
Es akkor arrol nem is beszeltunk, hogy ha rebalanceolni kell, akkor hogy fog beallni az egesz HDD-vel meg Gbit-tel, nem rossz lesz, hanem konkretan allni fogni minden I/O.
10G FC-n nem csak a sávod nagyobb, hanem 1 nagyságrenddel kisebb a latencyd. Az számít CEPH-nél.
Rebalance.
Egyik node ideiglenes kiesése után mennyi ideig tömi ki az I/O-t és a node-ok közti sávszélességet adminisztrációs okokból
Én azt mondom a Ceph - hacsak nem vagy 80-as szintű paladinokkal körbevéve - szopólroller.
Lásd még NagyZ commentjét korábban:
https://hup.hu/comment/2564829#comment-2564829
Erre a célra fel sem merült, illetve másra sem, mert nem vagyunk abban a méretben.
Többek között az említett komment is sokat elmond arról mennyire cephetül lehetsz ha ott valami elromlik :)
Ha csak object store kell, minio egy fokkal jobb egyébként, bár ott is találkoztunk annó furcsaságokkal.
Kb. 1 rack cabinet-től felfelé
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Bocs, de miért ne gondolkozzon adatbázisban? Teljesen függetlenül a fájlok darabszámától szükség lehet olyan indexértékek kezelésére, ami túlmutat a könyvtárnév-fájlnév konvención, és a fájl attribútumokon.
"hacsak nem ad az adatbázis olyan plusz feature-t, ami amúgy is kellene"
Az egyetlen ilyen requirement (kb amit te mondasz egyébként, csak ő metaadatoknak hívta) "Esetleg" szóval kezdődött :)
Így van, nem feltétel, de mindenképpen előnyös lenne ha egy "integrált" megoldást lehetne gyártani, ahol mondjuk egy ID alapján megjön a "blob", meg hozzá mondjuk 2-3 metaadat. Ugyanakkor ha ezt stabilan nem tudja semmi, akkor inkább egy jó FS alapú megoldás, ami túlmutat az ext3-on, mintsem egy olyan megoldás ami mindent tud, de mindent sz.rul :)
Nem szoktam on hand ekkora méretű blobstoreokat összerakni, de a minio pl tud metadatát tárolni a blobok mellett. Szerintem a longhorn is.
A minio fenn van a listámon nekem is, de kíváncsi voltam h. itt esetleg valaki megtalálta-e már a szent grált.
Kicsit majd jobban beleásom magam a nyáron, nem kapkodunk, nem hullik szét a mostani megoldás, de szeretnék hosszabb távra és a növekményre is felkészülni, lehetőleg úgy h. skálázható is legyen.
A minio erasure használata esetén szétdarabolja a fájlokat kis blokkokra, illetve a metaadatokat is külön fájlban tárolja az adatok mellett. A sok kicsi fájl problémán nem biztos, hogy segíteni fog.
Van egy olyan, hogy seaweedfs. Nem tudom, hogy mennyire megbízható, régebbóta fejlesztgetik, állítható méretű pár gigabyte-os fájlokban tárolja a tartalmat, a metaadatot pedig választható key-value storeban / adatbázisban. Papíron tudja az S3-at, van saját http api-ja, tud tiered storage-ot, active-active replication, van neki posix szerű fuse mountolható modulja is. Poénból meg lehet nézni, élesben nem tudom, home userként jól el lehetett vele bohóckodni.
A blob jó dolog - lehet, de a workload-tól nagyon függ. Ha döntően csak "befelé" mennek fájlok (a letöltésen kívül), és egy-egy törlés jön szembe, akkor sem a törlések, sem a logikailag törölt blobok helyének a felszabadítása nem fog jelentős gondot okozni.
Egyébként a fájlrendszer is egyfajta DB, csak nem SQL query-vel keresgélünk benne :-P Amit én láttam hasonlót, ott a DB-ben egy "pointer" (path) volt a fájlra, az összes metaadata (létrehozó, időadatok, cimkék) a DB-ben volt, a fájl meg egy méretes fájlrendszerben, ahol a feltöltés során megadott/kiválasztott cimkék alapján kerültek az új állományok elhelyezésre. Így a DB is kezelhető méretű maradt, az állományok kezelése (pl. adott "cimkéjű" állományok kimásolása) is faék egyszerű volt, ahogy a mentések, illetve - és ez is fontos volt - az anonimizált teszt/fejlesztői környezet létrehozása sem volt nagy munka: a DB dumpban a személyes adatokat kellett elmaszkolni, a fájlok helyett meg egy script a DB alapján legyártotta az "az yxz nevű állomány volt itt" tartalmú dummy állományokat.
+1 az S3 - vagy azzal kompatibilis object-store -ra, pár kérdés:
Igen, valami ilyesmi lesz a helyes irány (minio vagy hasonló, esetleg még az opensearch v. elastic).
Azért válaszolok a kérdéseidre, hátha valakinek beugrik valami egy kis konkretizálással:
Ami esetleg plusz "para", bár ahogy láttam minden object store-ból, DB-ből van lehetőség erre: ki kell tudni nyerni egy adott szűrésnek megfelelően az összes tárolt adatot fájlként (pl. 1 accounthoz tartozó összes fájl és metaadat)
Elastic -ot ilyesmire biztosan nem használnék, viszont arra megfelel hogy a metaadatokat párosítsd elérési útvonallal - Elastic üzemeltetésébe is bele kell jönni (ILM, hot-warm-cold node-ok). Elastic dokumentumokat (logfileok) tárolni jó, de a többi már szerintem nem pont Elastic terület. Lásd fórum itt.
Az már csak hab a tortán hogy Elastic license nem olcsó, nagyon nem és a support nem a leghasznosabb.
Az IOPS számokról annyit hogy a max IOPS amire szükséged van bőven belefér:
Minio
Particionálás: object key-nek a mostani megoldás teljesen jó: account/ev/honap/nap/<UUID>.mp3 - ezen nem változtatnék, kivéve ha adott account sok file-t generál egy nap.
Következő dolgoknak olvass utána: erasure coding , small files performance.
Nem derül ki a jelenlegi megoldás (milyen hardveren milyen FS-sel működik most), meg a büdzsé sem a fejlesztésre, ezt vedd figyelembe az alábbi javaslatnál.
Ha "kis" pénz-kis foci kell, akkor két szerver, ZFS alapon legalább RaidZ2 felállásban, ZFS send-receive replikálással szerintem hosszú távon jól működhet. A ZFS megoldja az FSCK-t (időszakos scrub, ha szükséges hibajavít), felismeri a hibákat chacksum alapján mindig (és javítja, ha van redundancia a pool-ban). Igazából FSCK vagy hardver hiba miatti leállással, kieséssel nem kell számolni (ha nem 7/24 a terhelés, de akkor úgysem 1+1 szerveres rendszer kell alá).
Ha (nagyobb) teljesítmény is kell, természetesen akár a RaidZ2-ket lehet stripe-olni (RAID60 jellegű kötet), vagy lehet RAID10 jellegű kötet is hot spare-rel, és mindez lehet akár SSD-ken, vagy HDD alapú kötet mellé lehet sok RAM-ot és L2ARC olvasási gyorstárat tenni. Persze minden a konkrét terheléstől függ (olvasás/írás aránya, napi adatmennyiség ki-be, stb), de ZFS-sel megvalósítható, ha nem kell osztott tárolás/elérés.
Amennyiben ez nem elég professzionális a feladatra, akkor a fentebb említett elosztott rendszerek bármelyike jó lehet, de ott masszívabb költségek lesznek a sok hardver miatt (CEPH pl. megy akár 3 host-on, de messze nem ideális semmilyen szempontból, stb.).
Nem mondanám h. kis pénz és kis foci van. Sokkal inkább az a helyzet, hogy van egy sok-sok éve működő megoldás, ami kisebb volumenhez, kevesebb szakértelemmel és -talán mondhatok ilyet is- kisebb körültekintéssel lett megcsinálva. A jelen felállás egyébként a következő:
A "fő" tároló egy VM, amire rá van kötve egy ennek az adattárnak dedikált EMC storage. A storage-ben raid6-okból van pool gyártva, ezen lakik az adat (NL-SAS, nincs cache, semmi). A VM egy LVM-ben kapja meg a block eszközről a kötetet, nincs qcow meg egyéb olyan dolgok amik ebben a méretben az öngyilkossággal lennének egyenértékűek.
A "backup" tároló egy vas, ami tele van tömve nagy NL-SAS diszkekkel, szintén RAID6-ok, LVM-el összefűzve poolba, egy VM kapja meg itt is a kötetet és tárolja rajta a fenti cucc mirrorját (éjjelente 1 rsync, prod időben lsyncd szinkronizál)
Jelenleg mintkét volume XFS, emlékeim szerint RH7 telepítővel lehetett csinálva, nem volt túlgondolva a dolog.
Teljesítmény: folyamatos, de lassú és szekvenciális írás (80-100 IOPS) + random olvasás ami lehet éppen kicsit nagyobb IO terheléssel is (150-200 IOPS), de azért ez sem olyan vészes.
Alapvetően a storage-et erre a célra nem tartom jó megoldásnak, ugyanakkor olyan esetben ha megkérdezi valaki h. hol lakik az adat, akkor lehet mondani h. EMC és akkor húú meg háá. Azt felejtjük el h. hiába van blokk szintű scrubbing pl, attól még egy FS crash és vége is mindennek, mert futhat az fsck 2 napig (ez amúgy kb. valós is)
Ha úgyis ott van az enterprise jellegű storage és a backup, akkor lehet, hogy egyszerűen csak darabolni kellene sok kis volume-ba az egészet valami shard/hash mentén... lehet, hogy randa, ha fel van csatolva 100-200 volume, de működhet. Akár úgy is, hogy nem egy VM-re van felcsatolva minden volume, hanem több kisebbre és valami faék shard/hash alapján osztódik szét a terhelés. Nyilván a SPOF a storage, de az meg azért EMC...
https://iotguru.cloud
Egyébként ha maradunk a storage vonalon, akkor akár ez a megoldás még jó is lenne, ha valamiféle rendezési elv alapján több volume-ra osztanánk a cuccot. Jelenleg a legnagyobb félelmem a 20+ TB és a 30+ millió fájl alatti fájlrendszer meghibásodása. Ha ezt lehet kezelhető szintre vinni (pl. 1 TB-os volumeok), akkor azzal egy hiba esetén gyorsan tud az üzemeltetés reagálni, nem az van h. " - mikor lesz kész?, - mittomén, még vissza van 19TB és 25m fájl".
Kicsit azt az analógiát látom ebben is, mint a raid + pool koncepcióban. Kisebb raid6-okból építünk nagy poolt, mert nem gáz h. 80TB a pool, de a resync idő ne legyen már 3 hét.
Ugyanakkor az h. a storage mennyire szolgálja a céljainkat, az jó kérdés. Hosszabb távon elképzelhető, hogy a fent már leírt "backup" gépet messzebb vinném, ezen a ponton meg akkor vagy storage alapú replikációban gondolkodnék, ami horror árban van, vagy akkor elegánsabb lenne 2 fizikai vas kitömve diszkekkel és ZFS-el replikálódni. Amin akár lehet OpenSearch is, meg akár valami blob store is mint "alkalmazás réteg".
...nem látom a külömbséget egy db 25TB-s volume fsck ideje és 25db 1TB-s volume fsck ideje között... Hiba esetén nagy valószínűséggel minden volume-on fsck kell..
Egyébként xfs alap esetben, ha nem volt clean umount, nem csinál full fsck-t, csak egy journal replay-t ami elvileg elég gyorsan megvan.
Mar miert kellene hiba eseten minden volume-on fsck?
Ha van 1 gepem amiben eldurran a tap akkor megall a gep, ha van 25 gepem es 1-ben eldurran a tap akkor a masik 24-et nem kell javitani.
Ha van tetszőleges darabszámú szerverem, amiből egyben eldurran egy táp, akkor jön a riasztás, hogy van egy döglött táp, és az épp "illetékes" bemegy, leveszi a polcról a tartalék tápegységet, döglött táp ki, új táp be, megyünk tovább, kiesés nélkül. Dupla táp nélküli gépre nem bíznék kritikus rendelkezésre állású, fontos adatokat. Bár láttam már olyat, hogy dupla tápos HP szerver, szólt, hogy az egyik táp rossz, bementem, cseréltem, és az új tápra is azt mondta, hogy hibás. Szerencsére volt lehetőség leállni, akkor szépen ki is derült, hogy nem a tápegység, hanem az alaplap a hibás... Az más kérdés, hogy service tag/sorozatszám alapján cserealkatrésszel érkező HP-s csóka egy egy socketes alaplapot hozott elsőre, miközben a gépben két CPU volt...
hol van itt 25 gép?
Arról van szó, hogy a storage-on levő 1db 20+ terás volume-ot felszabdalja 20+db 1 terásra, és úgy mountolja fel az 1db szerverre.
Ha az az 1 valami miatt hanyattesik, akkor jó eséllyel mind a 25 fsck lesz. Ha a storage esik hanyatt, akkor detto.
Nem láttam semmi utalást 25 külön gépre.
Nem kell 25 gép. Ha van egy gépen 25 fájlrendszered és épp csak egy fájlrendszerbe írt épp rosszul, amikor megdöglött a gép, akkor lesz 24 fájlrendszered, amelyik kb. azonnal online és lesz egy, amin végigfut az fsck x idő alatt. A másik opció meg az, hogy lesz 1 fájlrendszered, amin 25x ideig tart az fsck.
https://iotguru.cloud
A peldat probaltam egyszerusiteni a gep+tapegyseg komboval.
Alapvetően azt a kockázatot osztod el például 25 részre, hogy komolyabban megsérül a fájlrendszer és egy full offline fsck kell a helyrehozásához. Ha elő is fordul ilyen, akkor nem lesz mind a 25 fájlrendszeren és csak egy shard/hash tartomány fog kiesni. Ha pedig elő is fordul mind a 25 fájlrendszeren, akkor nem kell egyben megvárni egy full offline fsck idejét, hanem egyesével jönnek vissza üzembe a fájlrendszerek és lesz azért részleges szolgáltatásod. Ha pedig kiesik egy fájlrendszer és mentésből kell visszatenni, akkor is csak egy esik ki a 25 fájlrendszerből.
https://iotguru.cloud
Van. Ami nem lenne az a plusz performance, mert a storage tudja amit tud, es neki mindegy, altalaban, hogy 1 nagy vagy 100 kicsit szolgal ki. Legalabbis ha nem valami 20 eves cucc.
Nem rajongok erte, de ZFS lehet jo megaoldas es gyors is ha jol osszerakod.
Mindenkeppen SSD es L2 nek meg pcie s ssd. Azzal kihuzod egy ideig, Memoriat nem mondom, mert az termeszetes, hogy sok, meg meg egy kicsi.
Every single person is a fool, insane, a failure, or a bad person to at least ten people.
Ha csak 1 kisebb FS sérül meg valamilyen oknál fogva, akkor gyorsabban tudok szolgáltatást helyreállítani.
Ezen felül nem is attól félek h. mondjuk áramszünet meg hasonlók, inkább valami bármi bug, kernel crash, akármi. Úgy fogalmaznék h. láttam én már sok szépet, a 4diszkes raid6-ból egyszerre kihaló 2 diszktől a korai (igen, dev) ext4 fura eltűnt fájlokon át mindenféle jót :)
Nem a világot szeretném megváltani, a kockázat minimalizálása és a skálázhatóság a fő célom.
Ha LVM, akkor en keszitenek egy LV-t, a neve "a". Beleraknam az osszes "a" -val kezdodo allomanyt, es bemountolnam a /cucc/a utvonalra. Aztan jonne a "b", a "c", es igy tovabb. Alig 30 LV es kezdo alkonyvtar nem olyan csunya, es maris csak 30 -ad akkora az egyes volumenek merete, es esetleges fsck ideje.
Persze nem tudom a fileok nevkonvekciojat, szoval lehet, hogy mellelovok, de en igy allnek neki. Igazabol meg ezer dolgon mulhat, hogy mi a jo megoldas, ez most a legegyszerubb megoldas, nem pedig a legjobb. :-)
A névkészítésre egy jó megoldás, ha a metaadatok kriptó hashjét használjuk fájlnévnek. Ez hivatalból egyenletesen kell hogy elossza a névtérben a fájlokat. Amikor ilyet programozunk felmerül a kérdés, hogy kell-e kezelni a névütközést? :-)
Végigolvasva minden kommentet és információt, én kitartok a ZFS-es, fájl alapú tárolási javaslatomnál. Az, hogy mellé milyen módon tárolod a metaadatot, az a fájlok tárolásától teljesen független kérdés, az eddigiek alapján. Ráadásul ha marad a fájl alapú tárolás, az input oldalon nem kell alapjaiban új rendszert bevezetni, max kiegészíteni a metaadat felvitelével.
Az említett terhelés valóban elég csekély. Ha veszek mondjuk egy olyan ZFS pool-t, ami 2 db RaidZ2 VDEV-ből áll, egy VDEV 6x 8 TB-os sima NLSAS HDD-ből áll, akkor az kb. 200-350 IOPS írást és kb. 1000 IOPS olvasást tud, ~50 TB hasznos kapacitással. Mindez befér egy 2U 12 LFF szerverbe. Persze ha lehet nagyobb dobozban gondolkodni, akkor több VDEV-et mondanék a pool-ba és akkor magasabb írási IOPS-el lehet gazdálkodni (olvasásnál már a 12 diszk is eleget ad).
Ha teljesen random az olvasás, és nem valószínű, hogy egy beolvasott fájl hamarosan újra kelleni fog, akkor nem kell irtózat RAM sem meg L2ARC sem (ugyanis minek gyorsítjuk azt, ami egyszer kellett csak a héten/hónapban...).
Ha a két gép között 10G kapcsolat van, akkor egy 5 perces inkrementális replikáció pár másodperc lesz (ilyen írási tempó mellett túl nagy változás nem lesz 5 perc alatt). Ha a "forrás" gépen még ezen felül készítesz X percenként/óránként/naponként snapshot-okat, akkor a fájlok OS szintű elrontása ellen már védekeztél is (beleértve az user szintű elrontást), a memória, diszk hardverhibát (bitrot, meghalás) pedig kivédi a scrub/checksum és a RaidZ2. A replikáció során ezek a snapshot-ok is átmennek. Aztán az döntés kérdése, hogy meddig maradjanak meg a snapshot-ok (ha nem változnak az állományok, akkor kb. "örökre" is ott maradhat).
A méretekkel nem lesz gond, mert 25 TB ZFS léptékkel semmiség, egyetlen könyvtárban pedig 2^48 file lehet (szóval ha mindnek más a neve, nem is kellene szétszedni az FS miatt... :-D ), stb.
Már csak egy jó szalagos mentés kellene mellé (mert a felhős ilyen volumenben drága és lassú szerintem). Ráadásul nem is kellene Ultrium 8 meg ilyen drágaságok, mert a meglévő adatot ki lehet írni induláskor X szalagra, aztán ami jön új, mindig egy-egy újabb szalagra. A szalagot monduk naponta egyszer tovább írva az aznapi terméssel, míg tele nem lesz. Az elmondásod alapján az adat nem változik, szóval szalag rotálással meg ilyenekkel nem kell bajlódni.
Én is ZFS-raid-del mennék neki ennek, ezen a szinten, ilyen rengeteg fájlnál van értelme.
Amit még írnék a kollégának: maguk a fájlrendszerek is DB alapon mennek. DB-szerűen tárolnak, táblákban, inode-okban, naplókban. Berakni a fájlokat egy adatbázisba, az kb. olyan, hogy újra feltalálja valaki a kereket. Ráadásul nem lesz gyorsabb, csak lesz még egy réteg, még plusz overhead, és épp úgy lesz szopás, teljesítményvesztés valahol, csak akkor legfeljebb nem az fsck-nál, hanem máshogy. Ezt ennyi adatnál, fájlnál lehetetlen megúszni, akárhogy lehet cselezni. Ha a fájlrendszerek alatt lassú a teljesítmény, akkor lassú, akkor a tárolókat kell lecserélni (pl. HDD-SSD csere), vagy a vezérlőt (SATA-NVMe), vagy akár az egész gépet, ha a bottleneck máshol lenne. Ja, drága, de ha tényleg fontos az az adat, tényleg annyi usernek 33 millió fájlja, akkor szépen fizessék meg az infrastruktúra árát.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
És ha jobban belegondolsz
- van a relációs adatbázis, például SQL
- alatta a célorientált adatbázis (fájlrendszer)
Ha a valamelyikünk fél a fájlrendszer hibájától, akkor miért nem fél a fájlrendszer feletti SQL-ben levő adathibától?
Nem mindegy, hogy a CAP-ból melyik fontosabb a C vagy az A? :)
Nem kötelező a plusz egy réteg: egy csomó DB motornál a tablespace-t rá lehet tenni nyers partícióra is, azaz nincs FS alatta. IBM DB2 LUW-ot használtunk így. Mellesleg nem volt nagy a teljesítmény-nyereség...
Ez igaz, erre nem gondoltam, hogy Linux, BSD, stb. alatt lehet bármit közvetlenül az eszközre is pakolni, nyers adatformában, nem kell partícióra és/vagy fájlrendszerre tenni. De Windowsnál ebben nem vagyok biztos, hogy lehetőség.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
> Berakni a fájlokat egy adatbázisba, az kb. olyan, hogy újra feltalálja valaki a kereket.
+1 az első pillanattól bizsergett az ujjam, hogy ezt írjam: sok fájl tárolása? Hmmm, hadd gondolkodjak! Megvan! Erre találták ki a fájlrendszereket! Csak azért nem írtam, mert valójában semmi tapasztalatom nincsen ilyen sok fájllal, úgyhogy igazából nem tudom csak sejtem.
En inkabb egy documentstore-ba raknam plane ha metaadatokat is kell tarolni (elasticsearch, opensearch, etc) a 33 millio darab documentum az meg sem fog kottyanni, az adat tarolasaert meg ugyannyit kell fizetni, bar ha plusz egy replica can akkor az dupla annyi. De az adat is kezelheto szepen distributivan5-6 node-on szepen. Illetve milyen az elerese az adatnak? Van cold, hot stb? Foleg iras vagy inkabb olvasas?
Elastic-ban csomo indexeles kikapcsolhato igy sokkal tobb adatot nem fog foglalni mint a nyers adat.
Az elastic store-ja alá is kell valami filerendszer.
Mondjuk egy 3 node-os cluster legalább 1 replikával lehet hogy már elég jó.
Az elastic amúgy nagyon jó, szinte agyoncsaphatatlan.
Gábriel Ákos
Elasticsearch nem bináris adatokra van kitalálva. Arra viszont nagyon jó lehet, hogy metaadat store legyen és mutasson egy BLOB store felé...
https://iotguru.cloud
Igen, de egy ilyen setupban mi lenne az ideális BLOB store? Mert a OpenSearch nekem is eszembe jutott már, de én azért ódzkodom, mert itt tényleg egy nagy kupac nem szöveges adatról beszélünk. Hogy kicsit konkretizáljam, MP3 a formátum. Mielőtt valaki megkérdi (ha olvassa valami troll :) ), a rendszerben keletkezett anyagról van szó, nem kalózmásolatokat akarok nagy mennyiségben tárolni.
ja ha mp3 akkor nem document store :D
Bar lehet azt is tarolni benne, sot taroltunk is bene (pdf, de tenyleg barmi, sot irhatsz hozza sajat ingest plugin-t, ami szepen felparzolja neked az mp3 metaadatokat).
De ha mas nem kell csak egy agyonuthetetlen distributed filerendszer amit java-ban is le tudsz kerdezni, akkor is jo.
Amugy pedig tenyleg jo lehet barmelyik distributed filesystem ami tud blob-ot is es nem csak blockstore-t. Irtak parat mar elottem.
Nézőpont kérdése, idv3-ba be tudnánk ágyazni a metaadatokat és hasonló agymenéseink már voltak, onnantól meg olyan lenne mint egy kis dokumentum egy nagy csatolmánnyal/inline képpel :D
De igen, valami object store v. valami FS közelebb van a dologhoz egy meta DB-vel.
Sokat fogom én még ezt rajzolgatni, mire kitaláljuk h. melyik a legjobb setup nekünk, pláne h. flexibilitás is kellene, ha pl. később szétválasztjuk a két szervert 2 site-ra (előbb utóbb úgyis muszáj lesz)
Ha egy-egy könyvtárban nincs túl sok fájl, akkor nincs különösebb aggódni való. (Közismert módszer: a kakukkfu.txt a k/ka/kak/kaku/kakuk/kakukk/kakukkf/kakukkfu könyvtárba kerül.)
Nekem a Hadoop villant be, de valószínűleg léteznek jobb megoldások is, vagy nincs szükségetek ekkora ágyúra.
Mongodbvel nem fog menni, abban 16MB a dokument méret hard limit.
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
És nem is bináris adatokra tárolására van kitalálva...
https://iotguru.cloud
De, fog menni: https://www.mongodb.com/developer/products/mongodb/storing-large-object…
Ettol fuggetlenul mindenkeppen csinalnek egy eles probat, akarmit is valasztasz. Mongo elonye lenne, hogy kevesebb 'moving part' van benne: a metadata store es a blob store lehet ugyanaz. Hatranya, hogy cloudban nehezkesebb, mint egy google/amazon/... bucket, amit ugye keszen kapsz csili-vili mindennel. Szoval ha csak helyi DC van, akkor valszeg az egyik legjobb a mongo (es van java drivere :D ), ha cloud-ot is tervezel, jobban jarsz, ha rogton a cloud-native megoldasokra ugrasz.
Fájlrendszer + kigyűjtött metaadat. Lásd még minidlna és a többi szoftvert. Katalógusfájlt vezetnek.
Fájlrendszer többszintű, ne legyen 1000-nél több fájl egy mappában. A squid annó 256-nál húzta meg a limitet.
SAS vagy U2 SSD-vel lehet gyorsítani a nagy számú parallel kérés teljesítését. Kérdés mekkora a parallel igény? Kell-e SSD illetve kell-e elosztott tárolás?
Nem hinném h. a köv. 2-3 évben szükség lenne 2-3 RAID6 teljesítményénél nagyobb IOPS-re. Ahogy már írtam, az mindenképpen kell hogy minimum két helyen is meglegyen a cucc, de ennek nem kell realtime-nak lennie. Nyilvánvalóan ha lehet ahhoz közelíteni, az a legjobb, de nem gondoltam olyanra pl. h. akkor 40TB-os DRBD block device pl.
Ha ragaszkodom az adatbázis-szerű kívánalmadhoz, akkor Ceph-et mondanék, de szerintem ekkora méretben az még ágyúval verébre és nem lesz rentábilis.
Gyakorlatban inkább simán ZFS, SSD cache-el, snapshot-al, replikával.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Magam is próbáltam ezt már 'optimalizálni' fotók tárolása és rendszerezése kapcsán....
Azonban a végeredmény, ahogy a működő szoftverek is csinálják:
- adatbázisban a metaadatok, és a file helye (path) a filerendszerben
- a filerendszerben pedig valamilyen rendező elv alapján meggátolni a könyvtárak túlhízását.
pl dátum, téma/kezdőbetű/akármi. - ez már attól függ milyen jellegű állományokkal dolgozol.
Ezt meg lehet spékelni még egy verziókövetéssel is...
és akkot közeledsz a tökéletes dokumentumkezelő rendszerhez - amit biztosan sokan implementáltak már 100 féle módon ;)
zrubi.hu
Sub, hasonlo kihivasok elott allok, nekunk eddig a minio a befuto. :)
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
Milyen fs hibak fordulnak nalad elo, ami miatt fsck szukseges?
Most raneztem jelenleg az alabbi szamokkal fut par nginx proxy_cache_path,
df -i /mnt/asdf
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/asdf 2197274624 37761761 2159512863 2% /mnt/asdf
df -h /mnt/asdf
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/asdf 131T 34T 98T 26% /mnt/asdf
A kérdés remek, úgy fogalmaznék h. az ördög nem alszik. Ha csak átmeneti tárról beszélgetnénk, akkor nem tartanék ilyesmitől (fentebb már írtam h. pl kernel panic során valami megrogyhat ha előfordul, bármi hiba esetleg az fs driverben, ststb).
Ezen felül azért pl. ha ext4-et nézzük, akkor őt néha illene fsckzni, ami jelenleg nem opció (igen, az XFS nem olyan, de ki tudja).
A gond az, hogy itt olyan anyagokról beszélünk amik nem reprodukálhatók sehogyan sem, illetőleg akár nyomozati ügyben is elővehetik akár 10 év múlva is. És nem, nem lesz szalagos archiválás és társai, csak a félreértéseket elkerülendő :D
Jelenleg mi a backup ami 10 ev mulva is mukodik?
Jelenleg a szinkronban tartott (csak írt!) párja.
Az valóban igaz h. ha az élesen megsérül egy fájl, akkor azt áttoljuk a "backup"-ra is. Ezt a kockázatot jelenleg vállalja az üzleti oldal, nyilván az is kérdés h. meddig és mennyit áldoznának rá h. ezt is megszüntessük.
"És nem, nem lesz szalagos archiválás és társai," - ezen azért én elgondolkodnék... Ilyen növekmény mellett, pláne, ha jellemzően x időnél régebbi felvételek visszahallgatása és/vagy ügyfélnek/hatósági megkeresésre történő kikeresése nem igazán jellemző és/vagy ilyen esetben belefér, hogy nem azonnal, hanem 1-3 munkanapon belül lesz elérhető a régi felvétel, akkor az x-nél régebbi tartalom mehet offline/offsite archívba. A szalagos megoldással kapsz egy offline/offsite mentést (nem, a keletkezéskor/módosuláskor "bután" átmásolt adat nem mentés, csak egy offsite másolat arra az esetre, ha az elsődleges site-ot mindenestől elvinné a cica - az elsődleges site korrumpálódása/adatsérülése ellen nem véd, hiszen az is átszinkronizálódik...), és egy olyan lehetőséget, amivel az online tárhely méretét kellően kordában lehet tartani (x időszak adatait kell csak online tárolni, nem pedig Ádám-Éva és az öreg diófa óta mindent _is_)
Igen, lehetne opció, de macera, az ügyfél el akarja érni a cuccát amit tárolunk neki, ha kirakjuk szalagra akkor ezt bukja ő is, mi is.
Archiválásnak nagyon hasznos lenne, de lásd fentebb, ez most nem volt topic. Ugyanakkor igen, azok a problémák és megoldandó kérdések mind-mind előjönnek amire rámutattál, főleg ha már nem 20T-ról beszélgetünk majd, hanem ennél is többről.
"az ügyfél el akarja érni a cuccát amit tárolunk neki" - ÁSzF kérdése, hogy mondjuk az 5 évnél régebbi felvételeket a következő munkanap kapja meg :-D
"azok a problémák és megoldandó kérdések mind-mind előjönnek amire rámutattál" - Köszönöm, én sem most ASAP megoldandóként szedtem ezeket csokorba, de hosszabb távon biztos, hogy erre is gondolni kell majd - és nagyon nem mindegy, hogy hogyan lehet költséghatékonyan megoldani a felvetett problémákat. A szalag, vagy más offline+offsite mentés hiánya - orosz rulett - és nem is biztos, hogy egy lőszer van a tárban... Persze, kellően zárt és teljeskörűen védett adattárolás esetén gyakorlatilag "csak" a tároló rendszer hw és sw hibáiból, illetve az üzemeltetési hibákból adódó kockázatok ellen kell védelem elsődlegesen. Viszont ez utóbbi azért "szólhat nagyot", egy véletlen vagy szándékos(!) törlés például nagyon tud fájni backup nélkül.
Ha megfelel kész megoldás is, akkor Dell Technologies (EMC) kínálatból kettőt is tudok ajánlani. Bár szerintem az ECS object store a jobb erre a feladatra, de a PowerScale NAS is megfelelhet. Mindegyikkel van tapasztalat kicsi, és PB+ méretben is. Ha érdekes keress meg!
Ha HDD alapu a storage es sok kicsi fileod van es teljesen random a file-ok elerese, akkor az cumi. Hasznalhatsz barmit, nem lesz hatekony. Hogy a fenti 3-bol melyiket adod fel az a te dontesed :)
Definicio: egy file akkor "kicsi", ha a merete kb megegyezik vagy kisebb mint a storage rendszer latency-jenek es a savszelessegenek a szorzata. Manapsag szinte biztosan kb 16-32 mega felett nem szamit kicsinek egy file.
Meg 2008-ban epitettunk egy szervert, amirol tudtuk, hogy sok kicsi fajlt fog tarolni. Akkor ext4-re voksoltam. Azota megelt par migraciot, de az FS maradt ext4. Kb 18millio fajlt tarolunk rajta, ami naponta novekszik (append only), kb 5 TB tarhely foglaltsaggal. Igeny eseten noveljuk az LV meretet. A mentese viszonylag egyszeru, csak az utolso irasra kijelolt mappat kell rsyncelni, a tobbi csak RO, nem valtozik a tartalma.
Nem hasznalunk semmi varazslatot, annyi a trukk, hogy naponta uj almappat hoz letre az alkalmazas. Az alkalmazas adatai Oracle DB-ben vannak.
ez is jo megoldas lehet, hogy az uj fajlok mindig valami uj mappaba kerulnek bele. a regi mappat meg ro-ba mountolni, igy arra mar nemkell fsck-zni (egy ro csak nem romlik el)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nézz utána a "bitrot" kifejezésnek.
De a bitrot nem fog fsckt triggerelni, csendben lesz szar :)
hat a bitrot-ot ugyanugy nem fogja egy reboot utani fsck megtalalni...
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
A feltevés az volt, hogy ha valami RO lett mountolva, akkor az biztosan nem romolhat el "magától". A válasz pedig: de, elromolhat akár az is.
persze, meg ha rabaszol egy kalapaccal akkor is elromolhat... \o/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nem mondasz rosszat te sem! ;)
Sőt, a HDD a ráüvöltést sem szereti, úgyhogy vigyázni kell a kis lelkére... :D
https://www.youtube.com/watch?v=tDacjrSCeq4
Igazából a felvetés az volt, hogy nem romlik el úgy, hogy fsckzni kelljen (én implicit hallottam az automatánt is a mondatban). Az meg igaz, nem fog elindulni akkor az fsck.
Ha feltételezzük, hogy a storage oldalán RAIDx van, akkor a storage észre fogja ezt venni és korrigálja, mondhatni fizikai szinten, a fájlrendszer szintjén 'ro' marad és nem veszi észre a korrekciót.
https://iotguru.cloud
Mi úgy csináltuk, hogy a fájlok fájlrendszerbe mentek, a metaadatok Elastic-ba. Eléggé gazdag metaadat infók, pl, dokumentumokban full text search, stb. Pár millió fájl, Elastic simán viszi a bonyolultabb kereséseket is. A fájlok a tartalmuk SHA256 hashével vannak tárolva (ez a fájlnév) sima ext4-en, több szintű könyvtár-struktúrában: az első 3 karakter az első szint, a második 3 a második szint. A hash eloszlása miatt a könyvtárak terhelése is eléggé egyenletes. Fsck-ra nincs szükség, tisztességes RAID cucc van alatta.
Mi köze a RAID-nek ahhoz, hogy kell-e fsck?
https://iotguru.cloud
Mi a jellemzőbb tevékenység, olvasás vagy írás? (Írásra tippelnék)
Jellemző, hogy mikor keletkezik az adat?
Amit feltételezek, hogy ez egy call center, ahol a hívások munkaidőben vannak. Ez esetben lehetne a backend egy async rendszer, ahol egy kisebb, de gyorsabb storage a napi Prod, és este amikor nincs forgalom, mehetne a backup/átmozgatás egy nagyobb rendszerre.
Igen, jól tippeled :)
Konstans, nem túl nagy IO igényű írás (kb. tényleg munkaidőben, elvétve éjjel is azért, de az nagyságrendileg a 0-hoz közelít) és teljesen random 1-1 olvasás, vagy kampányszerű szekvenciális olvasás.
Ezt így nem biztos h. szeparálni fogjuk tárolás szempontjából, mert -ugyan nem részleteztem-, de jelenleg valami hasonló történik. Ügyfél rendszerben keletkezik egy hang X formátumban (másik tárolóeszközön), ez kerül az archívumba kódolás után. Tehát nézőpont kérdése, de ez a része a dolgonak létezik, igaz nem napi az áttöltés, hanem annál jóval rövidebb, hogy az alkalmazás szinten 1 "store"-t kelljen kezelni, ne legyen az h. hot/cold adat külön elérhetőségen létezik. Ráadásul konvertálás nélkül a formátum is viszonylag kismennyiségű lejátszó számára értelmezhető, ez tovább bonyolítja/bonyolítaná a dolgot. Az eleve konvertált rögzítés meg sok-sok CPU-ba kerülne (ennek a miértje a kiszámíthatatlanság).
Ha ritka az olvasás, akkor miért nem jó, ha az külön helyen van, egy nagyobb-lassabb-olcsóbb rendszeren? Ettől még az alkalmazást talán nem horror költség erre felkészíteni.
Naiv megközelítésem szerint, minimálisan az alábbi keresési usecase-ek vannak:
- ügyfél alapján
- munkatárs alapján
- időpont alapján
- ügytípus alapján
Ehhez meg db kell, hogy jól kereshető legyen. A másik fontos dolog, hogy egy-egy könyvtárban ne legyen sok állomány, mert az kurvára lassít. Vagyis, ha csak db-ben megy a keresés, akkor minél jobban legyen elpakolva az adat a könyvtárfában, ahogy Franko is mondta egy faék egyszerűségű hash kellene, ami ezt a könyvtárfát megcsinálja.
Igazabol ezen a szinten valasztanek egy olcso bucket provider-t, es abba raknam. Mindent keszen megkapsz (backup, load balancing, failover, menedzsment, csilivili grafikonok/kimutatasok, monitorozas, alerting, ...), es a metadata-t meg egy cloud sql vagy document store, amelyik olcsobb/jobb.
Arban mindent osszevetve (munkaido, 24/7, hardver, stb....) nem leszel hatrebb, de legalabb egy industry standard megoldas (=dokumentalt, ismert, 'van hozza ember'), nem egy helyi taknyolas.
Ez viszont adatkezelésileg és adatvédelmileg sajnos nem megoldható. Firtathatjuk, de felesleges, saját vason, saját lokációban marad az adat, ennek jogi/szabályozási/stb okai vannak.
Az oké és teljesen reális h. helyben valami cloud native megoldásban tárolunk.
Ilyen nekünk is volt, GDPR miatt. Eros encrypt-el okes a dolog a legtöbb esetben, de igényel némi utanajarast.
Igen, bucket használatánál alap a titkosítás. Ha ilyen irányba gondolkodnál akkor javaslom megnézni ezt: Home - Nasuni
(nincs valós tapasztalatom velük)
Attól függ hogy a titkosító kulcs hol van tárolva, ha szolgáltató rendszerében akkor nincs miről beszélni. Szeretem a felhőszolgáltatós munkát, de azért ne legyünk naivak sem.
Igen, csak ügyfél bekérdez h. hol a cucc, akkor lehet magyarázkodni.
Átlalában nem olyanok ülnek ott akiket érdekel az encrypt erőssége, vagy úgy általában bármi műszaki dolog. Sokkal inkább arról szól a kérdés h. nálunk van-e, ha igen HU DC-ben van-e és ha igen akkor békénhagynak. Más kérdés h. a mi gépünket se nem könnyebb se nem nehezebb feltörni mint másét, de ez egy teljesen más topic lenne.
Általam ismert bucket providereknél lehet kérni kizárólagosan EU-n belüli (GDPR-konform) tárolást.
Gábriel Ákos
Tisztában vagyok vele. De egy 50+-os kukacoskodós jogászt is győzzenek meg helyettem akkor pls :)
Viccet félretéve, még így is van olyan ügyfél, ahol úgy értelmeznek szabályozásokat/törvényeket, hogy 1 darab cloud dolguk nincs, még hazai providernél sem, minden onprem. Ilyenkor szokott jönni h. mi is tegyük ki a cuccot oda, mert no cloud. Nyilván ez nem megoldás, de ettől még nem fogom magam egy 3rd party -legyen az akár EU based- cloud providerrel tökönlövetni.
Miután neghalt a régi jogász, az új talán már modernebb felfogású lesz. Szar dolog, mikor munkahelyen valakinek a halálát kell kívánni, hogy jobban menjenek dolgok. A parlamentben ez mondjuk érthető.
Igen, de sajnos addig is üzemeltetni kell :)
Ha nem, hat nem, de eleg sok olyan projektet lattam, ahol ez nem jogi, hanem hajlandosagbeli problema volt elsosorban, mert az illetekesek nem akartak vele foglalkozni. :)
Azt nem mondtam h. ez nem hajlandóságbeli kérdés, pisztán azt h. felesleges firtatni, mert egész egyszerűen sem aparátusunk, sem erőnk nincsen átvinni néhány ügyfélen egy ilyen (akár EU-s) 3rd party providert jelenleg.
Szoktam mondani, hogy "széllel szemben nem lehet hugyozni, csak szarni".
https://iotguru.cloud
Fú, ilyet nekem is kell csinálni pár terra adatra. A témában viszont zöldfülű vagyok, ekkorra méretre mi az optimális szoftver?
minio + bucket replication.
https://hup.hu/node/27358
Ja hogy az helyesen tera. Kösz.
Persze, egy r-rel, és nem csak írásban, de ejtésben is rövid r! Vagy még jobb, amit a linkelt topik végén írnak, tebibájt, vagy tebi, elsőre így szokatlan, senkinek nem jönne a nyelvére, pedig sokkal precízebb. Nincs ez a 2-es vagy 10-es számrendszerrel, vagy melyik gyártó, eszköz, OS épp mit alkalmaz keverés. Persze, a nagyságrend akkor is világos, a tera-tebi általában azonos ebben a tekintetben. A legidegesítőbbek ebből a szempontból a floppy-k voltak, mert ott egyszerre keverték a 2-es és 10-es számrendszerben számolást, egy 3,5 inch-es HD (1,44-es) PC floppy sem nem 1,44 mebibájt, sem nem 1,44 megabájt, hanem ( 80 sáv × 18 szektor/sáv ) × ( 512 bájt/szektor × 2 oldal), azaz ( 1,44 × 1000 ) × ( 1024 ) bájt, azaz leginkább kilokibibájt lenne, vagy 1440 kibibájt.
Ami még sokszor furán jön ki, hogy a rövidítés, a Tb terabitet jelent (és nem tebibitet), míg a terabájt TB, a tebibájt TiB. A kiírt változatnál viszont mindegy, hogy terabájt vagy terabyte, mindkettő jó, magyar szövegkörnyezetben is, de az idegen írásmódnál érdemes figyelni, hogy akkor kötőjellel kell toldalékolni, pl. terabyte-ot, terabyte-tal.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Amin okoskodsz, az a marketed capacity - hasonlóan a százas papírzsebkendőhöz és a 200 lapos WC-papíhoz. Az utóbbi lapok az évek során annyit vesztett a szélességükből, hogy valamit tenni kellett. Így aztán az egyre keskenyülő téglalap egyre rövidülő négyzetté vált, miközben a mennyisége még mindig 200 lap. No, itt kéne precízkedni (a németeknek, akik még a brótot is grammra vásárolják), mert nagyságrendekkel nagyobb volumenű termékről beszélünk!
Nem. 1) nem okoskodok, 2) össez-vissza alkalmazza pl. a Windows, pl. a meghajtó méreténél decimálisan mutatja, de az Intézőben már binárisban. Egyik szoftver így, másik komponens amúgy. Erre jön rá, hogy a gyártók is kevernek, bár ott már beállt, hogy decimálisan van megadva, és ehhez tartják magukat. Főleg HDD-nél régi gyakorlat, de újabban SSD-ken is csinálják egyre inkább, hogy nem pontosan kettő hatványa a mérete sem, hanem decimálisan kerekebb méret (250, 500 giga, 1000-2000 giga) és még az is megint decimálisan van értve, tehát nem 500 GiB hanem 500 GB. Mindegy, mert a meghajtó méreténél még pont nem érdekelne, annál úgyis mindig ráhagyással veszek, hogy egyel nagyobbat, mint amekkora kéne, vagy gondolom, hogy a közeljövőben kellhet. Hasznos lenne azonban a gibi, tebi mintájára bevezetni valami rövidítéses jelölést a decimális tételekre is, pl. a GiB-tól jobban megkülönböztethetőbb lenne a G-B, vagy G+B, vagy hasonló, amiről ránézésre is messziről látszik. A GB-ról is tudja mindenki, hogy valószínű már decimális, de azért sose lehet benne biztos az ember fia, hogy az i-t nem tették ki, vagy a decimálisra céloznak. Tisztább lenne.
A commercial vendors mindig is a lókötő kategóriába tartoztak, az állítólag IT professionals is elég tág fogalom, kicsit ilyen brit tudósok rájöttek valamire szint. Én egyébként a mai napig bináris formában adom meg, értem, használom lehetőleg. Nagyon ritkán, mikor gyorsan kell átváltani, nincs idő számológépezni, vagy valami normálisabb szoftverrel kijeleztetni, akkor néha 10-esben olvasom ki, pl. lemért mappaméret 429 125 397 bájt, ott néha nem lehet gyorsan matekozni, ha annyira azonnal kell, és 429 megabájtnak veszi az ember, mikor csak 409,2 MiB. Nyilván fejszámoló művész nem vagyok. Linuxon a legtöbb CLI/TUI tool hála istennek általában eleve korrektül kezeli, binárisban (még akkor is, ha human readable megoldással automatikusan a legközelebbi nagyságrenddel jeleníti meg), és ha más kell, arra is adnak beállítási lehetőséget, kapcsolót, stb.. Inkább GUI-s programoknál rossz, főleg, ha valami normiknak készült, egyszerűsített változat, ami csak az egyik megoldást támogatja, és sokszor azt se tünteti fel jól. Persze ez nem jelenti, hogy ezt GUI-s programoknál nem lehet beállítani, Krusader, Total Commander, Double Commander, stb. simán támogatja.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
No látod, már megint okoskodsz. ;) Pedig pont arról, amit ily hosszan kifejtettél, egy betű sem hagyta el ajkaimat.
Én szakember vagyok már 40 éve, ezért a kiló a számítástechnikában mindig 1024 és az assembler program mindig radix 16 direktívával kezdődik. A marketing dumát meghagyom az informatikusnak (aki mindenhez ért semmit ;)). Sőt, a szövegfájlt - ha idegen helyről érkezik - hex editorral nyitom meg. Gyakran nem hiába. A GUI meg olyan amilyen, pl. a windows fájkezelőben a 0 után az 1k méret következik.
A számoknak sokan téveszik el a pillanatnyi szerepét. Az 1.44-es diszknek az 1.44 nem a mérete, hanem a neve, mint az 1GB-os diszknek is. (A kiló a szlengben 100Ft, a mázsa 1000Ft, a tucat gyufa 10 doboz.) A 429 125 397 bájt akkor érdekes, ha arra vagyok kíváncsi, hogy 879 MiB méretű 1GB-os diszk kapacitásának hány százalékát foglalja el. :-D Ekkor viszont soha nem a GiB MiBenlétéről töprenegek, hanem kB, szektor vagy blokk "mértékegységet" haszálok, azaz közös nevezőre hozom.
A számoknak és mértékegységekek általában nincs különösebb szerepük, hiszen a Hány óra? kérdésre normális ember azt feleli: Már elmúlt fél négy. Terrrmészetesen, ha dizsitális órád van, akkor mondhatod hogy tizenöt óra harnichét perc huszonhárom másodperc. :-D Az előbbi pedig a 15:30:00 < time < 15:45:00 kifejezéssel helyettesíthető, persze normális ember soha nem beszél így. Ezért lényegtelen, hogy melyik szoftver mi a retket ír ki és azt milyen agymenéssel próbáljuk megnevezni.
lényeges magyarázkodás nélkül;
- filesystem megoldás 20M file felett már macerás, 80M file felett már extrém nehézkes, 100M file felett alapvetően csak szenvedés
- Nagyjából ez igaz az AWS sima S3 szolgáltatására is, az se olyan nagyon ügyes
- Nincs üzemeltetési tapasztlatom 100M file felett, de a 30M - 100M közötti küzdelmek alapján logikusnak látszik a következő archiectúra:
Egy objstore, ami nem használ fiesystemet. csak szigorúan key->object storage, törlés/írás nem kell. Esetleg adatvédelmi okokból teljes nullázás, de a foglalt adatterületet felszabadítan egyszerűen túl drága. A key az 64 vagy 128bit, azt kész. A objstore backend lehet néhány nagy file egy filesystemen, de inkább csak natív partíció/blockdevice. A key->location metaadatrész férjen be a memóriába és maradjon is ott. Külön journal terület ennek mentésére/tárolására. A blockdevice alatt valami alapvető raid védelem. Az egész egyetlen, jól meghatározott felületen adja, mittomén leht S3 vagy webdav, vagy egy rest api vagy valami egyedi, de legyen egyszerű. Mivel nálatok mp3 az adat, deduplikáció vagy tömörités eleve nem játszhat, kár is ilyennel foglalkozni.
Egy adatvirtualizációs layer, ami több fenti tulajdonságú objstore példányt összefog, és tükrözést, replikációt vagy törlést implementál.
Az alkalmazás és minden management cucc ezen a felületen éri el.
Minden metaadat DB-ben, vagy más, ettől külső tárolóeszközön.
Külön ellenőrizni kell, hogy a "key" az kellően egyenletes: nem prediktálható és leginkább uniform randomnak tünik.
Adnék egy esélyt a seaweedfs-nek, (üzemeltetési tapasztalatom nincs, de játszottam vele) de ahhoz heggeszteni kell még egy adatvirtualizációs layert.
Viszont meg se próbálnám a MiniIO-t. Azt hírdetik, hogy restfull apin keresztül implementált distributed lock végzi a belső egységet. Na, a dlock pont az, mit mindenképpen kerülnék. Ugyane miatt a több host által implementált filesystemek (ceph/glusterfs) sem erre a feladatra valók. Az elemi objstore példányok ne tudjanak egymásról, az, hogy melyik key melyik elemi példányon (példányokon) van, azt leginkább csak az adatvirtializációs layer tudja. Szerintem ebben a méretben egy magyar középvállalat meg tudja oldani.
Én úgy szeretem, ha elérhető a forráskód, de ez már csak egyéni izlés kérdése.
Volt szerencsém fájlrendszerben ilyen könyvtárstruktúrához:
00/00/00/
00/00/01/
...
AA/BB/CC/
...
FF/FF/FE/
FF/FF/FF/
A könyvtárakban az AABBCC* nevű állományok voltak elhelyezve, és egészen jól kezelhető volt a könyvtáranként 10-50 fájl...
Ilyet utoljára egy Microsoft Certified Expert követett el, méghozzá WindowsXX alatt. Ott 16^4=65536, itt meg 36^3=46656 a dir száma, vagyis ugyanaz a nagyságrend. (Feltételezve a [0-9A-Z] neveket.) Az utóbbi esetben alig 100MB az eltapsolt memória, ami manapság semmiség, de keresgélni kell benne. A nevek eloszlása sem garantált, ezért lehet extrém terhelés az egyes ágakon.
Említésre méltó, hogy WindowsXX alatt (XP..legújabb szerver verzió) a MS cache kezelési hibája miatt visszafordíthatatlanul felzabálja a memóriátés a gépet is szépen terheli.
Szóval ez a lehető legrosszabb megoldás.
Jelen esetben a 000000...FFFFFF tartományba eső kezdetű hash-sel azonosítható fájlok kerültek az egyes könyvtárakba, ami tény, hogy nem adott tökéletesen egyenletes eloszlást, de sem az írásnál, sem a visszaolvasásnál nem okozott gondot a fájlok számossága.
Hááát, ezt gondolták a másik redszerröl is, ahol hash helyett uuid volt az ötlet. Bevallásod szerint ebben a struktúrában legfeljebb 2,4M elem van - vagy valószínűleg lényegesen kevesebb. Viszont ott fent a kiírás ennél lényegesen több.
De mondok jobbat.
A kb. 19M tételt 1 mélységű struktúrában és 128 dirben kezelem 6300 bejegyzéssel, szemben a 2,4M tétel 3 mélységű struktúrában és 46656 dirben. (128 a cégek ill. a mentendő Windows rendszerek száma) Melyik működhet gyorsabban? ;)
Ráadásul a 17 adattípusból nem ez a legnagyobb méretű vagy legszaporább.
Hát... a jó partition key megtalálása - meg úgy általában nosql-re adatstruktúra kialakítása - (másfajta) elemzést, tervezést igényel.
Mondanám, hogy Cassandrára lehetne ilyet építeni, de nincsen vele túl sok tapasztalatom, viszont vannak nem rossz módszertani anyagaik.
:)
:) Itt nincs se no, se yes sql. ;) Egyszerű fs + text "adatbázis". A metaadat sql-be IS betöltődik, hogy a php/js/java programozók az általuk kedvelt módon kérdezhessenek.
Az elemzés és tervezés csak annyi volt: 1) text sorokat kell elrakni, amelyek rövidek vagy akár hosszúak (elméletileg akár GB méretű) és ezekből 0...rengeteg darab. 2) db dumpok mentése néhányszor 10MB (90 napra) 3) a fentiekben leírt struktúra inkrementális mentése. A formátumokat 2-3 rfc leírja. Nyelvek bash, awk, C. A rendszer élesben 2009 óta megy, működése automatikus. A célja a max. 20 perces adatvesztés biztosítása és a fejlesztők log és adatbázis mentésekkel kiszolgálása. (Igen, ez egy backup szerver.) A topicnyitó igényeinek nem felelne meg - csak működik. ;)
256*256*256=16.7millió könyvtár, előre létrehozva, könyvtáranként átlagosan ~10-15 fájl. Lehetett _volna_ egy szinttel kevesebb is, és 3-4000 fájl/könyvtár, a döntés miértjét nem tudom, de tény, hogy nem volt performancia probléma, miközben igen jelentős olvasási "forgalma" volt a kiszolgálónak.
Optimális lehet képek tárolására!
Minden színhez egy path és a pixelek koordinátái alatta. :-D
(Bocs!)
zfs, ext4, xfs jellentősen másképp kezeli a directoryt, de mindegyikre igaz az, hogy a directory kezelésének műveletigénye (IO darabszám illetve btree/bucket mászkálás, dereferencia szám) nem szépen egyenletesen nő. Ezen 3 gyakran használt filesystem esetén van egy méret, aminél nem érdemes nagyobb directoryt használni. Ez a méret sok mindentől függ, pl nem csak bejegyzésszám, hanem a benne lévő nevek hosszának összege; nameg filesystem block méret vagy btree bucket méret stb. Mindenesetre van egy limit. Ez az oka a directry hierarchiába osztásnak, ami jó, ha jól csináljuk.
Ha van X file, és osztani akarjuk ezeket a limitnek megfelelő directoryba, akkor log(X)/log(limit) mélységű directory hierarchia javasolt, javasolt a file neve és a directory neve minél tömörebb (hexa ellenjavasolt, base64 is ellenjavasolt, van még karakter, tessék mindet használni, de mondjuk a base85 már nem olyan rossz). Roppant fontos, hogy egyenletesen terüljenek. Kriptográfiailag erős hash kell.
Megpróbálhatjuk optimalizálni a IO-t, mondjuk úgy, hogy a VFS cache minél nagyobb részét memóriában tartjuk, ekkor befigyelnek olyan apróságok is, hogy az indode pontosan hogyan reprezentálódik a slab-ban, és egyéb határozottan kernelközeli kérdések, a rendszergazdai tudást jelentősen meghaladva.
Megpróbálhatjuk azt is, hogy nem egy filesystem van, hanem több, esetleg bind mountolva egymáshoz (egy hierarchiát nyerünk).
Ha mondezt keményen végigszenvedjük, akkor érünk el a 100M bejegyzéshez. 1G bejegyzés filesystemben nem lesz mai filesystemeken. A filesystem egyszerűen túl általános, túl sok funkciója van, az inode túlságosan szószátyár, a directory hierarchia és a bejegyzés túl sok helyet vesz el. Nem lehet elérni, hogy 1 lekérés maximum 1 darab diszk IO-t eredményezzen.
Az más kérdés, hogy a metaadat-tárolásra javasolt DB mit csinál 1G nagyságrendű rekorddal (oracle DB-t láttam már 4G sor méretű táblával, hm.. nem volt túl hatékony, de még elzümmögött)
"Kriptográfiailag erős hash kell."
Semmi szükség rá ebben az esetben. Bármilyen hash table-hez használt algoritmus megteszi.
Tippre az ütközéseket szeretné elkerülni.
Azon a crypto alapú hash nem igazán segít...
https://iotguru.cloud
Ezt azért gondold át!
Szerintem is gondold át.
https://iotguru.cloud
egy sima uuid generáláshoz nem kell "crypto-hash", feleslegesen sok erőforrás. Ráadásul ettől nem lesz "unique-abb".
Gábriel Ákos
Az time based UUID nem szór eléggé, a random meg ugyanúgy ütközhet, mint bármi más hash (crypto is)...
https://iotguru.cloud
Nem olyan a uuid hogy egy része random egy része meg time-based és hostid alapú? (tehát biztosan unique)?
Mit jelent az hogy "nem szór eléggé", ezt hogyan lehet mérni és hogyan lehet javítani?
Gábriel Ákos
Többféle UUID van:
Az UUID v1 olyan, hogy 60 bit timestamp, 14 bit uniquifying bit, 6 bit ami megmondja, hogy ez TimeUUIDv1 és 48 bit MAC azonosító. Az ütközésmentesség biztosított, ha feltételezzük, hogy nincs MAC ütközés és az idő szinkronban van, de ha ezt elkezded kiosztani, akkor a bitek jelentős része fix, ami nem jó, ha valamilyen random szerint akarod szétosztani.
A v2 az majdnem v1, csak biztonsági okokból egy csomó dolog ki van benne cserélve (MAC és a dátum, például), ezért globális használatra nem alkalmas, de ugyanazok a bajok, mint fent.
Van a v3 és a v5, ami MD5 és SHA-1 hash, nincs garantálva az ütközésmentesség.
És van a v4, ami random, szintén nincs garantálva az ütközésmentesség.
Nyilván lehet saját UUID-t készíteni, saját igények és specifikáció alapján, ahol van rendes random benne, ahol kell, plusz megfelelő felbontású idő, lokális használatra.
https://iotguru.cloud
Vödrökbe akarjuk tenni a fájlokat a hash prefixei szerint. A cél az volna, hogy minden vödörbe ugyanannyi fájl kerüljön. Ha kriptó a hash, akkor joggal számíthatunk arra, hogy minden vödörbe ugyanannyi fájl kerül, illetve ezeknek a méretei is egyformák lesznek átlagosan. Így akár az első vödör akár fizikai diszk volume is lehet, a diszkjeinken ugyanakkora lesz a terhelés nagyjából.
A véletlenszerű mintavételezés törvényei szerinti szórással természetesen. Ha nem kriptó a hash, szerintem akkor is elvileg teljesülnie kell ennek, kivéve ha a hash valamiért tud korrelálni azzal amit tárolunk. Az biztos, hogy a kriptó jó, a nem kriptón meg gondolkodni kellene, hát akkor legyen kriptó. Elegendő annyit kriptóhashelni a metaadatokból, amik már egyedi módon azonosítják a fájlt. Tehát a teljes tartalmat nem feltétlenül kell, ha mondjuk hívások időbélyeggel és hívószámmal vannak tárolva, mert ez a páros már egyedi.
Kriptó hash esetén "Ízlés kérdése" lesz, hogy kezeljük-e az ütközéseket, ugye elvileg rendkívül ritka lesz. Lehet mérlegelni, hogy belefér-e. És mi fog történni, elszáll az egész, vagy csak hibásan működik ütközés esetén? Én egyszer használtam kriptó hash-t hasonló célra, és lekezeltem az ütközést ennek ellenére. Tesztelni kellemetlen, mert a kriptó ütközéshez nem tudtam tesztesetet gyártani, a hash algoritmust le kell cserélni a tesztben egy ütközőre, hogy tesztelhessük az ütközés esetén történő viselkedést.
Vagy nem, mióta feltalálták az alközpontot.
Csak ezt a nagy erőlködést nem értem. Minek bonyolítani, amikor egy 64 bites auto id biztosan egyedi. Abból pedig bármilyen felosztást - és egyenletes eloszlást - lehet gyártani div és mod segítségével. És egyből kész a metaadathoz a fk is.
Az az érdekes, hogy a thread tetején kiderült, hogy ez nem optimális és korlátozott tárolási mód. És a topicnyitó is így kezdi.
A hash alapú kulcskészítés egy ilyen általános megoldás, arról volt szó a szálban. Egyetértek egyébként, hogy ha van egyetlen "szerver", akinek lehetősége van rá, tehát nem kell olyan szinten skálázni, hogy ez lenne a szűk keresztmetszet, akkor ez a legegyszerűbb, hogy adunk mindennek egy sorszámot. Sokféle lehetőség van a saját előnyeikkel és hátrányaikkal, ez is egy megoldás. Például ésszerű lehet az is, hogy egyszerűen időrendben haladunk előre diszkenként. Ekkor pont hogy mindig a legutolsón lesz az összes terhelés, de mivel nem a sávszélesség volt a probléma, ezért ez sem probléma. Nekem az a tapasztalatom, hogy ami log szerű adat, azt érdemes időrendben sorrendben írni, az a legésszerűbb.
egy sima uuid generáláshoz nem kell "crypto-hash", feleslegesen sok erőforrás. Ráadásul ettől nem lesz "unique-abb".
Gábriel Ákos
Jogos, pontositok: ha a filenev is hashbol kepzodik, akkor nem jok a rovid kulcsu hashing algoritmusok.
Ha _csak_ hash a filenév alapja, akkor bármilyen hash esetén fennáll az ütközés veszélye, amit ugyan a hosszabb kulcsú algoritmusokkal lehet csökkenteni, de annak az erőforrásigénye lesz nagyobb. Simán előfordulhat,hogy egy rövidebb hash-ből _és_ egy kellően nagy felbontású időbélyegből összerakott név "olcsóbb", és kevesebb esélye van az ütközésnek, mintha hosszabb (de "drágább") hash lenne csak a név alapja.
Amennyiben a két fájlnév is megegyezik. Ha nem, akkor nem áll fenn az ütközés veszélye, amennyiben jó a crypto algoritmus.
https://en.wikipedia.org/wiki/Collision_attack
Mathematically stated, a collision attack finds two different messages m1 and m2, such that hash(m1) = hash(m2).
Ha ilyet találnál véletlenül akkor nagyon nagy a baj. :)
Nem nagy baj, csak ritka, minél több bit a hash, annál ritkább. Ha ütközést akarsz elkerülni _biztosan_, arra nem a crypto hash a legjobb megoldás.
https://iotguru.cloud
Ha ebbe belemennénk az nagyon messzire menne. :)
Akit esetleg érdekel a téma, az ezt nézze meg:
https://stackoverflow.com/questions/62664761/probability-of-hash-collis…
Illetve Couseran van egy nagyon jo crypto kurzus, ahol elég sok szó esik a témáról.
heh, nem akartam ekkora vitaszálat indukálni :-)
lényeg, hogy a kulcs jól szórása (és ütközésmentessége) rendkívül fontos, és ezt nem olyan egyszerű elérni.
Én nem bánom a normális vitaszálat, ha az alapján jobban lehet érteni a problémát. :)
anno nekunk 40+ kis thumbot kellett tarolni egy-egy videohoz (es volt >1M video), egy ffindex nevu cuccot hasznaltunk:
irtam hozza nginx modult, igy webserver kozvetlenul olvasta. egyszeru volt, es gyors.
hasonlo elven, te is osszecsomagolhatod (pl egynapi) anyagot egy fajlba, es azt kiszolgalhatod: https://github.com/youzee/nginx-unzip-module
ha meg apache kiszolgalas van (elsore nem talaltam modult), de egy kis php scripttel azt is le tudod kezelni: https://www.php.net/manual/en/book.zip.php
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
ez egyebkent tok elegans es egyszeru megoldas, ambar a 'helyi tocskoles' - feeling meg mindig megvan, de legalabb faek egyszerusegu.
Esetleg még megoldható szoftveresen is, Key-Value adatbázis használatával.
Pl.: How to manage large amounts of data with Iteratee
Ha van kedved elmenni enterprise irányba, akkor én is bedobok 2 nevet: Zenko Cloudserver vagy más néven Scality. S3 kompatibilis, elosztott rendszer építhető belőle, akár software defined storage alapon.
Én exabyte méretben láttam működni, illetve dolgoztam is vele. A beépített replikáció segítségével több telephely között ment a folyamat - hogy szinkron vagy aszinkron, arról fogalmam sincs.