Object Storage سازگار با S3 روشی مقیاسپذیر برای ذخیره تصاویر، ویدئوها، اسناد، بکاپها و سایر فایلهای محصولات دیجیتال است. در این مقاله، معماری استاندارد، مزایا، چالشها، الزامات امنیتی و نکات مهم پیادهسازی آن را بررسی میکنیم.
در بسیاری از محصولات دیجیتال، بخش قابلتوجهی از دادههای سیستم را فایلها تشکیل میدهند: تصاویر کاربران، ویدئوها، اسناد، فایلهای پشتیبان، خروجی گزارشها، فایلهای صوتی، محتوای دانلودی و حتی لاگهای آرشیوی.
در مراحل ابتدایی توسعه، ممکن است ذخیره این فایلها روی دیسک همان سروری که اپلیکیشن روی آن اجرا میشود، ساده و منطقی به نظر برسد. اما با افزایش کاربران، رشد حجم دادهها، اضافهشدن چند سرور و نیاز به پایداری بیشتر، این روش بهسرعت به یک محدودیت جدی تبدیل میشود.
اینجاست که Object Storage سازگار با S3 به یکی از اجزای مهم معماری محصولات مقیاسپذیر تبدیل میشود.
Object Storage یا «ذخیرهسازی شیءگرا» روشی برای نگهداری فایلها و دادههای غیرساختیافته است.
در این مدل، هر فایل بهعنوان یک Object یا شیء ذخیره میشود. هر Object معمولاً از سه بخش تشکیل شده است:
محتوای اصلی فایل
یک شناسه یا کلید یکتا
متادیتا یا اطلاعات تکمیلی فایل
برای مثال، تصویر پروفایل یک کاربر ممکن است با چنین کلیدی ذخیره شود:
users/1842/profile/avatar.webpدر کنار این فایل میتوان اطلاعاتی مانند نوع محتوا، حجم فایل، تاریخ ایجاد، سیاست کش، سطح دسترسی و سایر ویژگیها را نگهداری کرد.
برخلاف فایلسیستمهای سنتی، Object Storage معمولاً ساختار واقعی پوشهای ندارد. مسیرهایی که شبیه پوشه دیده میشوند، در عمل بخشی از نام یا Key فایل هستند.
S3 مخفف Simple Storage Service است؛ سرویسی که توسط Amazon Web Services معرفی شد و بهمرور API آن به یکی از استانداردهای رایج صنعت برای کار با Object Storage تبدیل شد.
امروزه وقتی از عبارت S3-Compatible Object Storage استفاده میکنیم، الزاماً منظورمان استفاده از سرویس آمازون نیست.
یک سرویس سازگار با S3، سامانهای است که بخش مهمی از API، ساختار درخواستها، روش احراز هویت و عملیات متداول S3 را پیادهسازی کرده باشد. در نتیجه، نرمافزارهایی که برای Amazon S3 توسعه داده شدهاند، معمولاً با کمترین تغییر میتوانند به این سرویسها نیز متصل شوند.
نمونههایی از عملیات رایج در API سازگار با S3 عبارتاند از:
ایجاد Bucket
آپلود Object
دریافت Object
حذف Object
دریافت فهرست فایلها
کپیکردن Object
آپلود چندبخشی فایلهای بزرگ
تولید لینک موقت دانلود یا آپلود
Bucket را میتوان یک فضای منطقی برای نگهداری مجموعهای از Objectها در نظر گرفت.
برای مثال، یک پلتفرم ممکن است Bucketهای زیر را داشته باشد:
user-uploads
product-images
private-documents
system-backups
generated-reportsتفکیک فایلها در Bucketهای مختلف به مدیریت بهتر دسترسی، سیاست نگهداری، امنیت، مانیتورینگ و چرخه عمر دادهها کمک میکند.
بااینحال، ایجاد یک Bucket مجزا برای هر کاربر یا هر رکورد معمولاً تصمیم مناسبی نیست. در بیشتر معماریها، تعداد محدودی Bucket تعریف میشود و جداسازی فایلها از طریق الگوی نامگذاری Keyها انجام میگیرد.
در File Storage، فایلها در قالب پوشهها و زیرپوشهها روی یک فایلسیستم ذخیره میشوند. اپلیکیشن نیز معمولاً از طریق مسیر فایل به آنها دسترسی پیدا میکند.
/var/www/uploads/users/1842/avatar.jpgاما در Object Storage، فایل از طریق API و با استفاده از Bucket و Object Key مدیریت میشود.
Bucket: user-uploads
Key: users/1842/avatar.jpgFile Storage برای برخی کاربردهای محلی، سیستمهای کوچک یا نرمافزارهایی که به عملیات پیچیده فایلسیستمی نیاز دارند، همچنان انتخاب مناسبی است.
Object Storage بیشتر برای شرایط زیر مناسب است:
حجم زیاد فایل
رشد مداوم داده
دسترسی از چند سرور
معماری ابری یا توزیعشده
نیاز به دسترسپذیری بالا
اتصال به CDN
نگهداری بکاپ و آرشیو
مدیریت فایلهای عمومی و خصوصی
Block Storage دادهها را در قالب بلوکهای خام در اختیار سیستمعامل قرار میدهد. دیسک ماشینهای مجازی، پایگاههای داده و فایلسیستمهای سرور معمولاً روی Block Storage قرار میگیرند.
Object Storage مانند یک دیسک معمولی به سیستمعامل متصل نمیشود. اپلیکیشن از طریق HTTP API با آن ارتباط برقرار میکند.
بهصورت کلی:
نوع ذخیرهسازی
کاربرد مناسب
Block Storage
پایگاه داده، دیسک سرور و سیستمعامل
File Storage
فایلسیستم اشتراکی و دسترسی پوشهای
Object Storage
تصاویر، ویدئو، اسناد، بکاپ و فایلهای حجیم
مهمترین مزیت سازگاری با S3، کاهش وابستگی مستقیم نرمافزار به یک ارائهدهنده مشخص است.
تقریباً برای تمام زبانها و فریمورکهای مطرح، ابزارها و SDKهایی برای اتصال به S3 وجود دارد:
.NET
Java
Kotlin
JavaScript و TypeScript
Node.js
Python
PHP
Go
Rust
بسیاری از ابزارهای زیر نیز بهصورت مستقیم از S3 یا سرویسهای سازگار با آن پشتیبانی میکنند:
نرمافزارهای بکاپ
سیستمهای مدیریت محتوا
ابزارهای Data Pipeline
سامانههای پردازش تصویر
پلتفرمهای تحلیل داده
زیرساختهای Kubernetes
سرویسهای CDN
ابزارهای آرشیو و Disaster Recovery
این سازگاری باعث میشود مهاجرت بین ارائهدهندگان مختلف، در مقایسه با APIهای اختصاصی، سادهتر باشد.
البته سازگاری با S3 همیشه به معنای پشتیبانی صددرصدی از تمام قابلیتهای Amazon S3 نیست. پیش از انتخاب سرویس باید عملیات و ویژگیهای موردنیاز پروژه بررسی شوند.
تصاویر پروفایل، مدارک، فایلهای ضمیمه، ویدئوها و سایر محتوای تولیدشده توسط کاربران، از متداولترین کاربردهای Object Storage هستند.
در این معماری، فایلها از پایگاه داده جدا نگهداری میشوند و دیتابیس فقط اطلاعاتی مانند Key، نوع فایل، مالک و وضعیت آن را ذخیره میکند.
تصاویر محصولات، فایلهای دانلودی، بنرها، کاتالوگها و محتوای رسانهای را میتوان در Object Storage نگهداری و از طریق CDN منتشر کرد.
این روش فشار روی سرور اصلی اپلیکیشن را کاهش میدهد.
فایلهای بکاپ پایگاه داده، تنظیمات، خروجی سیستم و نسخههای آرشیوی را میتوان در Bucketهای خصوصی ذخیره کرد.
برای امنیت بیشتر، بهتر است بکاپها:
رمزنگاری شوند
Versioning داشته باشند
سیاست حذف مشخصی داشته باشند
در یک حساب یا محیط جداگانه نگهداری شوند
در سامانههایی که با ویدئو، صوت، تصاویر باکیفیت یا فایلهای تحلیلی بزرگ سروکار دارند، Object Storage میتواند مرکز اصلی نگهداری فایل باشد.
سرویسهای پردازشی فایل را دریافت کرده، عملیات موردنیاز را انجام میدهند و خروجی را مجدداً در Storage ذخیره میکنند.
گزارشهای PDF، فایلهای Excel، فاکتورها، صورتحسابها و خروجیهای تولیدشده توسط سیستم بهتر است بهجای نگهداری در دیتابیس، در Object Storage ذخیره شوند.
در پروژههای دادهمحور، میتوان دادههای خام یا پردازششده را با ساختار مشخص در Object Storage ذخیره کرد و سپس از ابزارهای تحلیلی برای پردازش آنها استفاده کرد.
یکی از اشتباهات رایج این است که تمام فایلها ابتدا به Backend ارسال شوند و Backend دوباره آنها را در Object Storage آپلود کند.
Client → Backend → Object Storageاین مدل برای فایلهای کوچک یا پردازشهای خاص قابلقبول است، اما در مقیاس بالا باعث مصرف پهنای باند، حافظه و منابع Backend میشود.
در بسیاری از محصولات، معماری بهتر استفاده از Presigned URL است.
Client → Backend: Request upload permission
Backend → Client: Presigned upload URL
Client → Object Storage: Direct upload
Client → Backend: Confirm uploaded fileدر این روش، Backend هویت و مجوز کاربر را بررسی میکند و یک لینک محدود و موقت برای آپلود تولید میکند. سپس فایل مستقیماً از مرورگر یا اپلیکیشن موبایل به Object Storage ارسال میشود.
مزایای این روش:
کاهش بار Backend
سرعت بیشتر آپلود
مقیاسپذیری بهتر
کاهش مصرف پهنای باند سرور
پشتیبانی بهتر از فایلهای بزرگ
Presigned URL یک آدرس امضاشده و موقت است که اجازه انجام یک عملیات مشخص را برای مدت محدودی صادر میکند.
برای مثال، یک لینک ممکن است فقط برای شرایط زیر معتبر باشد:
آپلود یک فایل مشخص
در یک Bucket مشخص
با یک Key مشخص
برای مدت پنج دقیقه
با نوع محتوای مشخص
با محدودیت حجم تعیینشده
Presigned URL نباید بهعنوان یک مجوز دائمی در نظر گرفته شود. مدت اعتبار آن باید متناسب با عملیات و حداقل زمان لازم انتخاب شود.
یکی از مهمترین تصمیمها در طراحی Object Storage، تعیین سطح دسترسی فایلها است.
فایلهایی مانند تصاویر عمومی محصولات یا محتوای بلاگ ممکن است بدون احراز هویت قابلدسترسی باشند.
این فایلها معمولاً از طریق CDN منتشر میشوند:
https://cdn.example.com/products/483/main.webpمدارک هویتی، قراردادها، فایلهای سازمانی، گزارشهای مالی و محتوای اختصاصی کاربران نباید Public باشند.
برای دسترسی به این فایلها، Backend باید:
کاربر را احراز هویت کند.
مالکیت یا سطح دسترسی را بررسی کند.
یک لینک دانلود کوتاهمدت ایجاد کند.
رویداد دسترسی را در صورت نیاز ثبت کند.
تغییر نام تصادفی فایل یا استفاده از یک URL طولانی، جایگزین کنترل دسترسی نیست.
انتخاب ساختار مناسب برای Keyها تأثیر زیادی بر نگهداری و مدیریت سیستم دارد.
یک ساختار پیشنهادی میتواند چنین باشد:
{environment}/{tenantId}/{entityType}/{entityId}/{fileId}/{variant}.{extension}مثال:
production/tenant-45/products/1942/file-7/thumbnail.webpیا برای فایلهای کاربران:
production/users/1842/documents/9f2a8c3b.pdfبهتر است در Object Key از اطلاعات حساس مانند شماره ملی، شماره موبایل، ایمیل یا نام کامل کاربر استفاده نشود.
خود فایل معمولاً در Object Storage ذخیره میشود، اما متادیتای تجاری آن باید در دیتابیس نگهداری شود.
یک مدل ساده میتواند شامل فیلدهای زیر باشد:
Id
Bucket
ObjectKey
OriginalFileName
ContentType
Size
Checksum
OwnerType
OwnerId
Visibility
Status
CreatedAt
UploadedAt
DeletedAtوضعیت فایل نیز میتواند یکی از مقادیر زیر باشد:
Pending
Uploaded
Processing
Ready
Rejected
Deletedاین State Machine از ثبت فایلهای ناقص، استفاده از فایلهای پردازشنشده و ایجاد رکوردهای بدون Object جلوگیری میکند.
راهاندازی Object Storage بدون طراحی امنیتی مناسب میتواند باعث افشای مستقیم اطلاعات کاربران شود.
قاعده امن این است که تمام Bucketها Private باشند، مگر اینکه عمومیبودن آنها یک نیاز قطعی و مستند باشد.
هر سرویس باید فقط به Bucketها و عملیات موردنیاز خود دسترسی داشته باشد.
برای مثال، سرویس تولید گزارش ممکن است به مجوزهای زیر نیاز داشته باشد:
PutObject
GetObjectاما احتمالاً نباید اجازه حذف تمام فایلهای Bucket یا تغییر تنظیمات آن را داشته باشد.
Access Key و Secret Key نباید داخل Repository، فایلهای Frontend یا Imageهای Docker قرار بگیرند.
این اطلاعات باید از طریق Secret Manager، متغیرهای محیطی امن یا سازوکارهای مدیریت هویت زیرساخت تزریق شوند.
صرفاً بررسی پسوند فایل کافی نیست. بهتر است موارد زیر کنترل شوند:
MIME Type
امضای واقعی فایل یا Magic Bytes
حداکثر حجم
پسوند مجاز
تعداد فایل
ابعاد تصویر
مدت ویدئو یا صوت
Checksum
در سامانههایی که فایل کاربران را دریافت میکنند، بهتر است فایل قبل از انتشار یا استفاده نهایی، توسط سرویس امنیتی یا آنتیویروس بررسی شود.
فایل جدید میتواند ابتدا در مسیر قرنطینه قرار گیرد:
quarantine/{fileId}پس از تأیید:
safe/{fileId}رمزنگاری باید هم برای انتقال داده و هم برای داده ذخیرهشده در نظر گرفته شود:
TLS برای ارتباطات
Server-Side Encryption
کلیدهای مدیریتشده
در پروژههای حساس، رمزنگاری سمت اپلیکیشن
برای آپلود فایلهای بزرگ، ارسال تمام فایل در یک درخواست ریسک بالایی دارد. قطع ارتباط ممکن است باعث شود آپلود از ابتدا تکرار شود.
در Multipart Upload، فایل به چند بخش تقسیم میشود. هر بخش جداگانه آپلود شده و در پایان، Storage آنها را به یک Object نهایی تبدیل میکند.
این قابلیت برای موارد زیر اهمیت دارد:
فایلهای ویدئویی
بکاپهای حجیم
آرشیوها
اتصالهای ناپایدار
اپلیکیشنهای موبایل
آپلودهای طولانی
سیستم باید آپلودهای ناقص را نیز مدیریت کند؛ زیرا بخشهای رهاشده میتوانند بهمرور فضای ذخیرهسازی و هزینه ایجاد کنند.
با فعالکردن Versioning، جایگزینی یا حذف یک فایل الزاماً نسخه قبلی را از بین نمیبرد.
این قابلیت برای فایلهای حساس و بکاپها مفید است و امکان بازیابی نسخههای قبلی را فراهم میکند.
البته Versioning میتواند مصرف فضا و هزینه را افزایش دهد. بنابراین باید همراه با Lifecycle Policy استفاده شود.
Lifecycle Policy مجموعه قوانینی برای مدیریت خودکار چرخه عمر Objectها است.
برای مثال:
حذف فایلهای موقت پس از ۲۴ ساعت
حذف Multipart Uploadهای ناقص پس از ۷ روز
انتقال بکاپهای قدیمی به فضای آرشیوی
نگهداری گزارشها برای یک سال
حذف نسخههای قدیمی پس از ۹۰ روز
حذف فایلهای Soft Delete شده پس از دوره بازیابی
بدون Lifecycle Policy، Object Storage ممکن است به انبار دائمی فایلهای بلااستفاده تبدیل شود.
برای فایلهای عمومی یا نیمهعمومی، قرار دادن CDN در مقابل Object Storage مزایای مهمی دارد:
کاهش زمان بارگذاری
کاهش مصرف پهنای باند Storage
توزیع محتوا در موقعیتهای جغرافیایی مختلف
مدیریت بهتر Cache
محافظت از Origin
پشتیبانی از دامنه اختصاصی
معماری کلی:
User → CDN → Object Storageدر این مدل، Storage بهعنوان Origin عمل میکند و کاربران فایلها را از CDN دریافت میکنند.
برای فایلهای خصوصی نیز میتوان از Signed URL یا Signed Cookie در سطح CDN استفاده کرد.
پایگاه داده میتواند فایل را در قالب Binary یا BLOB ذخیره کند، اما این روش برای اکثر فایلهای حجیم انتخاب مناسبی نیست.
ذخیره فایل در دیتابیس ممکن است باعث موارد زیر شود:
افزایش شدید حجم دیتابیس
سنگینشدن بکاپ و بازیابی
افزایش مصرف منابع
پیچیدهشدن Replication
کاهش کارایی Queryها
افزایش هزینه نگهداری
در بیشتر محصولات، الگوی مناسب این است:
Database → File metadata and relations
Object Storage → Actual file contentالبته برای فایلهای بسیار کوچک، دادههای تراکنشی خاص یا سیستمهای دارای الزام فنی مشخص، ذخیره در دیتابیس همچنان میتواند قابلبررسی باشد.
Object Storage برای نگهداری تعداد بسیار زیادی فایل طراحی شده و بدون وابستگی به یک سرور اپلیکیشن میتواند توسعه پیدا کند.
فایلها با حذف، جایگزینی یا Scale شدن سرور اپلیکیشن از بین نمیروند.
کتابخانهها، ابزارها و سرویسهای زیادی از API سازگار با S3 پشتیبانی میکنند.
انتشار تصاویر، ویدئوها و فایلهای عمومی با کارایی بالاتر انجام میشود.
امکان تعریف Policy، دسترسی محدود، لینک موقت و تفکیک سرویسها وجود دارد.
Object Storage با Container، Kubernetes، Serverless و معماری Microservice سازگاری بالایی دارد.
اگر لایه Storage بهدرستی طراحی شود، مهاجرت بین ارائهدهندگان سازگار با S3 سادهتر خواهد بود.
Object Storage جایگزین تمام انواع ذخیرهسازی نیست.
عملیاتی مانند ویرایش بخشی از فایل، Lock فایل یا تغییرات تصادفی داخل فایل، معمولاً مانند فایلسیستم سنتی انجام نمیشوند.
برای تغییر یک Object، اغلب باید نسخه جدیدی از آن آپلود شود.
دسترسی به فایلها از طریق شبکه و API انجام میشود. بنابراین Latency، Timeout و خطاهای ارتباطی باید در طراحی لحاظ شوند.
برخی ارائهدهندگان فقط عملیات اصلی را پشتیبانی میکنند و ممکن است در قابلیتهایی مانند Replication، Event Notification، Object Lock یا Policyها تفاوت داشته باشند.
علاوه بر فضای ذخیرهسازی، هزینههای زیر نیز باید بررسی شوند:
ترافیک خروجی
تعداد درخواستها
عملیات خواندن و نوشتن
بازیابی فایلهای آرشیوی
Replication
CDN
نگهداری نسخههای قدیمی
پیش از انتخاب ارائهدهنده، بهتر است این موارد بررسی شوند:
پشتیبانی از Presigned URL
Multipart Upload
Versioning
Lifecycle Policy
CORS
Encryption
Event Notification
Object Lock
Replication
دسترسی عمومی و خصوصی
Domain و CDN اختصاصی
SLA
سیاست نگهداری داده
تعداد نسخههای داده
مانیتورینگ
گزارش مصرف
Audit Log
Disaster Recovery
کیفیت مستندات
پشتیبانی فنی
قیمت هر گیگابایت
هزینه ترافیک خروجی
هزینه درخواستها
حداقل مصرف
هزینه بازیابی
هزینه CDN
هزینه انتقال داده بین سرویسها
محل نگهداری داده، قوانین حریم خصوصی، الزامات قراردادی و محدودیتهای دسترسی بینالمللی نیز باید بررسی شوند.
یک معماری استاندارد میتواند شامل اجزای زیر باشد:
Web / Mobile Client
│
▼
Backend API
│
├── Authentication & Authorization
├── File Metadata Database
├── Presigned URL Generation
└── File State Management
│
▼
Object Storage
│
┌───────────┴───────────┐
▼ ▼
File Processing Worker CDN
│ │
▼ ▼
Antivirus / Resize / OCR End Userدر این معماری:
Backend مجوز آپلود را صادر میکند.
Client فایل را مستقیماً آپلود میکند.
وضعیت فایل در دیتابیس ثبت میشود.
Worker فایل را پردازش یا بررسی میکند.
نسخههای بهینهشده تولید میشوند.
فایل نهایی از طریق CDN یا لینک خصوصی ارائه میشود.
ذخیره URL کامل باعث وابستگی به Domain، CDN و ارائهدهنده میشود.
بهتر است Bucket و Object Key ذخیره شوند و URL هنگام نیاز ساخته شود.
برای سادهکردن توسعه، گاهی کل Bucket عمومی میشود. این تصمیم ممکن است باعث افشای فایلهای خصوصی فعلی یا آینده شود.
نام اصلی فایل ممکن است شامل کاراکترهای نامعتبر، اطلاعات شخصی یا الگوهای خطرناک باشد. بهتر است برای Object Key از شناسه تولیدشده توسط سیستم استفاده شود.
اگر سیستم فقط یک لینک آپلود صادر کند اما تکمیل عملیات را ثبت نکند، فایلهای ناقص و بدون مالک ایجاد میشوند.
حذف فایل از Storage در همان Transaction دیتابیس همیشه قابلاعتماد نیست؛ زیرا Object Storage بخشی از Transaction دیتابیس نیست.
روش مطمئنتر استفاده از Outbox Pattern و Worker حذف فایل است.
آپلودهای ناقص، فایلهای موقت و Objectهای بدون رکورد باید بهصورت دورهای شناسایی و پاکسازی شوند.
بدون محدودیت مناسب، یک کاربر میتواند حجم زیادی از فضای ذخیرهسازی یا پهنای باند سیستم را مصرف کند.
در محصولات Multi-Tenant، جداسازی داده مشتریان اهمیت زیادی دارد.
دو رویکرد رایج وجود دارد:
tenant-1/...
tenant-2/...
tenant-3/...این مدل مدیریت سادهتری دارد، اما Policyها و کنترل دسترسی باید با دقت طراحی شوند.
این روش جداسازی بیشتری ایجاد میکند، اما با افزایش تعداد مشتریان، مدیریت Bucketها و تنظیمات پیچیدهتر میشود.
انتخاب بین این دو مدل به الزامات امنیتی، تعداد مشتریان، محدودیت ارائهدهنده و ساختار عملیاتی سیستم وابسته است.
Object Storage برای سناریوهای زیر ممکن است انتخاب اصلی مناسبی نباشد:
اجرای مستقیم پایگاه داده
فایلهایی که دائماً بخشی از آنها تغییر میکند
سیستمهایی که به File Lock نیاز دارند
پردازشهایی که نیازمند فایلسیستم محلی با Latency بسیار پایین هستند
نرمافزارهای قدیمی که فقط مسیر فایل محلی را پشتیبانی میکنند
در برخی معماریها، ترکیب چند مدل ذخیرهسازی بهترین نتیجه را ایجاد میکند:
Block Storage برای دیتابیس
Local Disk موقت برای پردازش
Object Storage برای فایل نهایی
CDN برای توزیع محتوا
Object Storage سازگار با S3 فقط یک فضای آپلود فایل نیست؛ بلکه یکی از اجزای زیربنایی محصولات دیجیتال مدرن و مقیاسپذیر است.
با استفاده صحیح از این فناوری میتوان:
فایلها را از سرور اپلیکیشن جدا کرد
بار Backend را کاهش داد
آپلود فایلهای بزرگ را مدیریت کرد
فایلهای عمومی را از طریق CDN منتشر کرد
دسترسی به فایلهای خصوصی را کنترل کرد
بکاپ و آرشیو قابلاعتمادتری ایجاد کرد
امکان مهاجرت بین زیرساختهای مختلف را حفظ کرد
بااینحال، موفقیت این معماری به انتخاب سرویس مناسب محدود نمیشود. ساختار Object Key، مدیریت متادیتا، سیاست دسترسی، Presigned URL، Lifecycle، امنیت، پردازش فایل و پاکسازی دادههای رهاشده باید از ابتدای طراحی محصول در نظر گرفته شوند.
در رادکسا، زیرساخت ذخیرهسازی صرفاً بهعنوان یک فضای نگهداری فایل دیده نمیشود. انتخاب و پیادهسازی Storage باید بر اساس معماری محصول، مدل دسترسی کاربران، الزامات امنیتی، هزینه عملیاتی و مسیر رشد سیستم انجام شود.