Object Storage چیست و چه فرقی با File Storage و Block Storage دارد؟

وقتی صحبت از «فضای ذخیره‌سازی» می‌شود، بیشتر ما یک دیسک و چند پوشه را تصور می‌کنیم. اما در زیرساخت‌های امروزی سه مدل کاملاً متفاوت برای نگه‌داری داده وجود دارد: Block Storage، File Storage و Object Storage. هر کدام برای نوع خاصی از داده ساخته شده‌اند و انتخاب اشتباه، دیر یا زود به کندی، هزینه‌ی اضافه یا مهاجرت‌های دردسرساز می‌رسد. در این مقاله هر سه را توضیح می‌دهیم و نشان می‌دهیم چرا Object Storage به انتخاب پیش‌فرض برای فایل‌های آپلودی، رسانه و بکاپ تبدیل شده است.

Block Storage: دیسک خام

Block Storage داده را به قطعه‌های (Block) هم‌اندازه تقسیم می‌کند و هر قطعه یک آدرس دارد. خود ذخیره‌ساز هیچ تصوری از «فایل» ندارد؛ این سیستم‌عامل است که روی آن فایل‌سیستم (مثل ext4 یا XFS) می‌سازد. دیسک سرور مجازی شما، یک Volume در SAN با iSCSI، یا یک RBD در Ceph همگی Block Storage هستند.

نقطه‌ی قوت: کمترین تأخیر و بیشترین کارایی برای خواندن و نوشتن‌های کوچک و تصادفی.
مناسب برای: دیتابیس‌ها، دیسک ماشین‌های مجازی، Volumeهای کوبرنتیز.
محدودیت: معمولاً در هر لحظه فقط به یک سرور وصل می‌شود و بزرگ کردنش به برنامه‌ریزی نیاز دارد.

File Storage: پوشه‌های مشترک

File Storage همان ساختار آشنای پوشه و فایل است که از طریق شبکه و با پروتکل‌هایی مثل NFS یا SMB بین چند سرور به اشتراک گذاشته می‌شود. NAS‌های سازمانی و CephFS نمونه‌های رایج آن هستند.

نقطه‌ی قوت: چند سرور هم‌زمان به یک مجموعه فایل دسترسی دارند و اپلیکیشن‌ها بدون تغییر کد با آن کار می‌کنند، چون از دید آن‌ها یک پوشه‌ی معمولی است.
مناسب برای: پوشه‌های مشترک کارکنان، نرم‌افزارهای قدیمی که فقط با مسیر فایل کار می‌کنند.
محدودیت: با رشد تعداد فایل‌ها (میلیون‌ها فایل کوچک) و تعداد کلاینت‌ها، مدیریت قفل‌ها و متادیتای فایل‌سیستم به گلوگاه تبدیل می‌شود. اتصال NFS روی اینترنت هم نه امن است و نه پایدار.

Object Storage: داده + متادیتا + یک کلید

در Object Storage خبری از پوشه‌های تودرتو و Blockهای خام نیست. هر داده یک Object است که سه بخش دارد:

خود داده: یک تصویر، یک فایل PDF، یک بکاپ چند گیگابایتی.
متادیتا: اطلاعاتی درباره‌ی داده، مثل نوع محتوا (Content-Type)، تاریخ تغییر، اندازه و هر برچسب دلخواهی که خودتان تعریف کنید.
کلید (Key): یک نام یکتا، مثل avatars/2026/user-1542.jpg.

Objectها داخل ظرف‌هایی به نام Bucket قرار می‌گیرند. فضای نام داخل هر Bucket تخت (Flat) است؛ یعنی avatars/2026/ در واقع پوشه نیست، بلکه بخشی از نام Object است که به آن Prefix می‌گویند. ابزارها آن را شبیه پوشه نشان می‌دهند، اما ذخیره‌ساز با آن مثل یک رشته‌ی متنی رفتار می‌کند. همین سادگی است که اجازه می‌دهد Object Storage تا میلیاردها Object و صدها ترابایت رشد کند.

