Kedves Közösség! Ez a cikk több százmillió kis fájlok hatékony tárolására és visszakeresésére összpontosít. Ebben a szakaszban a végső megoldást a POSIX-kompatibilis fájlrendszerekre javasoljuk, amelyek teljes mértékben támogatják a zárakat, beleértve a fürtzárakat is, és látszólag még mankók nélkül is.
Így erre a célra saját egyedi szervert írtam.
A feladat megvalósítása során sikerült megoldanunk a fő problémát, egyúttal lemezterületet és RAM-ot is megtakarítottunk, amit a fürt fájlrendszerünk kíméletlenül felemésztett. Valójában ilyen számú fájl káros minden fürtözött fájlrendszerre.
Az ötlet a következő:
Egyszerűen fogalmazva, a kis fájlok a szerveren keresztül kerülnek feltöltésre, közvetlenül az archívumba kerülnek, és onnan is olvashatók, a nagy fájlok pedig egymás mellé kerülnek. Séma: 1 mappa = 1 archívum, összesen több millió archívumunk van kis fájlokkal, és nem több százmillió fájl. És mindez teljes mértékben, minden szkript vagy fájlok tar/zip archívumba való elhelyezése nélkül valósul meg.
Igyekszem rövidre fogni, előre is elnézést kérek, ha hosszú lesz a bejegyzés.
Az egész azzal kezdődött, hogy nem találtam a világon megfelelő szervert, amely a HTTP protokollon keresztül kapott adatokat közvetlenül archívumba menthetné, a hagyományos archívumokban és objektumtárolásban rejlő hátrányok nélkül. A keresés oka pedig a 10 szerverből álló, nagyra nőtt Origin klaszter volt, amelyben már 250,000,000 XNUMX XNUMX kis fájl gyűlt össze, és a növekedési trend nem áll meg.
Azok számára, akik nem szeretnek cikkeket olvasni, egyszerűbb egy kis dokumentáció:
и .
És egyben a docker is, most már csak nginx-el van lehetőség arra az esetre:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdKövetkező:
Ha sok a fájl, akkor jelentős erőforrásokra van szükség, és a legrosszabb az, hogy ezek egy része elpazarol. Például fürtözött fájlrendszer (jelen esetben MooseFS) használatakor a fájl a tényleges méretétől függetlenül mindig legalább 64 KB-ot foglal el. Vagyis 3, 10 vagy 30 KB méretű fájlokhoz 64 KB szükséges a lemezen. Ha negyedmilliárd fájl van, akkor 2-10 terabájtot veszítünk. Nem lehet a végtelenségig új fájlokat létrehozni, mivel a MooseFS-nek van egy korlátozása: legfeljebb 1 milliárd minden fájl egy replikájával.
A fájlok számának növekedésével sok RAM-ra van szükség a metaadatokhoz. A gyakori nagy metaadat-kiíratások szintén hozzájárulnak az SSD-meghajtók elhasználódásához.
wZD szerver. A lemezeken rendet rakunk.
A szerver Go nyelven van írva. Először is csökkentenem kellett a fájlok számát. Hogyan kell csinálni? Archiválás miatt, de jelen esetben tömörítés nélkül, mivel a fájljaim csak tömörített képek. A BoltDB jött a segítségre, amit még ki kellett küszöbölni a hiányosságaiból, ezt tükrözi a dokumentáció.
Összességében negyedmilliárd fájl helyett esetemben csak 10 millió Bolt-archívum maradt. Ha lehetőségem lenne megváltoztatni a jelenlegi könyvtárfájl-struktúrát, akkor azt megközelítőleg 1 millió fájlra lehetne csökkenteni.
Minden kis fájl be van csomagolva a Bolt archívumba, amely automatikusan megkapja a könyvtárak nevét, amelyben található, és minden nagy fájl az archívum mellett marad, nincs értelme becsomagolni, ez testreszabható. A kicsiket archiváljuk, a nagyokat változatlanul hagyjuk. A szerver mindkettővel átláthatóan működik.
A wZD szerver felépítése és jellemzői.
A szerver Linux, BSD, Solaris és OSX operációs rendszerek alatt működik. Csak AMD64 architektúrát teszteltem Linux alatt, de működnie kell ARM64, PPC64, MIPS64 esetén.
Főbb jellemzői:
- Többszálú;
- Többszerver, amely hibatűrést és terheléselosztást biztosít;
- Maximális átláthatóság a felhasználó vagy a fejlesztő számára;
- Támogatott HTTP metódusok: GET, HEAD, PUT és DELETE;
- Az olvasási és írási viselkedés kezelése ügyféloldali fejléceken keresztül;
- Nagymértékben konfigurálható virtuális gazdagépek támogatása;
- Támogatja a CRC adatok integritását írás/olvasás közben;
- Féldinamikus pufferek a minimális memóriafogyasztás és az optimális hálózati teljesítmény hangolás érdekében;
- Elhalasztott adattömörítés;
- Ezenkívül egy többszálú wZA archiváló is elérhető a fájlok áttelepítéséhez a szolgáltatás leállítása nélkül.
Valódi tapasztalat:
A szervert és az archiválót elég régóta fejlesztem és tesztelem élő adatokon, mostanra sikeresen működik egy 250,000,000 15,000,000 10 kisméretű fájlt (képet) tartalmazó fürtön, amely külön SATA meghajtókon 2 2 XNUMX könyvtárban található. A XNUMX kiszolgálóból álló fürt egy CDN-hálózat mögé telepített Origin-kiszolgáló. Kiszolgálásához XNUMX Nginx szerver + XNUMX wZD szerver használható.
Azok számára, akik úgy döntenek, hogy ezt a szervert használják, bölcs dolog, ha használat előtt megtervezik a címtárszerkezetet, ha lehetséges. Azonnal le kell foglalnom, hogy a szervernek nem az a célja, hogy mindent egy 1 Bolt archívumba zsúfoljon.
Teljesítményfelmérés:
Minél kisebb a tömörített fájl mérete, annál gyorsabban hajtják végre rajta a GET és PUT műveleteket. Hasonlítsuk össze a HTTP-kliens írásának teljes idejét a normál fájlokhoz és Bolt-archívumokhoz, valamint az olvasáshoz. A 32 KB, 256 KB, 1024 KB, 4096 KB és 32768 KB méretű fájlokkal végzett munka összehasonlítása történik meg.
A Bolt archívumokkal végzett munka során minden fájl adatsértetlenségét ellenőrzik (CRC-t használnak), rögzítés előtt és rögzítés után is menet közbeni kiolvasás és újraszámítás történik, ez természetesen késéseket okoz, de a lényeg az adatbiztonság.
Teljesítményteszteket végeztem SSD meghajtókon, mivel a SATA meghajtókon végzett tesztek nem mutatnak egyértelmű különbséget.
Grafikonok a vizsgálati eredmények alapján:
Amint láthatja, kisméretű fájlok esetén kicsi a különbség az olvasási és írási idők között az archivált és a nem archivált fájlok között.
Teljesen más képet kapunk a 32 MB méretű olvasási és írási fájlok tesztelésekor:
A fájlok olvasása közötti időkülönbség 5-25 ms között van. A felvételnél rosszabb a helyzet, kb 150 ms a különbség. De ebben az esetben nincs szükség nagy fájlok feltöltésére, egyszerűen nincs értelme, külön élhetnek az archívumoktól.
*Technikailag ezt a szervert NoSQL-t igénylő feladatokhoz használhatja.
A wZD szerverrel való munka alapvető módszerei:
Normál fájl betöltése:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgFájl feltöltése a Bolt archívumba (ha nem lépi túl az archívumba helyezhető maximális fájlméretet meghatározó fmaxsize szerverparamétert; túllépése esetén a fájl a szokásos módon az archívum mellé kerül feltöltésre):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgFájl letöltése (ha azonos nevű fájlok vannak a lemezen és az archívumban, akkor letöltéskor alapértelmezés szerint az archiválatlan fájl kap prioritást):
curl -o test.jpg http://localhost/test/test.jpgFájl letöltése a Bolt archívumból (kényszerítve):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgA többi módszer leírása a dokumentációban található.
A szerver jelenleg csak a HTTP protokollt támogatja, HTTPS-sel még nem működik. A POST módszer szintén nem támogatott (még nem dőlt el, hogy szükség van-e rá vagy sem).
Aki beleás a forráskódba, az ott találja a butterscotch-ot, nem mindenki szereti, de a fő kódot nem kötöttem a webes keretrendszer funkcióihoz, kivéve a megszakításkezelőt, így a jövőben gyorsan át tudom írni szinte bármelyikre motor.
Feladat:
- Saját replikátor és disztribútor fejlesztése + geo a nagy rendszerekben való használathoz fürt fájlrendszerek nélkül (Minden felnőtteknek)
- A metaadatok teljes visszaállításának lehetősége, ha azok teljesen elvesztek (terjesztő használata esetén)
- Natív protokoll az állandó hálózati kapcsolatok és illesztőprogramok használatára a különböző programozási nyelvekhez
- Speciális lehetőségek a NoSQL komponens használatához
- Különböző típusú tömörítések (gzip, zstd, snappy) a Bolt archívumokban lévő fájlokhoz vagy értékekhez, valamint normál fájlokhoz
- Különböző típusú titkosítás a Bolt archívumokban lévő fájlokhoz vagy értékekhez és a normál fájlokhoz
- Késleltetett szerveroldali videokonverzió, beleértve a GPU-t is
Mindenem megvan, remélem valakinek hasznos lesz ez a szerver, BSD-3 licenc, dupla szerzői jog, hiszen ha nem lenne cég ahol dolgozom, akkor nem írták volna meg a szervert. Én vagyok az egyetlen fejlesztő. Hálás lennék az esetleges hibákért és funkciókra vonatkozó kérésekért.
Forrás: will.com