جامعه عزیز، این مقاله بر روی ذخیره و بازیابی کارآمد صدها میلیون فایل کوچک تمرکز دارد. در این مرحله راه حل نهایی برای سیستم های فایل سازگار با POSIX با پشتیبانی کامل از قفل ها از جمله قفل های خوشه ای و به ظاهر حتی بدون عصا پیشنهاد شده است.
بنابراین من سرور سفارشی خودم را برای این منظور نوشتم.
در مسیر اجرای این کار، ما موفق شدیم مشکل اصلی را حل کنیم و در عین حال به صرفه جویی در فضای دیسک و RAM که سیستم فایل کلاستر ما بی رحمانه مصرف می کرد، دست یافتیم. در واقع، چنین تعداد فایلی برای هر سیستم فایل خوشه ای مضر است.
ایده این است:
به عبارت ساده، فایل های کوچک از طریق سرور آپلود می شوند، مستقیماً در آرشیو ذخیره می شوند و همچنین از روی آن خوانده می شوند و فایل های بزرگ در کنار هم قرار می گیرند. طرح: 1 پوشه = 1 آرشیو، در مجموع چندین میلیون آرشیو با فایل های کوچک داریم و نه چند صد میلیون فایل. و همه اینها به طور کامل بدون هیچ گونه اسکریپت یا قرار دادن فایل ها در بایگانی های tar/zip پیاده سازی می شوند.
سعی می کنم کوتاه بنویسم، اگر پست طولانی شد پیشاپیش عذرخواهی می کنم.
همه چیز با این واقعیت شروع شد که من نتوانستم سرور مناسبی در جهان پیدا کنم که بتواند داده های دریافت شده از طریق پروتکل HTTP را مستقیماً در بایگانی ها ذخیره کند، بدون اینکه معایب ذاتی بایگانی های معمولی و ذخیره سازی اشیاء را داشته باشد. و دلیل جستجو، خوشه Origin از 10 سرور بود که به مقیاس بزرگی رشد کرده بودند، که در آن 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 میلیارد با یک نسخه از هر فایل.
با افزایش تعداد فایل ها، مقدار زیادی رم برای متادیتا مورد نیاز است. تخلیه مکرر ابرداده های بزرگ نیز به فرسودگی و پارگی درایوهای SSD کمک می کند.
سرور wZD. ما چیزها را روی دیسک ها مرتب می کنیم.
سرور در Go نوشته شده است. اول از همه باید تعداد فایل ها را کم کنم. چگونه انجامش بدهیم؟ با توجه به بایگانی، اما در این مورد بدون فشرده سازی، از آنجایی که فایل های من فقط تصاویر فشرده هستند. BoltDB به کمک آمد، که هنوز باید از کاستی های آن حذف می شد، این در اسناد منعکس شده است.
در کل به جای یک چهارم میلیارد فایل، در مورد من فقط 10 میلیون آرشیو بولت باقی مانده بود. اگر من این فرصت را داشتم که ساختار فایل دایرکتوری فعلی را تغییر دهم، می‌توانستم آن را به حدود 1 میلیون فایل کاهش دهم.
همه فایل‌های کوچک در بایگانی‌های Bolt بسته‌بندی می‌شوند، که به طور خودکار نام دایرکتوری‌هایی را که در آن قرار دارند دریافت می‌کنند، و همه فایل‌های بزرگ در کنار بایگانی‌ها باقی می‌مانند؛ بسته‌بندی آنها فایده‌ای ندارد، این قابل تنظیم است. موارد کوچک بایگانی می شوند و موارد بزرگ بدون تغییر باقی می مانند. سرور به صورت شفاف با هر دو کار می کند.
معماری و ویژگی های سرور wZD.
این سرور تحت سیستم عامل های Linux، BSD، Solaris و OSX کار می کند. من فقط برای معماری AMD64 تحت لینوکس تست کردم، اما باید برای 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 کیلوبایت، 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آپلود یک فایل در بایگانی 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 نیز پشتیبانی نمی شود (هنوز تصمیم گیری نشده است که آیا به آن نیاز است یا خیر).
هر کسی که کد منبع را بررسی کند، butterscotch را در آنجا پیدا می کند، همه آن را دوست ندارند، اما من کد اصلی را به توابع چارچوب وب گره نزدم، به جز کنترل کننده وقفه، بنابراین در آینده می توانم به سرعت آن را برای تقریباً هر کسی بازنویسی کنم. موتور
انجام دادن:
- توسعه Replicator و Distributor + Geo برای امکان استفاده در سیستم های بزرگ بدون سیستم فایل کلاستر (همه چیز برای بزرگسالان)
- امکان بازیابی معکوس کامل ابرداده در صورت از بین رفتن کامل آن (در صورت استفاده از توزیع کننده)
- پروتکل بومی برای توانایی استفاده از اتصالات شبکه و درایورهای مداوم برای زبان های برنامه نویسی مختلف
- امکانات پیشرفته برای استفاده از مؤلفه NoSQL
- فشرده سازی انواع مختلف (gzip، zstd، snappy) برای فایل ها یا مقادیر داخل آرشیو Bolt و برای فایل های معمولی
- رمزگذاری انواع مختلف برای فایل ها یا مقادیر داخل آرشیو Bolt و برای فایل های معمولی
- تبدیل ویدیوی سمت سرور با تاخیر، از جمله در GPU
من همه چیز دارم، امیدوارم این سرور برای کسی مفید باشد، مجوز BSD-3، حق چاپ دوگانه، زیرا اگر شرکتی که در آن کار می کنم وجود نداشت، سرور نوشته نمی شد. من تنها توسعه دهنده هستم. برای هر گونه اشکال و درخواست ویژگی که پیدا کنید سپاسگزار خواهم بود.
منبع: www.habr.com