Հարգելի համայնք, այս հոդվածը կկենտրոնանա հարյուր միլիոնավոր փոքր ֆայլերի արդյունավետ պահպանման և առբերման վրա: Այս փուլում վերջնական լուծումն առաջարկվում է POSIX-ի հետ համատեղելի ֆայլային համակարգերի համար՝ կողպեքների ամբողջական աջակցությամբ, ներառյալ կլաստերային կողպեքները, և կարծես թե նույնիսկ առանց հենակների:
Այսպիսով, ես այս նպատակով գրեցի իմ սեփական սերվերը:
Այս առաջադրանքի իրականացման ընթացքում մեզ հաջողվեց լուծել հիմնական խնդիրը և միևնույն ժամանակ խնայել սկավառակի տարածություն և RAM, որը մեր կլաստերային ֆայլային համակարգը անխնա սպառում էր: Իրականում, նման թվով ֆայլեր վնասակար են ցանկացած կլաստերային ֆայլային համակարգի համար:
Գաղափարը սա է.
Պարզ խոսքերով, փոքր ֆայլերը վերբեռնվում են սերվերի միջոցով, դրանք պահվում են անմիջապես արխիվում, ինչպես նաև ընթերցվում են դրանից, և մեծ ֆայլերը տեղադրվում են կողք կողքի: Սխեման՝ 1 թղթապանակ = 1 արխիվ, ընդհանուր առմամբ մենք ունենք մի քանի միլիոն արխիվ փոքր ֆայլերով, և ոչ մի քանի հարյուր միլիոն ֆայլ։ Եվ այս ամենն իրականացվում է ամբողջությամբ՝ առանց որևէ սկրիպտի կամ tar/zip արխիվներում ֆայլեր դնելու։
Կփորձեմ կարճ լինել, նախապես ներողություն եմ խնդրում, եթե գրառումը երկար է:
Ամեն ինչ սկսվեց նրանից, որ ես չկարողացա աշխարհում գտնել համապատասխան սերվեր, որը կարող էր պահպանել HTTP արձանագրության միջոցով ստացված տվյալները անմիջապես արխիվներում, առանց սովորական արխիվների և օբյեկտների պահպանման թերությունների: Իսկ որոնումների պատճառը մեծ մասշտաբի հասած 10 սերվերներից կազմված Origin կլաստերն էր, որում արդեն կուտակվել էին 250,000,000 XNUMX XNUMX փոքր ֆայլեր, իսկ աճի միտումը չէր պատրաստվում կանգ առնել։
Նրանց համար, ովքեր չեն սիրում հոդվածներ կարդալ, մի փոքր փաստաթղթավորումն ավելի հեշտ է.
и .
Եվ միևնույն ժամանակ docker, այժմ կա տարբերակ միայն nginx-ով ներսում ամեն դեպքում.
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdՀաջորդը
Եթե ֆայլերը շատ են, զգալի ռեսուրսներ են անհրաժեշտ, իսկ ամենավատն այն է, որ դրանցից մի քանիսը վատնում են: Օրինակ՝ կլաստերային ֆայլային համակարգ օգտագործելիս (այս դեպքում՝ MooseFS), ֆայլը, անկախ իր իրական չափից, միշտ զբաղեցնում է առնվազն 64 ԿԲ։ Այսինքն՝ 3, 10 կամ 30 ԿԲ չափի ֆայլերի համար սկավառակի վրա պահանջվում է 64 ԿԲ։ Եթե կան քառորդ միլիարդ ֆայլեր, մենք կորցնում ենք 2-ից 10 տերաբայթ: Անվերջ հնարավոր չի լինի ստեղծել նոր ֆայլեր, քանի որ MooseFS-ն ունի սահմանափակում՝ ոչ ավելի, քան 1 միլիարդ յուրաքանչյուր ֆայլի մեկ կրկնօրինակով:
Քանի որ ֆայլերի քանակը մեծանում է, մետատվյալների համար անհրաժեշտ է շատ RAM: Մեծ մետատվյալների հաճախակի արտանետումները նույնպես նպաստում են SSD կրիչների մաշվածությանը:
wZD սերվեր: Մենք իրերը կարգի ենք դնում սկավառակների վրա։
Սերվերը գրված է Go-ում: Առաջին հերթին ինձ անհրաժեշտ էր նվազեցնել ֆայլերի քանակը։ Ինչպե՞ս դա անել: Արխիվացման շնորհիվ, բայց այս դեպքում առանց սեղմման, քանի որ իմ ֆայլերը պարզապես սեղմված նկարներ են։ Օգնության եկավ BoltDB-ն, որը դեռ պետք է վերացվեր իր թերություններից, սա արտացոլված է փաստաթղթերում:
Ընդհանուր առմամբ, քառորդ միլիարդ ֆայլի փոխարեն, իմ դեպքում մնացել էր ընդամենը 10 միլիոն Bolt արխիվ։ Եթե ես հնարավորություն ունենայի փոխել ընթացիկ գրացուցակի ֆայլի կառուցվածքը, հնարավոր կլիներ այն կրճատել մինչև մոտավորապես 1 միլիոն ֆայլ:
Բոլոր փոքր ֆայլերը փաթեթավորվում են Bolt-ի արխիվներում, որոնք ավտոմատ կերպով ստանում են այն գրացուցակների անունները, որոնցում գտնվում են, և բոլոր մեծ ֆայլերը մնում են արխիվների կողքին, դրանք փաթեթավորելը իմաստ չունի, սա հարմարեցված է: Փոքրերը արխիվացվում են, մեծերը թողնվում են անփոփոխ։ Սերվերը երկուսի հետ էլ թափանցիկ է աշխատում:
wZD սերվերի ճարտարապետությունը և առանձնահատկությունները:
Սերվերը գործում է Linux, BSD, Solaris և OSX օպերացիոն համակարգերով: Ես փորձարկեցի միայն AMD64 ճարտարապետության համար Linux-ով, բայց այն պետք է աշխատի ARM64, PPC64, MIPS64-ի համար:
Հիմնական հատկանիշները:
- Multithreading;
- Մուլտիսերվեր, որն ապահովում է սխալների հանդուրժողականություն և բեռի հավասարակշռում;
- Օգտագործողի կամ մշակողի համար առավելագույն թափանցիկություն;
- Աջակցվող HTTP մեթոդներ՝ GET, HEAD, PUT և DELETE;
- Հաճախորդի վերնագրերի միջոցով կարդալու և գրելու վարքագծի վերահսկում;
- Աջակցություն ճկուն վիրտուալ հյուրընկալողներին;
- Աջակցել CRC տվյալների ամբողջականությանը գրելու/կարդալու ժամանակ;
- Կիսադինամիկ բուֆերներ հիշողության նվազագույն սպառման և ցանցի աշխատանքի օպտիմալ թյունինգի համար;
- Հետաձգված տվյալների խտացում;
- Բացի այդ, առաջարկվում է wZA բազմաշերտ արխիվատոր՝ առանց ծառայությունը դադարեցնելու ֆայլերը տեղափոխելու համար:
Իրական փորձ.
Ես բավականին երկար ժամանակ մշակում և փորձարկում էի սերվերը և արխիվատորը կենդանի տվյալների վրա, այժմ այն հաջողությամբ գործում է կլաստերի վրա, որը ներառում է 250,000,000 փոքր ֆայլեր (նկարներ), որոնք տեղակայված են 15,000,000 դիրեկտորիաներում առանձին SATA կրիչներով: 10 սերվերների կլաստերը ծագման սերվեր է, որը տեղադրված է CDN ցանցի հետևում: Այն սպասարկելու համար օգտագործվում են 2 Nginx սերվեր + 2 wZD սերվեր։
Նրանց համար, ովքեր որոշում են օգտագործել այս սերվերը, խելամիտ կլինի օգտագործելուց առաջ պլանավորել գրացուցակի կառուցվածքը, եթե կիրառելի է: Թույլ տվեք անմիջապես վերապահել, որ սերվերը նախատեսված չէ ամեն ինչ խցկել 1 Bolt արխիվի մեջ:
Կատարման փորձարկում.
Որքան փոքր է zipped ֆայլի չափը, այնքան ավելի արագ են կատարվում GET և PUT գործողությունները դրա վրա: Եկեք համեմատենք HTTP հաճախորդի գրելու ընդհանուր ժամանակը սովորական ֆայլերի և Bolt արխիվների հետ, ինչպես նաև կարդալու համար: Համեմատվում է 32 ԿԲ, 256 ԿԲ, 1024 ԿԲ, 4096 ԿԲ և 32768 ԿԲ չափերի ֆայլերի հետ աշխատանքը։
Bolt-ի արխիվների հետ աշխատելիս ստուգվում է յուրաքանչյուր ֆայլի տվյալների ամբողջականությունը (օգտագործվում է CRC), նախքան ձայնագրումը, ինչպես նաև ձայնագրումից հետո տեղի է ունենում թռիչքի ընթերցում և վերահաշվարկում, դա, բնականաբար, բերում է ուշացումների, բայց հիմնականը տվյալների անվտանգությունն է:
Ես կատարեցի կատարողականության թեստեր SSD կրիչների վրա, քանի որ SATA կրիչների վրա փորձարկումները հստակ տարբերություն չեն ցույց տալիս:
Թեստավորման արդյունքների վրա հիմնված գրաֆիկներ.
Ինչպես տեսնում եք, փոքր ֆայլերի դեպքում արխիվացված և չարխիվացված ֆայլերի միջև կարդալու և գրելու ժամանակի տարբերությունը փոքր է:
Մենք բոլորովին այլ պատկեր ենք ստանում 32 ՄԲ չափի ֆայլեր կարդալու և գրելու ժամանակ.
Ֆայլերի ընթերցման ժամանակի տարբերությունը 5-25 ms-ի սահմաններում է: Ձայնագրման դեպքում ամեն ինչ ավելի վատ է, տարբերությունը մոտ 150 ms է: Բայց այս դեպքում մեծ ֆայլեր վերբեռնելու կարիք չկա, ուղղակի իմաստ չունի դա անել, նրանք կարող են ապրել արխիվներից առանձին:
*Տեխնիկապես, դուք կարող եք օգտագործել այս սերվերը NoSQL պահանջող առաջադրանքների համար:
wZD սերվերի հետ աշխատելու հիմնական մեթոդները.
Սովորական ֆայլի բեռնում.
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgՖայլի վերբեռնումը Bolt արխիվում (եթե սերվերի fmaxsize պարամետրը, որը որոշում է ֆայլի առավելագույն չափը, որը կարող է ներառվել արխիվում, չի գերազանցվում.
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgՖայլի ներբեռնում (եթե սկավառակի վրա և արխիվում կան նույն անուններով ֆայլեր, ապա ներբեռնելիս առաջնահերթությունը լռելյայն տրվում է չարխիվացված ֆայլին).
curl -o test.jpg http://localhost/test/test.jpgՖայլի ներբեռնում Bolt արխիվից (պարտադիր).
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgԱյլ մեթոդների նկարագրությունները ներկայացված են փաստաթղթերում:
Սերվերը ներկայումս աջակցում է միայն HTTP արձանագրությանը, այն դեռ չի աշխատում HTTPS-ի հետ: POST մեթոդը նույնպես չի ապահովվում (դեռ որոշված չէ՝ անհրաժեշտ է, թե ոչ)։
Ով փորփրում է սկզբնաղբյուրը, այնտեղ կգտնի կարագ, ոչ բոլորին է դուր գալիս, բայց ես հիմնական կոդը չեմ կապել վեբ շրջանակի գործառույթների հետ, բացառությամբ ընդհատումների մշակողի, այնպես որ ապագայում ես կարող եմ արագ վերաշարադրել այն գրեթե ցանկացածի համար: շարժիչ.
Անել:
- Ձեր սեփական վերարտադրողի և դիստրիբյուտորի մշակում + աշխարհագրություն՝ առանց կլաստերային ֆայլային համակարգերի խոշոր համակարգերում օգտագործման հնարավորության համար (Ամեն ինչ մեծահասակների համար)
- Մետատվյալների ամբողջական հակադարձ վերականգնման հնարավորությունը, եթե դրանք ամբողջությամբ կորչվեն (եթե օգտագործվում է դիստրիբյուտոր)
- Մայրենի արձանագրություն՝ ծրագրավորման տարբեր լեզուների համար մշտական ցանցային կապեր և դրայվերներ օգտագործելու ունակության համար
- NoSQL բաղադրիչի օգտագործման առաջադեմ հնարավորություններ
- Տարբեր տեսակի սեղմումներ (gzip, zstd, snappy) ֆայլերի կամ արժեքների համար Bolt արխիվներում և սովորական ֆայլերի համար
- Ֆայլերի կամ արժեքների տարբեր տեսակների կոդավորումը Bolt արխիվների և սովորական ֆայլերի համար
- Հետաձգված սերվերի կողմից տեսանյութերի փոխարկում, ներառյալ GPU-ում
Ես ամեն ինչ ունեմ, հուսով եմ այս սերվերը ինչ-որ մեկին օգտակար կլինի, BSD-3 լիցենզիա, կրկնակի հեղինակային իրավունք, քանի որ եթե չլիներ այն ընկերությունը, որտեղ ես աշխատում եմ, սերվերը չէր գրվի: Ես միակ մշակողն եմ։ Ես երախտապարտ կլինեմ ձեր հայտնաբերած սխալների և գործառույթների հարցումների համար:
Source: www.habr.com