Ефективно съхранение на стотици милиони малки файлове. Self-Hosted решение

Уважаемо общество, тази статия ще бъде посветена на ефективното съхранение и извеждане на стотици милиони малки файлове. На този етап предлагам окончателно решение за POSIX съвместими файлови системи с пълна поддръжка на блокировки, включително кластерни, и изглежда, че вече не се нуждаем от импровизации.

Затова за тази цел написах свой собствен специализиран сървър.
В хода на реализиране на тази задача успяхме да решим основния проблем, а в същото време постигнахме икономия на дисково пространство и оперативна памет, която нашата кластерна файловата система изразходваше неумолимо. Всъщност такова количество файлове е вредно за всяка кластерна файловата система.

Идеята е следната:

Простими думи, през сървъра се зареждат малки файлове, те се съхраняват директно в архив и също така се извеждат от него, а големите файлове се поставят до тях. Схемата: 1 папка = 1 архив, в крайна сметка имаме няколко милиона архива с малки файлове, вместо няколко стотин милиона файла. И всичко това е реализирано напълно, без никакви скриптове и разполагане на файлове в tar/zip архиви.

Ще се постарая да изложа по-кратко, предварително се извинявам, ако постът стане обемен.

Всичко започна от това, че не успях да намеря подходящ сървър в света, който да може да съхранява данни, получени чрез HTTP протокол директно в архиви, така че да няма недостатъците, присъщи на обикновените архиви и обектните хранилища. А причината за търсенето стана разрасналият се до големи размери Origin клъстър от 10 сървъра, в който вече бяха събрани 250,000,000 малки файлове, а тенденцията за растеж не спираше.

За тези, които не обичат да четат статии, е по-просто с малка документация:

тук и тук.

И docker също, в момента има вариант само заедно с nginx вътре за всеки случай:

docker run -d --restart=always -e host=localhost -e root=\/var\/storage \n-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 милиард при едно копие на всеки файл.

С увеличаването на количеството файлове, е необходимо много оперативна памет за метаданни. Честите големи дампове на метаданни също допринасят за износването на 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 сървъра представлява Origin-сървър, разположен зад CDN мрежата. За неговото обслужване се използват 2 сървъра Nginx + 2 сървъра wZD.

За тези, които решат да използват този сървър, е разумно да планират структурата на директориите предварително, ако това е приложимо. Веднага отбелязвам, че сървърът не е предназначен да събира всичко в 1 Bolt архив.

Тестване на производителността:

Колкото по-малък е размерът на архивирания файл, толкова по-бързо се извършват операциите GET и PUT с него. Сравняваме общото време за запис на HTTP клиент в обикновени файлове и в Bolt архиви, както и четенето. Сравняваме работа с файлове с размер 32 KB, 256 KB, 1024 KB, 4096 KB и 32768 KB.

При работа с Bolt архиви се проверява целостта на данните на всеки файл (използва се CRC), преди да бъде записан, и също така след записа се извършва четене на момента и повторен оборот, което естествено внася забавяне, но основното е сигурността на данните.

Тествата за производителност провеждах на SSD дискове, тъй като на SATA дисковете тестовете не показват ясна разлика.

Графики на резултатите от тестовете:

Както личи, разликата във времето за четене и запис между архивираните и неархивираните файлове за малки файлове не е голяма.

Коренно различна картина ще получим при теста за четене и запис на файлове с размер 32 MB:

Разликата във времето между четенето на файловете е в диапазона 5-25 мс. С записването обаче положението е по-лошо, разликата е около 150 мс. Но в този случай не е необходимо да се качват големи файлове, в това просто няма смисъл, те могат да съществуват отделно от архивите.

*Технически е възможно да се използва този сървър и за задачи, изискващи 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

Описание на другите методи можете да намерите в документацията.

Документация wZD
Документация wZA

Сървърът в момента поддържа само HTTP протокол, с HTTPS все още не работи. Методът POST също не е подкрепен (все още не е решено дали е необходим или не).

Който се запознае с изходния код, ще открие там ириска; не всеки я харесва, но не съм свързал основния код с функциите на уеб фреймворка, освен обработчика на прекъсвания, така че в бъдеще мога бързо да пренапиша почти на всякакъв двигател.

ToDo:

• Разработка на собствен репликатор и дистрибутор + гео за възможност за използване в големи системи без клъстерни файлови системи (всичко по-възрастно)
• Възможност за пълно обратно възстановяване на метаданни при пълната им загуба (в случай на използване на дистрибутор)
• Нативен протокол за възможност за използване на постоянни мрежови връзки и драйвери за различни програмни езици
• Разширени възможности за използване на NoSQL компонента
• Компресии на различни типове (gzip, zstd, snappy) за файлове или стойности в Bolt архиви и за обикновени файлове
• Шифриране на различни типове за файлове или стойности в Bolt архиви и за обикновени файлове
• Отложена сървърна видео конверсия, включително на GPU

С това завършвам, надявам се този сървър да бъде полезен на някого, лицензия BSD-3, двойно авторско право, тъй като ако нямаше компанията, в която работя, нямаше да напиша и сървъра. Аз съм разработчик в единствено число. Ще бъда благодарен за намерените бъгове и заявки за нови функции.

Източник: habr.com