Жүздеген миллион шағын файлдарды тиімді сақтау. Өздігінен орналастырылған шешім

Жүздеген миллион шағын файлдарды тиімді сақтау. Өздігінен орналастырылған шешім

Құрметті қауымдастық, бұл мақала жүздеген миллион шағын файлдарды тиімді сақтауға және жеткізуге арналған. Бұл кезеңде құлыптарды толық қолдайтын POSIX үйлесімді файлдық жүйелер үшін соңғы шешім ұсынылады, соның ішінде кластерлік құлыптар және тіпті балдақсыз сияқты.

Сондықтан, осы мақсатта мен өзімнің арнайы серверімді жаздым.
Бұл тапсырманы орындау барысында біз кластерлік файлдық жүйеміз аяусыз тұтынған дискілік кеңістік пен жедел жадты үнемдеуге қол жеткізе отырып, негізгі мәселені шеше алдық. Шындығында, мұндай файлдар саны кез келген кластерлік файлдық жүйе үшін зиянды.

Идея мынадай:

Қарапайым сөзбен айтқанда, кішігірім файлдар сервер арқылы жүктеледі, олар тікелей мұрағатқа сақталады, сонымен қатар одан оқылады және үлкен файлдар қатар орналастырылады. Схема: 1 қалта = 1 мұрағат, барлығы бізде бірнеше жүз миллион файл емес, шағын файлдары бар бірнеше миллион архивтер бар. Мұның бәрі ешқандай сценарийсіз және файлдарды tar/zip мұрағаттарына ашпай, толығымен орындалады.

Қысқа етіп жазуға тырысамын, егер пост көлемді болса алдын ала кешірім сұраймын.

Мұның бәрі мен HTTP протоколы арқылы алынған деректерді тікелей мұрағаттарға сақтай алатын әлемдегі қолайлы серверді таба алмағанымнан басталды, осылайша әдеттегі мұрағаттар мен объектілер қоймаларына тән кемшіліктер болмады. Ал іздеудің себебі 10 250,000,000 XNUMX шағын файлдар жинақталған және өсу тенденциясы тоқтап қалмайтын кең ауқымға дейін өскен XNUMX серверден тұратын Origin кластері болды.

Мақалаларды оқуды ұнатпайтындар үшін және кішкене құжаттама оңайырақ:

осында и осында.

Сонымен қатар докер, енді тек 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 миллиардтан аспайды.

Файлдар саны артқан сайын, метадеректер үшін сізге көп ЖЖҚ қажет. Сондай-ақ, жиі үлкен метадеректер қоқыстары SSD дискілерінің тозуына ықпал етеді.

wzd сервері. Біз дискілерде заттарды ретке келтіреміз.

Сервер Go тілінде жазылған. Ең алдымен, файлдардың санын азайту керек болды. Бұны қалай істейді? Мұрағаттауға байланысты, бірақ бұл жағдайда қысусыз, өйткені менің файлдарым қатты қысқартылған суреттер. БолтДБ көмекке келді, оны әлі де кемшіліктерінен айыруға тура келді, бұл құжаттамада көрсетілген.

Жалпы алғанда, төрттен бір миллиард файлдың орнына, менің жағдайда, Болттың 10 миллион мұрағаты ғана қалды. Егер менде каталогтарды файлдармен толтырудың ағымдағы құрылымын өзгерту мүмкіндігі болса, онда оны шамамен 1 миллион файлға дейін азайтуға болады.

Барлық шағын файлдар Bolt мұрағаттарына жинақталған, олар орналасқан каталогтардың атын автоматты түрде алады және барлық үлкен файлдар мұрағаттардың жанында қалады, оларды буып-түюдің қажеті жоқ, бұл реттеледі. Кішілері мұрағатталады, үлкендері өзгеріссіз қалдырылады. Сервер екеуімен де мөлдір жұмыс істейді.

wZD серверінің архитектурасы мен мүмкіндіктері.

Жүздеген миллион шағын файлдарды тиімді сақтау. Өздігінен орналастырылған шешім

Сервер Linux, BSD, Solaris және OSX операциялық жүйелерінде жұмыс істейді. Мен тек Linux астында AMD64 архитектурасын сынадым, бірақ ол ARM64, PPC64, MIPS64 үшін де жұмыс істеуі керек.

Негізгі ерекшеліктері:

  • Көп ағынды;
  • Ақауларға төзімділік пен жүктемені теңестіруді қамтамасыз ететін мультисервер;
  • Пайдаланушы немесе әзірлеуші ​​үшін максималды ашықтық;
  • Қолдау көрсетілетін HTTP әдістері: GET, HEAD, PUT және DELETE;
  • Клиенттік тақырыптар арқылы оқу және жазу әрекетін басқару;
  • Жоғары конфигурацияланатын виртуалды хосттарды қолдау;
  • Жазу/оқу кезінде CRC деректерінің тұтастығын қолдау;
  • Жадты минималды тұтыну және желі өнімділігін оңтайлы реттеу үшін жартылай динамикалық буферлер;
  • Деректердің кешіктірілген тығыздалуы;
  • Сонымен қатар, қызметті тоқтатпай файлдарды тасымалдау үшін көп ағынды wZA мұрағатшысы ұсынылады.

Нағыз тәжірибе:

