بازگشت به کتابخانهکتابخانه17.6Case Study: ذخیره‌سازی شیء (S3)
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 17.6فصل ۱۷Case Study های تکمیلی

Case Study: ذخیره‌سازی شیء (S3)

  • ~۱۳ دقیقه
  • ۳ پرسش
  • متن را انتخاب کن تا هایلایت شود

مسئله: S3 بساز — PUT فایل، GET فایل، تا ابد، با دوام ۱۱ تا ۹. سرویس ده‌ساله‌ای که همه اینترنت رویش خوابیده؛ درونش درس‌های بزرگی برای دیتابیس‌سازی است.

۱-۲) نیازمندی و تخمین

  • FR: آپلود/دانلود شیء (از کیلوبایت تا ترابایت)، bucket ،لیست کردن، versioning ،کنترل دسترسی.
  • NFR: Durability ~۱۱ نه (از دست رفتن داده یعنی مرگ اعتماد) — Availability بالا، هزینه per-GB پایین، throughput عظیم.
  • تخمین: اشیاء بزرگ (عکس/ویدیو/بکاپ) غالب‌اند؛ دیسک ارزان و IOPS کم اهمیت است — برخلاف دیتابیس تراکنشی.

۳) طراحی — جدایی متادیتا از داده

DIAGRAMدو سطح S3
API — احراز/مسیریاب
Metadata DB — نام/مالک/نگاشت
Data Store — بلاک‌های رمزنگاری‌شده
Erasure Coding — توزیع
بک‌گراند: repair/انتقال
  • دو سطح: متادیتا (bucket ،key ،مالک، محل بلاک‌ها) در دیتابیس کوچک و سریع؛ داده خام به‌صورت بلاک‌های چندمگابایتی در گره‌های ذخیره. جدایی یعنی هر یک به روش خودش مقیاس می‌شود.
  • دوام با Erasure Coding: به‌جای ۳ کپی کامل (۲۰۰٪ overhead)، شیء به k بلاک داده + m بلاک parity شکسته می‌شود؛ از هر k+m ،با k تا بازسازی می‌شود — دوام بهتر با ~۵۰٪ overhead. RAID در مقیاس سیاره‌ای.
  • Multipart Upload: فایل بزرگ به قطعات موازی آپلود می‌شود و در پایان complete اعلام می‌شود — از سرگیری بعد از قطعی فقط قطعه ناقص را می‌خواهد.
  • آپلود مستقیم: کلاینت با presigned URL مستقیم به storage می‌نویسد؛ سرور API فقط امضا می‌کند — گلوگاه پروکسی حذف می‌شود.

۴) عمق و گلوگاه

  • لیست‌کردن: LIST در bucket میلیاردشیء‌ای باید صفحه‌بندی‌شده و بر پایه ایندکس متادیتا باشد — عملیات «ارزان به‌نظر» که در طراحی بد، گران تمام می‌شود.
  • گرمای سلسله‌مراتبی: شیء تازه hot است، شش ماه بعد تقریباً مرده — tiering خودکار به ذخیره ارزان‌تر (Glacier) هزینه را می‌شکافت.
  • تعمیر پس‌زمینه: دیسک‌ها می‌میرند؛ سرویس بازرس دائم checksum ها را می‌خواند و بلاک گمشده را از parity بازسازی می‌کند — دوام فرایندی دائمی است نه یک تنظیم.

به زبان ساده

S3 یعنی جدایی نام و آدرس فایل (متادیتا) از خودِ بایت‌ها؛ دوام افسانه‌ای‌اش از تقسیم هر فایل به تکه‌های داده+پارانسی (erasure coding) و تعمیر دائمی پس‌زمینه می‌آید.

مثال واقعی

مثل بایگانی با فهرست جدا: فهرست می‌گوید جلد ۴۲ در قفسه کجاست؛ خودِ جلد به ۱۲ تکه تقسیم شده که اگر ۴ تکه آتش هم بگیرند، از ۸ تای بقیه بازسازی می‌شود.

دانش‌سنجی

آزمون درس

۳ Q
01
مزیت Erasure Coding بر Replication سه‌نسخه‌ای؟
02
Multipart Upload چه مشکلی را حل می‌کند؟
03
چرا presigned URL به‌جای عبور داده از سرور API؟