دسترسی به Objectها از طریق HTTP انجام می‌شود، نه با mount کردن دیسک. اپلیکیشن یک درخواست PUT برای ذخیره، GET برای خواندن و DELETE برای حذف می‌فرستد. یک نکته‌ی مهم: Objectها معمولاً تغییرناپذیرند؛ نمی‌توانید وسط یک فایل چند بایت را عوض کنید و باید کل Object را دوباره بنویسید. به همین دلیل Object Storage برای دیتابیس مناسب نیست، اما برای فایل‌هایی که یک بار نوشته و بارها خوانده می‌شوند ایده‌آل است.

API استاندارد S3 چیست؟

آمازون با سرویس Amazon S3 یک API برای کار با Object Storage تعریف کرد که امروز به استاندارد عملی این حوزه تبدیل شده است. بیشتر راهکارهای متن‌باز و تجاری، از جمله Ceph RADOS Gateway، Garage، SeaweedFS و MinIO، همین API را پیاده‌سازی می‌کنند. نتیجه این است که هر نرم‌افزاری که برای S3 نوشته شده (وردپرس، لاراول، GitLab، Nextcloud، ابزارهای بکاپ مثل Restic و rclone) با یک Object Storage سازگار با S3 روی سرور خودتان هم کار می‌کند و معمولاً فقط باید این موارد را تغییر دهید:

Endpoint: آدرس سرویس، مثلاً https://s3.example.com
Access Key و Secret Key: چیزی شبیه نام کاربری و رمز، که هر درخواست با آن امضا می‌شود (Signature V4).
نام Bucket و در صورت نیاز Region.

چند مفهوم دیگر S3 که زیاد با آن‌ها روبه‌رو می‌شوید:

Bucket Policy: قوانین دسترسی به شکل JSON؛ مثلاً اینکه همه بتوانند فایل‌های یک Prefix را بخوانند، اما فقط اپلیکیشن بتواند بنویسد.
Presigned URL: لینکی موقت و امضاشده که برای مدت محدود اجازه‌ی دانلود یا آپلود یک Object خصوصی را می‌دهد؛ مناسب فاکتورها و فایل‌های خریداری‌شده.
Versioning: نگه‌داشتن نسخه‌های قبلی یک Object بعد از بازنویسی یا حذف.
Lifecycle: قوانینی برای حذف خودکار Objectهای قدیمی، مثلاً لاگ‌های بیش از ۹۰ روز.
Multipart Upload: آپلود فایل‌های بزرگ در چند قطعه‌ی موازی و قابل ادامه.

یک مثال عملی

با AWS CLI می‌توانید با هر Object Storage سازگار با S3 کار کنید. فقط کافی است Endpoint را مشخص کنید:

# ساخت Bucket
aws --endpoint-url https://s3.example.com s3 mb s3://app-media

# آپلود یک فایل همراه با متادیتای دلخواه
aws --endpoint-url https://s3.example.com s3 cp ./invoice.pdf \
  s3://app-media/invoices/2026/invoice-1001.pdf \
  --content-type application/pdf \
  --metadata customer-id=1542

# دیدن متادیتای Object
aws --endpoint-url https://s3.example.com s3api head-object \
  --bucket app-media --key invoices/2026/invoice-1001.pdf

# ساخت لینک موقت یک‌ساعته
aws --endpoint-url https://s3.example.com s3 presign \
  s3://app-media/invoices/2026/invoice-1001.pdf --expires-in 3600

همین چند دستور نشان می‌دهد چرا Object Storage برای اپلیکیشن‌ها جذاب است: هیچ دیسکی mount نشده، هیچ پوشه‌ی مشترکی بین سرورها لازم نیست و هر سرور یا کانتینری که کلید داشته باشد، از هر جای شبکه به داده دسترسی دارد.

مقایسه‌ی سه مدل

