2. Fórumok
  3. PC, mini PC, barebone, szerver
  4. Megjelent a Fujitsu flash-alapú szupertárolója
Keresés

Új hozzászólás Aktív témák

  • #28 #06658560 törölt tag tecsu #27
    Új Válasz #28
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    #06658560

    törölt tag

    válasz tecsu #27 üzenetére

    Mondok egy példát.
    Ülésfejlesztés járműiparban. Van egy autó, mondjuk Ford Transit. Az összes változatában van 150 ülésvariáció. Ezekhez a csapatban van beszerző, sales, gyártásfolyamat tervező, prototípus koordinátor, FMEA koordinátor, programmanager, lead engineer, tervezőmérnök. Az összes ülésre többen vannak. A BOM Excelben van tárolva, képekkel minden alkatrészről, összeállításról. Ennyi üléshez van vagy tizenöt Excel file. Ezt módosítja gyakorlatilag mindenki, aki fenn fel lett sorolva. A file ugyan adatbázisban van, de ahhoz csak a mérnökök férnek hozzá. Ezért kell lokális másolat. E mellé vannak 3D pdf modellek minden ülésről, minden alkatrészről és részösszeállításról. Egy ülésben van vagy kétszáz ilyen. Plusz DFMEA és PFMEA exportok excelbe, PPAP, Control Plan, QOP, Cost break down, timing, Open Issues, stb. Na, szerinted mennyire jó ötlet mindent lokálisan tárolni, a helyett, hogy van egy elő dokumentum mindenből, mellette archív mappa, s ahhoz nyúl mindenki?

  • #33 rudi nagyúr tecsu #27
    Új Válasz #33
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz tecsu #27 üzenetére

    Honnan jön ide az adatbázis? Szerintem nagyon elbeszélünk egymás mellett. Angol példát fordítsam le, nem jött át?

    A Fujitsu és hasonló kaliberű vállalatok az otthoni júzertől a Google szintű mega tárhely igénylőkig mindenféle formátummal és felhasználással foglalkoznak, van 1-2 fiókos házi NAS-uk és van temérdek rack alakpú gépük, amiben akár Skylake alapú Xeon is dolgozhat, nem beszélve az olyanokról, ahol a tároló rackek szekrényét külön szerver "hajtja meg".

    Rengetegféle adatstruktúra és tárolási stratégia létezik náluk, amiknek a megismerése és a megfelelő implementálása külön szakma. Mondok egy kiragadott példát, de nem azért hogy elkezdj a részleteibe beleturkálni, hanem hogy hátha megvilágosodsz belőle, milről lehet itt szó:

    Legyen az az igény, hogy egy 20 tagú fejlesztőcsapat dolgozik ugyanazokon a terveken (ezek lehetnek 3d modellek, prezentációk, nagyfelbontású képek, akármik, ez lényegtelen) heti szinten 1 TB adatot generálva. És szeretnénk biztonságban tudni a gépeki fejenként 8 TB-os merevlemezét, illetve szeretnénk, ha az éppen aktuális verziókból kb. 1 TB adat minden csoporttag által a legkisebb késleltetéssel elérhetőek legyenek.

    Mezei ember úgy állna neki a dolognak, hogy hozzunk össze egy tárolót, amire rá lehet menteni mind a 20 emberke 8 TB-os merevlemezéből a három legutóbbi teljes állapotot, ergo kell 20 x 8 x 3 = 480 TB. Meg kell valami 1 TB gyors online elérés is - nyilvános vagy privát felhőben. Végig tiszta tárhelyben gondolkodunk, ahol az adatbiztonságot RAID6 tömb oldja meg.

    Kicsit okosabban már csak inkrementális mentést csinálnak minden júzernél, amihez erősebb hardver kell a NAS-ban, de nem kell háromszoros tárhely, mert mentésenéként a júzereknél kb. 1 TB a frissülő adat. Így az állás 20 x 8 x 1,2 = 192 TB meg az 1 TB felhős tár.

    Rákapcsolva erre még a deduplikációt rájövünk, hogy a 20 fejlesztő ugyanazon az adattömegen dolgozik, ha Pista gépe bekakál, akkor lényegében Jóska mentéséből is újra tudjuk húzni az adatait. Kis analízis, kis elemzés és hopp máris nem kell 20 külön ember, hanem mondjuk csak 5 mentése 4:1 deduplikációs arány. Ergo tárhelyben 5 x 8 x 1,2 = 48 TB. Meg a felhős 1 TB.

    Következő szintként elkezdhetjük elemezni, hogy a júzerek a 8 TB-ból mennyit használnak valójában. Ha kijön, hogy átlagban csak 4 TB-ot, akkor akkor felezhető a tárhely és csinálhatunk egy olyan storage poolt, amiben minden júzerre 4 TB-tal számolnak, de ha valaki túlmegy rajta, akkor dinamikusan kap teret más júzer nem használt helyéből. Az ilyen rednszerek tudnak jelezni, amikor fogy a valódi tárhely és kvázi pillanatok műve rájuk kapcsolni még egy csomó adattárat. Ergo 5 x 4 x 1,2 = 24 TB-nál tartunk. Meg az 1 TB felhő.

    Bár a példámhoz nem igazán illik, inkább valami gyors, sok lekéréses adatbázishoz passzolna, de a felhős 1 TB helyett betehetünk a saját tárolónkba 2 TB-os SSD-t. Bedobva ezt a gyors táhelyet a storage poolba használhatjuk gyorsítótárnak a júzerek inkrementális mentési folyamataihoz. Sőt, lehet nem is kell majd használni, mert csinálható úgy, hogy amikor Jóska inkrementális mentését csináljuk, akkor összehasonlítjuk az 1 TB-os felhős adatcsomaggal a munkáját, és ami azonos verziójú, azt nem ráncigáljuk át a hálózaton, hanem szépen a sokkal gyorsabb storage poolban másolgatun, akár időben eltolva olyankorra, amikor kisebb a tároló terhelése.

    És még ezer apró finomítás, amihez nekem nem elég mélyek az ismereteim ;)

    [ Szerkesztve ]

    Resistance Is Futile. You will be assimilated!

Új hozzászólás Aktív témák