ProHoster > Blogs > Administrācija > Efektīvi glabājiet simtiem miljonu mazu failu. PaŔmitināts risinājums

Efektīvi glabājiet simtiem miljonu mazu failu. PaŔmitināts risinājums

Efektīvi glabājiet simtiem miljonu mazu failu. PaŔmitināts risinājums

CienÄ«jamā kopiena! Å ajā rakstā galvenā uzmanÄ«ba tiks pievērsta simtiem miljonu mazu failu efektÄ«vai glabāŔanai un izgÅ«Å”anai. Å ajā posmā tiek piedāvāts galÄ«gais risinājums ar POSIX saderÄ«gām failu sistēmām ar pilnu atbalstu slēdzenēm, ieskaitot kopu slēdzenes, un Ŕķietami pat bez kruÄ·iem.

Tāpēc Å”im nolÅ«kam es uzrakstÄ«ju savu pielāgoto serveri.
ÄŖstenojot Å”o uzdevumu, mums izdevās atrisināt galveno problēmu un tajā paŔā laikā panākt diska vietas un operatÄ«vās atmiņas ietaupÄ«jumu, ko mÅ«su klastera failu sistēma nežēlÄ«gi patērēja. Faktiski Ŕāds failu skaits ir kaitÄ«gs jebkurai kopu failu sistēmai.

Ideja ir Ŕāda:

VienkārÅ”iem vārdiem sakot, mazie faili tiek augÅ”upielādēti caur serveri, tie tiek saglabāti tieÅ”i arhÄ«vā, kā arÄ« lasÄ«ti no tā, un lieli faili tiek novietoti blakus. Shēma: 1 mape = 1 arhÄ«vs, kopā mums ir vairāki miljoni arhÄ«vu ar maziem failiem, nevis vairāki simti miljonu failu. Un tas viss tiek Ä«stenots pilnÄ«bā, bez skriptiem vai failu ievietoÅ”anas tar/zip arhÄ«vos.

CentīŔos rakstīt īsi, jau iepriekŔ atvainojos, ja ieraksts būs garŔ.

Viss sākās ar to, ka nevarēju atrast pasaulē piemērotu serveri, kas ar HTTP protokolu saņemtos datus varētu saglabāt tieÅ”i arhÄ«vos, bez trÅ«kumiem, kas raksturÄ«gi parastajiem arhÄ«viem un objektu glabāŔanai. Un meklÄ“Å”anas iemesls bija 10 serveru Origin klasteris, kas bija izaudzis lÄ«dz lielam mērogam, kurā jau bija uzkrāti 250,000,000 XNUMX XNUMX mazu failu, un izaugsmes tendence negrasÄ«jās apstāties.

Tiem, kam nepatīk lasīt rakstus, neliela dokumentācija ir vienkārŔāka:

Å”eit Šø Å”eit.

Un docker tajā paŔā laikā, tagad ir iespēja tikai ar nginx iekŔā katram gadÄ«jumam:

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

Nākamais:

Ja failu ir daudz, ir nepiecieÅ”ami ievērojami resursi, un vissliktākais ir tas, ka daži no tiem tiek izŔķiesti. Piemēram, izmantojot klasteru failu sistēmu (Å”ajā gadÄ«jumā MooseFS), fails neatkarÄ«gi no tā faktiskā lieluma vienmēr aizņem vismaz 64 KB. Tas nozÄ«mē, ka failiem, kuru lielums ir 3, 10 vai 30 KB, diskā ir nepiecieÅ”ami 64 KB. Ja ir ceturtdaļmiljards failu, mēs zaudējam no 2 lÄ«dz 10 terabaitiem. Jaunus failus nevarēs izveidot bezgalÄ«gi, jo MooseFS ir ierobežojums: ne vairāk kā 1 miljards ar vienu katra faila repliku.

Palielinoties failu skaitam, metadatiem ir nepiecieŔams daudz RAM. Bieža liela metadatu izgāztuve arī veicina SSD disku nodilumu.

wZD serveris. Sakārtojām lietas diskos.

Serveris ir rakstÄ«ts Go. Pirmkārt, man vajadzēja samazināt failu skaitu. Kā to izdarÄ«t? ArhivÄ“Å”anas dēļ, bet Å”ajā gadÄ«jumā bez saspieÅ”anas, jo mani faili ir tikai saspiesti attēli. Talkā nāca BoltDB, kas vēl bija jānovērÅ” no trÅ«kumiem, tas ir atspoguļots dokumentācijā.

