Հարգելի համայնք, այս հոդվածը dedicada լինելու է հարյուր միլիոնավոր փոքր ֆայլերի արդյունավետ պահեստավորմանը և փոխանցմանը: Այս փուլում առաջարկվում է վերջնական լուծում POSIX համատեղելի ֆայլային համակարգերի համար՝ լիարժեք լոկալացման աջակցությամ, ներառյալ կլաստերայինները, և կարծես թե արդեն առանց որևէ զառանցանքի:
Ուստի, այս նպատակով ես գրել եմ իմ սեփական պրոֆեսիոնալ սերվերը:
Այս խնդիրը իրականացնելիս հաջողվեց լուծել հիմնական խնդիրը և միաժամանակ խնայել արգանակային և օպերատիվ հիշողություն, որը անխնայորեն սպառում էր մեր կլաստերային ֆայլային համակարգը: Իրականում, այդպիսի մեծ թվով ֆայլերը վնասակար են ցանկացած կլաստերային ֆայլային համակարգի համար:
Հիմնական գաղափարը հետևյալն է:
Եվվին, սերվերի միջոցով փոքր ֆայլերը փոխանցվում են, նրանք ուղիղ պահպանվում են արխիվում, և նմանապես ընթերցվում են այնտեղից, իսկ մեծ ֆայլերն ուղարկվում են կողք։ Սքեմա՝ 1 թեք ու 1 արխիվ, արդյունքում մենք ունենում ենք մի քանի միլիոն արխիվներ փոքր ֆայլերով, այլ ոչ թե մի քանի հարյուր միլիոն ֆայլեր: Եվ ամեն κάτι ընկերական է իրականացվում, առանց ցանկացած սցենարներ և ֆայլերի բաժանումների tar/zip արխիվների մեջ:
Պործելու եմ ներկայացնել ավելի կարճ, նախօրոք ներողություն եմ խնդրում, եթե հրապարակումն էներգիայով լինի:
Այլանդակվել է նրանից, որ ես խնդիրներ գտա աշխարհում, որը կարող է պահպանել տվյալները HTTP պրոտոկոլի միջոցով ուղիղ արխիվներում՝ այնպես, որ չեն լինի սովորական արխիվների կամ օբյեկտային հ ذخ687ե, իսկ որոնման պատճառը եղել է մեծածավալ լայնակերտում գտնվող արեգակ կլաստեր, որը բաղկացած է 10 սերվերից, որտեղ կուտակված է արդեն 250,000,000 փոքր ֆայլեր, և աճի միտումը դեռ չի դադարում:
Այն մարդկանց համար, ովքեր չեն սիրում հոդվածներ կարդալ և փոքրիկ փաստաթղթադրամ բոլորը ավելի հեշտ:
և .
Եվ 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 KB: Այսինքն, 3, 10 կամ 30 KB չափսով ֆայլերի համար дисկում պահանջվում է 64 KB: თუ ֆայլերի թիվը քառորդ միլիար է, մենք կորցնում ենք 2-ից 10 տերաբայթ: Անսահմանակի վերջի նոր ֆայլեր ստեղծելը չի լինի հնարավոր, քանի որ այն MooseFS-ում կա սահմանափակում՝ չպետք է գերազանցի 1 միլիարդ մեկ պատճենի յուրաքանչյուր ֆայլի:
Ֆայլերի քանակը ավելանալով՝ անհրաժեշտ է շատ օպերատիվ հիշողություն մետատվDatos , ինչպես նաև հաճախակի մեծ մետադիտ/thiles մեծ հոգնածության ընթերցման SSD-զամբոյներով:
wZD սերվեր: Համակարգում ենք կարգը դիսկերում:
Սերվերը գրել է Go լեզվով։ Նախ ամենից առաջ պետք է նվազեցնել ֆայլերի քանակը։ Ինչպես դա անել? Անցած արխիվացման միջոցով, սակայն այս դեպքում առանց սեղմման, քանի որ իմ ֆայլերը կրճատված պատկերներ են։ Օգնականի դեր ստանձնեց BoltDB, որը ևս պետք է ազատեր թերություններից, ինչը երկխոսության մեջ է։
Դրա արդյունքում իմ դեպքում քառորդ միլիար ֆայլերի փոխարեն մնաց միայն 10 միլիոն Bolt արխիվներ։ Եթե հնարավորություն ունենայի փոխել ներկայիս ֆայլերի լիքը կառուցվածքը, հնարավոր կլիներ կրճատել մոտ 1 միլիոն ֆայլի։
Բոլոր փոքր ֆայլերը փաթեթավորվում են Bolt արխիվների մեջ, որոնք ավտոմատ կերպով ստանում են իրենց եղանակները, որոնք ակամա հեռավորություններում են, իսկ բոլոր մեծ ֆայլերը մնում են կողք առ կողքի՝ արխիվների, չկա նրանց լուծելու որեւէ իմաստ, դա կարգավորվում է։ Փոքրերը՝ արխիվացնում ենք, մեծերը՝ հեռուստատեսությամբ։ Սերվերը աշխատում է անթարթ, թե այս, թե մյուսների հետ։
wZD սերվերի ճարտարապետությունը եւ առանձնահատկությունները։
Սերվերը գործում է Linux, BSD, Solaris եւ OSX օպերացիոն համակարգերի ներքո։ Ես փորձել եմ միայն AMD64 ճարտարագիտության համար Linux-ի տակ, բայց այն նույնպես պետք է համապատասխանեցնի ARM64, PPC64, MIPS64-ին։
Այժմ հաղելու բնութագրերը՝
- Կադետների ինժեներություն;
- Մուլտիսերվերություն, ապահովելով վստահության կայունություն եւ բեռի հավասարակշռություն;
- Ավելի լայն հասանելիություն օգտագործողի կամ զարգացողի համար;
- Կայանի HTTP մեթոդների աջակցությունն է՝ GET, HEAD, PUT եւ DELETE;
- Կարդալ-գրել վարակի կառավարելիությունը՝ հաճախորդի որոտների միջոցով;
- Բազմակողմանի վիրտուալ հոստինգների աջակցություն;
- CRC ամբողջությունը տրված տվյալների համար գրելու/կարդալու դեպքում;
- Հալված կենդանի անհատական ստանդարտների նվազագույն հիշողության եւ օպտիմալ ցանցային հաջողության համար;
- Զգեկայություն վաղաժամ աշխատելու համար;
- Դիտարկվում է wZA բազմաստիճան արխիվատոր, անհրաժեշտ ֆայլերի շարժումն առանց ծառայության դադարեցման համար։
Ինքներգրավման փորձը։
Ես մշակում ու փորձարկել եմ սերվերն ու արխիվատորը կենդանի տվյալների վրա բավական երկար ժամանակ, հիմա այն հաջողությամբ գործում է 250,000,000 փոքր ֆայլերով (պատկերներ), որոնք գտնվում են 15,000,000 քարտեզներում առանձին SATA սկավառակներում։ 10 սերվերի կլաստերը հանդիսանում է հեղինակային սերվեր, այն թույլ է տալիս CDN ցանցին։ Այն սպասարկելու համար օգտագործվում է 2 Nginx սերվեր + 2 wZD սերվեր։
Սովորելով այս սերվերն օգտագործելու համար, խորհուրդ է տրվում որոշել քարտեզային կառուցվածքը, եթե դա կիրառելի է։ Բոլորովին նշեմ, որ սերվերը ոչ թե նախատեսված է բոլորն 1 Bolt արխիվում մուտքագրելու նպատակով։
Կատարողականության ստուգում։
Ինչքան քիչ է արձանագրված ֆայլի չափը, այնքան արագ են GET եւ PUT գործողությունները։ Կատարվում է համեմատությունը HTTP հաճախորդի կողմից ֆայլերի սովորական ֆայլեր եւ Bolt արխիվներով գրելու ամբողջ ժամանակում, ինչպես նաեւ կարդալու։ Համեմատվում են 32 KB, 256 KB, 1024 KB, 4096 KB եւ 32768 KB չափի ֆայլերի աշխատանքը։
Բոլտ արխիվներով աշխատելու ժամանակ ստուգվում է յուրաքանչյուր ֆայլի տվյալների ամբողջականությունը (օգտագործվում է CRC), գրելուց առաջ և հետո կատարվում է ընթերցում և հաշվարկ, ինչն, ամենակարևորը, ապահովության առումով, կարող է բերել ուշացածության:
Կատարելագործման թեստերը անցկացրել եմ SSD-վերցրածներով, քանի որ SATA-դիսկեր վրա թեստերը չեն ցույց տալիս կտրուկ տարբերություն:
Թեստավորման արդյունքների գծապատկերներ:
Ինչպես տեսնում ենք, փոքր ֆայլերի համար ընթերցման և գրելու ժամանակի միջև տարբերությունը արխիվացված և արխիվացված չֆայլերի միջև փոքր է:
32 MB չափսի ֆայլերի ընթերցման և գրելու թեստը ցույց է տալիս լրիվ այլ պատկեր:
Ընթերցման ժամանակի տարբերությունը ֆայլերի միջև տատանվում է 5-25 միլիավորի սահմաններում: Գրելու հարցում առկա խնդիրները ավելի վատ են, տարբերությունը կազմում է շուրջ 150 միլիսեկունդ: Սակայն այս դեպքում մեծ ֆայլերի թողունակումը չի պահանջվում, ինչի մեջ ընթանալը պետք չէ, նրանք կարող են ապրել արխիվներից առանձին:
*Տեխնիկապես կարելի է օգտագործել այս սերվերը նաև NoSQL պահանջող առաջադրանքների համար:
wZD սերվերով աշխատելու հիմնական մեթոդները:
Հաճախակի ֆայլի ներբեռնումը:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgBolt արխիվում ֆայլի ներբեռնելը (եթե չի գերազանցվում սերվերի fmaxsize պարամետրը, որը սահմանում է արխիվում ընդգրկվող ֆայլի առավելագույն չափը, եթե գերազանցվում է, ապա ֆայլը ներբեռնվում է որպես սովորական արխիվի կողքին):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgՖայլի ներբեռնում (եթե սկավառակում և արխիվում կան համանուն ֆայլեր, ապա ներբեռնելու ժամանակ առաջնությունը տրվում է արխիվացված չէ ֆայլին):
curl -o test.jpg http://localhost/test/test.jpgBolt արխիվից ֆայլի ներբեռնում (պարտադիր):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgԱյլ մեթոդների նկարագրությունը գտնվում է փաստաթղթում:
Սերվերը առայժմ աջակցում է միայն HTTP արձանագրությանը, HTTPS-ով դեռ չի աշխատում: Ավելին, POST մեթոդը չի աջակցվում (նաև դեռ չի որոշվել, պետք է արդյոք):
Ովքեր կփափկեն իրական կոդում, այնտեղ կգտնեն մածի, որը բոլորին չի հուզում, բայց ես ոչ մի պայմանով հիմնական կոդը կապված չեմ անում web-framework-ի ֆունկցիաների հետ, բացառությամբ ընդհատումների մշակույթի, այնպես որ հետագայում կարող եմ արագորեն գրանցել գրեթե ցանկացած շարժիչ:
ToDo:
- Զարգացում սեփական փոխանակիչի և տարածողի + աշխարհագրական հնարավորությունների համար, որպեսզի օգտագործվի մեծ համակարգերում առանց կլաստեռային ՖՍ (բոլորը հասկանալի):
- Լիարժեք հակառակ վերականգնում մետապատվերի դեպքում նրա ամբողջական կորուստի դեպքում (ապրանքի փոխանակող օգտագործելու դեպքում)
- Նատիվ արձանագիր постоян կապերի օգտագործման հնարավորությունների համար և տարբեր ծրագրավորման լեզուների համար վարորդներ
- NoSQL բաղադրիչի օգտագործման ընդլայնված հնարավորություններ
- Տարբեր տեսակների նախնական կոմպրեսիա (gzip, zstd, snappy) ֆայլերի կամ Bolt արխիվներում և սովորական ֆայլեր ներբեռնելու համար
- Տարբեր տեսակների զուգահեռում (ֆայլերի կամ Bolt արխիվներում և սովորական ֆայլերում)
- Հետաձգված սերվերի տեսանյութի փոխարկում, այդ թվում և GPU-ի վրա
Ես բացառիկ շուրդ եմ, հուսով եմ՝ այս սերվերը ինչ-որ մեկին կլինի օգտակար, BSD-3 լիցենզիա, կրկնակի հեղինակային իրավունք, քանի որ եթե չլիներ այն ընկերությունը, որտեղ աշխատում եմ, չեմ գրել լինի սերվերի մասին։ Ես ծրագրավորող եմ միայնակ։ Շնորհակալ կլինեմ ստացված սխալների և ֆունկցիոնալությունների հարցման համար։
Ընտանիք: habr.com
