Съхранявайте ефективно стотици милиони малки файлове. Самостоятелно хоствано решение

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

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

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

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

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

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

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

тук и тук.

И докер в същото време, сега има опция само с 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 милиард с една реплика на всеки файл.

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

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

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

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

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

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

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

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

Получаваме съвсем различна картина, когато тестваме четене и запис на файлове с размер 32 MB:

Времевата разлика между файловете за четене е в рамките на 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

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

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

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

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

ToDo:

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

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

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