ویژگی	Block Storage	File Storage	Object Storage
واحد داده	Block با آدرس	فایل در ساختار پوشه	Object با کلید و متادیتا
نحوه‌ی دسترسی	دیسک متصل به سیستم‌عامل (iSCSI، RBD، دیسک مجازی)	NFS / SMB	HTTP و API سازگار با S3
اشتراک بین چند سرور	معمولاً خیر	بله	بله، حتی از راه دور و روی اینترنت
تغییر بخشی از داده	بله	بله	خیر؛ کل Object دوباره نوشته می‌شود
مقیاس‌پذیری	محدود به اندازه‌ی Volume	متوسط	بسیار بالا
تأخیر	کمترین	کم تا متوسط	بیشتر (درخواست HTTP)
کاربرد اصلی	دیتابیس، دیسک VM	پوشه‌های مشترک، نرم‌افزارهای قدیمی	فایل‌های آپلودی، رسانه، بکاپ، لاگ، آرشیو

کدام را انتخاب کنیم؟

به‌جای انتخاب یکی برای همه‌چیز، برای هر نوع داده جداگانه تصمیم بگیرید. یک چارچوب ساده:

داده مدام و در قطعه‌های کوچک تغییر می‌کند؟ (دیتابیس، صف، دیسک سیستم‌عامل) ← Block Storage.
نرم‌افزار فقط با مسیر فایل کار می‌کند و قابل تغییر نیست؟ ← File Storage. در غیر این صورت سراغ گزینه‌ی بعد بروید.
فایل یک بار نوشته و بارها خوانده می‌شود، یا حجمش زیاد است و رشد می‌کند؟ (تصاویر کاربران، ویدیو، PDF، بکاپ، لاگ آرشیوی) ← Object Storage.

یک اپلیکیشن معمولی وب در عمل از هر سه استفاده می‌کند: دیتابیس روی Block Storage، و فایل‌های آپلودی و بکاپ‌ها روی Object Storage. همین جداسازی است که سرور اپلیکیشن را «بی‌حالت» (Stateless) می‌کند و اجازه می‌دهد آن را راحت چند برابر کنید، داکرایز کنید یا جابه‌جا کنید.

نشانه‌هایی که وقت مهاجرت به Object Storage است

پوشه‌ی uploads یا storage سایت شما بزرگ‌ترین بخش بکاپ است و هر شب ساعت‌ها طول می‌کشد.
برای اضافه کردن سرور دوم به اپلیکیشن، با همگام‌سازی فایل‌ها بین سرورها مشکل دارید.
بکاپ‌ها روی همان سروری نگه‌داری می‌شوند که از آن بکاپ گرفته شده است.
دیسک سرور مرتب پر می‌شود (نگاهی به مقاله‌ی پر شدن دیسک سرور لینوکس بیندازید).

برای قدم بعدی، مقاله‌ی مقایسه‌ی MinIO، Ceph و Garage به شما کمک می‌کند راهکار مناسب را انتخاب کنید و در انتقال فایل‌های آپلود وردپرس و لاراول به Object Storage روش اتصال اپلیکیشن را قدم‌به‌قدم توضیح داده‌ایم. اگر هزینه برایتان مهم است، محاسبه‌ی هزینه‌ی Object Storage را هم ببینید.

جمع‌بندی

Block Storage برای سرعت، File Storage برای سازگاری با نرم‌افزارهای سنتی و Object Storage برای مقیاس و سادگی دسترسی ساخته شده است. اگر داده‌ی شما فایل‌های آپلودی، رسانه یا بکاپ است، Object Storage سازگار با S3 تقریباً همیشه انتخاب درستی است؛ چه روی سرویس ابری، چه روی زیرساخت خودتان و داخل ایران.

نمی‌خواهید این کار را خودتان انجام دهید؟ تیم مروانت Object Storage سازگار با S3 را روی سرورهای شما یا در دیتاسنتر مروانت طراحی و راه‌اندازی می‌کند و اپلیکیشن‌هایتان را به آن متصل می‌کند. صفحه‌ی راه‌اندازی Object Storage اختصاصی را ببینید.