Kopumā ceturtdaļmiljarda failu vietā manā gadÄ«jumā bija palikuÅ”i tikai 10 miljoni Bolta arhÄ«vu. Ja man bÅ«tu iespēja mainÄ«t paÅ”reizējo direktoriju failu struktÅ«ru, bÅ«tu iespējams to samazināt lÄ«dz aptuveni 1 miljonam failu.

Visi mazie faili tiek iesaiņoti Bolt arhīvos, kas automātiski saņem to direktoriju nosaukumus, kuros tie atrodas, un visi lielie faili paliek blakus arhīviem; nav jēgas tos iesaiņot, tas ir pielāgojams. Mazie tiek arhivēti, lielie atstāti nemainīgi. Serveris darbojas pārredzami ar abiem.

wZD servera arhitektūra un funkcijas.

Efektīvi glabājiet simtiem miljonu mazu failu. PaŔmitināts risinājums

Serveris darbojas operētājsistēmās Linux, BSD, Solaris un OSX. Es pārbaudīju tikai AMD64 arhitektūru operētājsistēmā Linux, taču tai vajadzētu darboties ARM64, PPC64, MIPS64.

Galvenās iezīmes:

  • Daudzpavedienu veidoÅ”ana;
  • Multiserveris, kas nodroÅ”ina kļūdu toleranci un slodzes lÄ«dzsvaroÅ”anu;
  • Maksimāla pārredzamÄ«ba lietotājam vai izstrādātājam;
  • AtbalstÄ«tās HTTP metodes: GET, HEAD, PUT un DELETE;
  • LasÄ«Å”anas un rakstÄ«Å”anas uzvedÄ«bas kontrole, izmantojot klientu galvenes;
  • Atbalsts elastÄ«giem virtuālajiem saimniekiem;
  • AtbalstÄ«t CRC datu integritāti rakstot/lasot;
  • Daļēji dinamiski buferi minimālam atmiņas patēriņam un optimālai tÄ«kla veiktspējas regulÄ“Å”anai;
  • Atliktā datu blÄ«vÄ“Å”ana;
  • Turklāt failu migrÄ“Å”anai, neapturot pakalpojumu, tiek piedāvāts vairāku pavedienu arhivētājs wZA.

Reāla pieredze:

Es diezgan ilgu laiku izstrādāju un testēju serveri un arhivētāju uz dzÄ«vajiem datiem, tagad tas veiksmÄ«gi darbojas klasterÄ«, kurā ir 250,000,000 15,000,000 10 mazu failu (bildes), kas atrodas 2 2 XNUMX direktorijās uz atseviŔķiem SATA diskdziņiem. XNUMX serveru klasteris ir Origin serveris, kas instalēts aiz CDN tÄ«kla. Lai to apkalpotu, tiek izmantoti XNUMX Nginx serveri + XNUMX wZD serveri.

Tiem, kas nolemj izmantot Å”o serveri, bÅ«tu prātÄ«gi pirms lietoÅ”anas izplānot direktoriju struktÅ«ru, ja tāda ir. Ä»aujiet man uzreiz izdarÄ«t atrunu, ka serveris nav paredzēts visu sabāzt 1 Bolt arhÄ«vā.

Veiktspējas pārbaude:

Jo mazāks ir zip faila izmērs, jo ātrāk ar to tiek veiktas GET un PUT darbÄ«bas. SalÄ«dzināsim kopējo HTTP klienta rakstÄ«Å”anas laiku ar parastajiem failiem un Bolt arhÄ«viem, kā arÄ« lasÄ«Å”anu. Tiek salÄ«dzināts darbs ar failiem, kuru izmēri ir 32 KB, 256 KB, 1024 KB, 4096 KB un 32768 KB.

Strādājot ar Bolt arhÄ«viem, tiek pārbaudÄ«ta katra faila datu integritāte (tiek izmantots CRC), pirms ierakstÄ«Å”anas un arÄ« pēc ierakstÄ«Å”anas notiek nolasÄ«Å”ana un pārrēķins lidojumā, tas likumsakarÄ«gi ievieÅ” aizkavÄ“Å”anos, bet galvenais ir datu droŔība.

Es veicu veiktspējas testus SSD diskdziņiem, jo ā€‹ā€‹ā€‹ā€‹SATA disku testi neuzrāda skaidru atŔķirÄ«bu.

