Object در برابر file و block storage
Block storage یک دیسک خام است: سریع، متصل به یک ماشین، و همان واحدی که دیتابیس شما میخواهد. File storage (مثل NFS و همخانوادههایش) یک درخت پوشهی مشترک است: آشنا، اما با بزرگتر شدن، locking و متادیتا به گلوگاه تبدیل میشوند. Object storage کلاً این درخت را کنار میگذارد — هر object در یک فضای نام تخت درون یک bucket زندگی میکند و با کلیدی مانند «invoices/2026/08/1234.pdf» آدرسدهی میشود. آن کلید شبیه مسیر بهنظر میرسد، اما فقط یک نام است؛ لازم نیست چیزی واقعاً «داخل» چیز دیگری باشد.
همین یک تصمیم طراحی است که باعث میشود object storage اینقدر آرام مقیاس بگیرد. نه دایرکتوریای هست که قفل شود، نه فایلسیستمی که fsck بخواهد، نه والیومی که باید resize شود. بابت آنچه ذخیره میکنید پول میدهید و فضا بدون هیچ مهاجرتی از چند مگابایت تا چند ترابایت رشد میکند. در عوض: objectها بهصورت کامل جایگزین میشوند، نه ویرایش درجا، و خبری از semanticsهای POSIX نیست — دقیقاً به همین دلیل جای درستی برای یک دیتابیس زنده نیست و جای درستی برای تقریباً هر چیز دیگری است که اپلیکیشن شما سرو یا آرشیو میکند.
«سازگار با S3» واقعاً یعنی چه
آمازون S3 در سال ۲۰۰۶ عرضه شد و API مبتنی بر HTTP آن برای object storage همان نقشی را پیدا کرد که SQL برای دیتابیسها دارد: استاندارد عملی. یک سرویس سازگار با S3 همان API را پیاده میکند، پس کل اکوسیستمی که حول S3 ساخته شده — AWS CLI، SDK هر زبانی، rclone، restic، ابزار mc از MinIO، افزونههای بکاپ و ابزارهای انتشار سایت استاتیک — بدون تغییر روی آن کار میکند. ابزار را به یک endpoint دیگر نشانه میگیرید و عادتهای کاریتان دستنخورده میماند.
معنای عملی این موضوع برای شما: در سطح ابزار، قفلشدن به یک فروشنده وجود ندارد. کدی که روی API استاندارد S3 نوشته شده با تغییر دو خط پیکربندی — endpoint و اطلاعات دسترسی — بین ارائهدهندگان جابهجا میشود. یعنی میتوانید بهصورت محلی روی یک پیادهسازی S3 تست کنید و روی یکی دیگر منتشر کنید، بدون دست زدن به کد اپلیکیشن.
Bucket، کلید و endpoint — سه واژهای که اهمیت دارند
Bucket ظرف سطحبالا است و نام آن در کل سرویس یکتاست — آن را مانند «درایو»ی ببینید که برای هر پروژه یا هر هدف میسازید (uploads، backups، assets). یک جفت access key هم روشی است که برنامه با آن احراز هویت میکند: access key ID آن را میشناساند و secret key هر درخواست را امضا میکند. با secret مانند یک رمز عبور رفتار کنید — فقط یکبار هنگام ساخت نمایش داده میشود، پس آن را در secret manager نگه دارید، نه داخل کد.
Endpoint همان آدرسی است که API استاندارد S3 روی آن قرار دارد. روی AWS شکل منطقهای دارد (s3.eu-central-1.amazonaws.com)؛ روی ارائهدهندگان دیگر آدرس خودشان است — روی cdn.com.tr این آدرس s3.cdn.com.tr است. هر ابزار S3 امکان بازنویسی endpoint را میپذیرد؛ همان یک فلگ، چهرهی عملی «سازگار با S3» است.
همان AWS CLI که از قبل میشناسید — فقط endpoint تغییر میکند
# create a bucket
aws --endpoint-url https://s3.cdn.com.tr s3 mb s3://app-uploads
# upload and list
aws --endpoint-url https://s3.cdn.com.tr s3 cp ./photo.jpg s3://app-uploads/2026/photo.jpg
aws --endpoint-url https://s3.cdn.com.tr s3 ls s3://app-uploads/2026/
# sync a whole folder (deploys, backups)
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./public s3://app-uploads/siteچه چیزی را در آن بگذارید (و چه چیزی را نه)
Object storage هرجا که فایلها یکبار نوشته و بارها خوانده میشوند ارزش خود را ثابت میکند: آپلود کاربران و رسانه، تصویر و ویدیو، خروجیهای بیلد و فایلهای دانلود نسخهها، آرشیو لاگ، dump و بکاپ دیتابیس، و نیمهی استاتیک وبسایت شما. همچنین جای طبیعی هر چیزی است که باید نگه دارید اما بهندرت سراغش میروید — معادل ذخیرهسازیِ یک انبار مرتب.
هر چیزی را که به ویرایش درجا یا locking نیاز دارد بیرون نگه دارید: فایلهای دیتابیس زنده، کشهای داغ با انتظار زیرمیلیثانیه، و فایلهایی که یک پروسه پیوسته به آنها append میکند. جای اینها روی block storage یا در یک دیتابیس مدیریتشده است؛ object storage خروجیهای ماندگاری را که آنها تولید میکنند تحویل میگیرد.
چرا یک CDN باید جلوی objectهای عمومی باشد
ذخیرهسازی و تحویل دو کار متفاوتاند. Storage نسخهی مرجع را ماندگار نگه میدارد؛ یک CDN همان درخواست را هزاران بار از مکانهای edge نزدیک به کاربران شما پاسخ میدهد. اگر یک فایل پرطرفدار را مستقیم از هر backend ذخیرهسازی سرو کنید، هر دانلود تا مبدأ سفر میکند؛ اما با یک edge جلوی آن، مبدأ تقریباً برای هر فایل یکتا یکبار پاسخ میدهد و edge جمعیت را جذب میکند.
روی cdn.com.tr این دو بخشی از یک پلتفرم واحدند: bucketها میتوانند به container appهای شما متصل شوند و محتوای عمومی از همان edge جهانی سرو میشود که جلوی بقیهی حساب شما ایستاده — یک پنل، یک صورتحساب، و هیچ غافلگیری بابت egress بینارائهدهندهای میان storage و CDN شما.
اشتباههایی که برای مردم گران تمام میشود
سه الگو بیشتر دردسرهای object storage را میسازند. اول، bucket عمومی: باز گذاشتن یک bucket برای همه در حالی که دادهی خصوصی دارد. پیشفرض را خصوصی بگذارید و تنها پیشوندهایی را عمومی کنید که واقعاً قرار است عمومی باشند. دوم، سرو کردن فایلهای پرترافیک مستقیماً از storage روی ارائهدهندگانی که egress را گیگابایتی حساب میکنند — آن صورتحساب همراه با موفقیت شما رشد میکند؛ یک کش edge جلوی آن، منحنی را صاف میکند. سوم، اطلاعات دسترسی داخل کد: یک secret key لو رفته، توکن دسترسی کامل به همه چیز در آن حساب است. برای هر هدف کلید جداگانه بسازید، آنها را در متغیرهای محیطی یا یک secret manager نگه دارید، و هر کلیدی را که حتی به لو رفتنش شک دارید تعویض کنید.
پرسشهای پرتکرار
آیا object storage همان S3 bucket است؟
تقریباً. «S3» محصول آمازون است؛ bucket هم مفهوم ظرفی است که همان محصول رایج کرد. Object storage نام دستهی کلی است و چون بیشتر ارائهدهندگان API استاندارد S3 را پیاده میکنند، «یک S3 bucket» در گفتوگوی روزمره یعنی «یک bucket روی هر سرویس سازگار با S3».
میتوانم کل یک وبسایت را از object storage میزبانی کنم؟
بخشهای استاتیک را بله — HTML، CSS، JS و تصاویر که از طریق یک CDN سرو شوند یک الگوی کلاسیک است. هر چیز پویا (PHP، Node.js، یک دیتابیس) به یک محیط اجرا نیاز دارد؛ روی cdn.com.tr این همان کاری است که پلتفرمهای مدیریتشدهی WordPress، PHP و کانتینر انجام میدهند، در حالی که bucket فایلها را نگه میدارد.
آیا ابزارها و کد SDK فعلی من با S3 کار میکنند؟
بله — نکتهی اصلی سازگاری با S3 همین است. AWS CLI یا SDK را با جفت access key مربوط به bucket خود به endpoint آدرس https://s3.cdn.com.tr نشانه بگیرید و دستورهایی که از قبل استفاده میکنید (cp، sync، presigned URL، multipart upload) دقیقاً مثل قبل رفتار میکنند.
این با Google Drive یا Dropbox چه فرقی دارد؟
آنها محصولات همگامسازی فایل برای آدمها هستند: اپلیکیشن، پنجرهی اشتراکگذاری، کلاینت sync. Object storage زیرساختی برای برنامههاست: یک API که اپلیکیشن شما برای ذخیره و بازیابی objectها در مقیاس صدا میزند. قابلیت آپلود یک اپلیکیشن را روی Dropbox نمیسازید، و دسکتاپ خود را هم با یک bucket همگام نمیکنید.