Мен ұзақ уақыт бойы сервер мен архиваторды тірі деректерде әзірлеп, сынап жүрмін, қазір ол бөлек SATA дискілеріндегі 250,000,000 15,000,000 10 каталогта орналасқан 2 2 XNUMX шағын файлдарды (суреттерді) қамтитын кластерде сәтті жұмыс істейді. XNUMX серверден тұратын кластер CDN желісінің артында орнатылған Origin сервері болып табылады. Оған XNUMX Nginx сервері + XNUMX wZD сервері қызмет көрсетеді.

Бұл серверді пайдалануды шешкендер үшін, егер қажет болса, пайдалану алдында каталог құрылымын жоспарлау мағынасы бар. Мен сервердің барлығын 1 Болт мұрағатына жинауға арналмағанына бірден тапсырыс беремін.

Өнімділік сынағы:

Мұрағатталған файлдың өлшемі неғұрлым кіші болса, онда GET және PUT операциялары соғұрлым жылдам орындалады. HTTP клиентінің жазудың жалпы уақытын қарапайым файлдармен және Болт мұрағаттарымен, сондай-ақ оқумен салыстырайық. 32 КБ, 256 КБ, 1024 КБ, 4096 КБ және 32768 КБ файлдармен жұмысты салыстырады.

Bolt мұрағаттарымен жұмыс істегенде, әрбір файлдың деректердің тұтастығы тексеріледі (CRC пайдаланылады), жазу алдында, сондай-ақ жазғаннан кейін ол жылдам оқылады және қайта есептеледі, бұл табиғи түрде кідірістерді тудырады, бірақ ең бастысы - деректер қауіпсіздігі.

Мен SSD дискілерінде өнімділік сынақтарын өткіздім, өйткені сынақтар SATA дискілерінде нақты айырмашылықты көрсетпейді.

Сынақ нәтижелеріне негізделген графиктер:

Жүздеген миллион шағын файлдарды тиімді сақтау. Өздігінен орналастырылған шешім
Жүздеген миллион шағын файлдарды тиімді сақтау. Өздігінен орналастырылған шешім

Көріп отырғаныңыздай, шағын файлдар үшін мұрағатталған және мұрағатталмаған файлдар арасындағы оқу және жазу уақыттарының айырмашылығы шамалы.

Біз 32 МБ файлдарды оқу мен жазуды сынаған кезде мүлдем басқа сурет аламыз:

Жүздеген миллион шағын файлдарды тиімді сақтау. Өздігінен орналастырылған шешім

Файлдарды оқу арасындағы уақыт айырмашылығы 5-25 мс аралығында болады. Жазу кезінде жағдай нашар, айырмашылық шамамен 150 мс. Бірақ бұл жағдайда үлкен файлдарды жүктеп салудың қажеті жоқ, бұл жай ғана мағынасы жоқ, олар мұрағаттардан бөлек өмір сүре алады.

*Техникалық тұрғыдан бұл серверді NoSQL қажет ететін тапсырмалар үшін де пайдалануға болады.

wZD серверімен жұмыс істеудің негізгі әдістері:

Қалыпты файлды жүктеу:

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

Болт мұрағатына файлды жүктеп салу (мұрағатқа қосуға болатын файлдың максималды өлшемін анықтайтын 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

Болт мұрағатынан файлды жүктеп алу (мәжбүрлеп):

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

Басқа әдістер құжаттамада сипатталған.

wZD құжаттамасы
wZA құжаттамасы

Сервер әзірге тек HTTP протоколын қолдайды, ол әлі HTTPS протоколымен жұмыс істемейді. POST әдісіне де қолдау көрсетілмейді (ол қажет пе, жоқ па әлі шешілген жоқ).

Бастапқы кодты кім зерттесе, ол жерде ірімшік табады, оны бәрі бірдей ұнатпайды, бірақ мен негізгі кодты үзу өңдеушісінен басқа веб-рамканың функцияларына байланыстырған жоқпын, сондықтан болашақта мен кез келген қозғалтқышты тез қайта жаза аламын. .

Істеу:

  • Өзіңіздің репликаторыңызды және дистрибьюторыңызды + оны кластерленген FSсіз үлкен жүйелерде пайдалану мүмкіндігі үшін гео (Ересектер үшін бәрі)
  • Толық жоғалған жағдайда метадеректерді толық кері қалпына келтіру мүмкіндігі (дистрибьюторды пайдаланған жағдайда)
  • Тұрақты желілік қосылымдарды және әртүрлі бағдарламалау тілдері үшін драйверлерді пайдалану мүмкіндігіне арналған жергілікті протокол
  • NoSQL компонентін пайдаланудың кеңейтілген мүмкіндіктері
  • Болт мұрағаттарының ішіндегі файлдар немесе мәндер және кәдімгі файлдар үшін әртүрлі типтегі қысулар (gzip, zstd, snappy)
  • Bolt мұрағатындағы файлдар немесе мәндер үшін және кәдімгі файлдар үшін әртүрлі типтерді шифрлау
  • Кешіктірілген серверлік бейне түрлендіру, соның ішінде GPU

Менде бәрі бар, бұл сервер біреуге пайдалы деп үміттенемін, BSD-3 лицензиясы, қосарланған авторлық құқық, өйткені мен жұмыс істейтін компания болмаса, сервер жазылмас еді. Мен жалғыз әзірлеушімін. Табылған қателер мен мүмкіндік сұраулары үшін алғыс айтамын.

Ақпарат көзі: www.habr.com

пікір қалдыру