Diagrammas, kuru pamatā ir testÄ“Å”anas rezultāti:

Efektīvi glabājiet simtiem miljonu mazu failu. PaŔmitināts risinājums
Efektīvi glabājiet simtiem miljonu mazu failu. PaŔmitināts risinājums

Kā redzat, maziem failiem lasÄ«Å”anas un rakstÄ«Å”anas laika atŔķirÄ«ba starp arhivētajiem un nearhivētajiem failiem ir neliela.

Pārbaudot lasÄ«Å”anas un rakstÄ«Å”anas failus, kuru lielums ir 32 MB, mēs iegÅ«stam pavisam citu attēlu:

Efektīvi glabājiet simtiem miljonu mazu failu. PaŔmitināts risinājums

Laika starpÄ«ba starp failu nolasÄ«Å”anu ir 5ā€“25 ms robežās. Ar ierakstÄ«Å”anu viss ir sliktāk, atŔķirÄ«ba ir aptuveni 150 ms. Bet Å”ajā gadÄ«jumā nav nepiecieÅ”ams augÅ”upielādēt lielus failus; vienkārÅ”i nav jēgas to darÄ«t, tie var dzÄ«vot atseviŔķi no arhÄ«viem.

*Tehniski Ŕo serveri var izmantot uzdevumiem, kuriem nepiecieŔams NoSQL.

Pamatmetodes darbam ar wZD serveri:

Parasta faila ielāde:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

Faila augÅ”upielāde Bolt arhÄ«vā (ja netiek pārsniegts servera parametrs fmaxsize, kas nosaka maksimālo faila izmēru, ko var iekļaut arhÄ«vā; ja tas tiek pārsniegts, fails tiks augÅ”upielādēts kā parasti blakus arhÄ«vam):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

Faila lejupielāde (ja diskā un arhÄ«vā ir faili ar vienādiem nosaukumiem, tad lejupielādes laikā prioritāte pēc noklusējuma tiek pieŔķirta nearhivētajam failam):

curl -o test.jpg http://localhost/test/test.jpg

Faila lejupielāde no Bolt arhīva (piespiedu kārtā):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

Citu metožu apraksti ir dokumentācijā.

wZD dokumentācija
wZA dokumentācija

Serveris paÅ”laik atbalsta tikai HTTP protokolu; tas vēl nedarbojas ar HTTPS. ArÄ« POST metode netiek atbalstÄ«ta (vēl nav izlemts, vai tā ir vajadzÄ«ga vai nē).

KurÅ” iedziļinās pirmkodā, tas tur atradÄ«s butterscotch, ne visiem tas patÄ«k, bet es galveno kodu nesaistÄ«ju ar tÄ«mekļa ietvara funkcijām, izņemot pārtraukumu apstrādātāju, tāpēc nākotnē varÄ“Å”u ātri pārrakstÄ«t gandrÄ«z jebkuram dzinējs.

Darīt:

  • Sava replikatora un izplatÄ«tāja + Ä£eogrāfiskā atraÅ”anās vieta, lai to varētu izmantot lielās sistēmās bez klasteru failu sistēmām (Viss pieauguÅ”ajiem)
  • Iespēja pilnÄ«bā atgriezt metadatus, ja tie ir pilnÄ«bā pazaudēti (ja tiek izmantots izplatÄ«tājs)
  • Vietējais protokols iespējai izmantot pastāvÄ«gus tÄ«kla savienojumus un draiverus dažādām programmÄ“Å”anas valodām
  • Papildu iespējas NoSQL komponenta lietoÅ”anai
  • Dažādu veidu kompresijas (gzip, zstd, snappy) failiem vai vērtÄ«bām Bolt arhÄ«vos un parastajiem failiem
  • Dažādu veidu failu vai vērtÄ«bu Å”ifrÄ“Å”ana Bolt arhÄ«vos un parastajiem failiem
  • Aizkavēta servera puses video konvertÄ“Å”ana, tostarp GPU

Man ir viss, ceru, ka Å”is serveris kādam noderēs, BSD-3 licence, dubultās autortiesÄ«bas, jo ja nebÅ«tu uzņēmuma, kurā es strādāju, serveris nebÅ«tu rakstÄ«ts. Es esmu vienÄ«gais izstrādātājs. BÅ«Å”u pateicÄ«gs par atrastajām kļūdām un funkciju pieprasÄ«jumiem.

Avots: www.habr.com

Pievieno komentāru