Object storage არის დიდი, ბრტყელი key-value საცავი, რომელსაც HTTP-ით ელაპარაკები. მთელ ფაილს bucket-ში რაღაც სახელით დებ და მოგვიანებით იმავე სახელით მთლიანად იღებ უკან. არ არსებობს დირექტორიები, ბოლოში მიწერა ან ადგილზე რედაქტირება - შეცვალე ერთი ბაიტი და ობიექტი თავიდან ატვირთავ. S3 ამისთვის Amazon-ის API-ა და ის სტანდარტად იქცა: "S3-თავსებადი" საცავი არის ნებისმიერი სერვისი, რომელიც იმავე HTTP მოთხოვნებს პასუხობს, ამიტომ AWS CLI, rclone, restic, Cyberduck და ყველა S3 ბიბლიოთეკა მასთან მუშაობს ერთი პარამეტრის, endpoint-ის, შეცვლით. ეს მოდელი ზუსტად სწორია backup-ებისთვის, ატვირთული მედიისთვის, სტატიკური ფაილებისა და არქივებისთვის და არასწორია ბაზებისთვის და ყველაფრისთვის, რასაც პროგრამა გამუდმებით არედაქტირებს. ეს პოსტი მოდელს რიგიანად ხსნის, რომ ამ სერიის დანარჩენ ხელსაწყოებს აზრი ჰქონდეს.
Bucket-ები, ობიექტები და key-ები#
სამი არსებითი სახელი მთელ მონაცემთა მოდელს ფარავს.
- Bucket სახელიანი კონტეინერია. ყოველი ობიექტი ზუსტად ერთ bucket-შია. credential-ები და პარამეტრები ჩვეულებრივ bucket-ის დონეზე მოქმედებს.
- ობიექტი არის მონაცემები - ნებისმიერი ბაიტები, ნულიდან ძალიან დიდამდე - პლუს მათ შესახებ მეტამონაცემები.
- Key არის ობიექტის სახელი bucket-ის შიგნით.
backups/2026-10-08/world.tar.gzერთი key-ია; დახრილი ხაზები მასში უბრალოდ სიმბოლოებია.
Amazon S3-ზე bucket-ის სახელი 3-დან 63 სიმბოლომდეა, შედგება პატარა ასოებისგან, ციფრებისგან, დეფისებისა და წერტილებისგან, იწყება და მთავრდება ასოთი ან ციფრით და IP მისამართს არ ჰგავს. S3-თავსებადი სერვერები ხშირად მეტს იღებენ, მაგრამ თუ მხოლოდ პატარა ასოებს, ციფრებსა და დეფისებს გამოიყენებ, bucket გადატანადი დარჩება და მოგვიანებით წერტილების გამო სერტიფიკატის პრობლემებს აირიდებ. Key შეიძლება იყოს UTF-8-ის 1,024 ბაიტამდე და თითქმის ყველაფერს შეიცავდეს, თუმცა ჰარები, +, # და არა-ASCII სიმბოლოები ნაკლებად ფრთხილ ხელსაწყოებში URL-კოდირების ბაგებს იწვევს.
საქაღალდეები ილუზიაა
Bucket-ის შიგნით სახელების სივრცე ბრტყელია. რასაც ხელსაწყოები საქაღალდეებად აჩვენებენ, ჩამონათვალის ხრიკია: მოითხოვე key-ები პრეფიქსით backups/ და გამყოფით /, და სერვერი დააბრუნებს ობიექტებს უშუალოდ ამ პრეფიქსის ქვეშ, პლუს შემდეგი დონის "საერთო პრეფიქსების" სიას - backups/2026-10-07/, backups/2026-10-08/ - რომლებსაც კლიენტები საქაღალდეებად ხატავენ.
bucket: renode-backups backups/2026-10-07/world.tar.gz backups/2026-10-07/db.sql.gz backups/2026-10-08/world.tar.gz media/avatars/u123.pngშედეგები, რომლებიც პირდაპირ აქედან გამომდინარეობს:
- "ცარიელი საქაღალდე" არ არსებობს, თუ რომელიმე ხელსაწყომ მის გასაყალბებლად
/-ით დამთავრებული ნულბაიტიანი ობიექტი არ შექმნა. - საქაღალდის სახელის გადარქმევა ნიშნავს მისი პრეფიქსის ქვეშ ყოველი ობიექტის კოპირებასა და წაშლას. მილიონ ობიექტზე ეს ორი მილიონი მოთხოვნაა.
- ჩამონათვალი გვერდებად იყოფა - S3-ის
ListObjectsV2ერთ მოთხოვნაზე მაქსიმუმ 1,000 key-ს აბრუნებს - ამიტომ დიდი bucket-ის დათვლას ბევრი ორმხრივი მოთხოვნა სჭირდება.
რა არის სინამდვილეში ობიექტი#
ობიექტი არის უცვლელი ბაიტები პლუს მეტამონაცემები. მეტამონაცემები, რომელთა ცოდნაც ღირს:
| ველი | რა არის |
|---|---|
Content-Length | ზომა ბაიტებში |
Content-Type | MIME ტიპი, რომელიც ბრაუზერებს უბრუნდება - მედიისთვის სწორად დააყენე |
ETag | ვერსიის ანაბეჭდი; მარტივი ატვირთვებისთვის ჩვეულებრივ კონტენტის MD5 |
Last-Modified | როდის ჩაიწერა ეს ვერსია |
x-amz-meta-* | შენი საკუთარი key-value მეტამონაცემები, დაყენებული ატვირთვისას |
Cache-Control, Content-Disposition | გადაეცემა HTTP კლიენტებს |
მეტამონაცემები ობიექტის ჩაწერისას დგინდება. მათი შეცვლა ნიშნავს ობიექტის საკუთარ თავზე კოპირებას ახალი მეტამონაცემებით - სერვერისთვის ეს კიდევ ერთი სრული ჩაწერაა.
დიდი ობიექტები ნაწილებად იტვირთება. Multipart upload იწყება, აგზავნის ნაწილებს (Amazon-ზე თითოეული 5 MiB-დან 5 GiB-მდე, ბოლოს გარდა, 10,000 ნაწილამდე) და სრულდება; შემდეგ სერვერი მათ ერთ ობიექტად აწყობს. ნაწილები პარალელურად იტვირთება და ჩავარდნილი ნაწილი ცალკე მეორდება, რის გამოც ყველა სერიოზული ხელსაწყო გარკვეული ზღვრის ზემოთ multipart-ზე გადადის. Multipart ობიექტის ETag ფაილის MD5 არ არის - ის მთავრდება --ით და ნაწილების რაოდენობით - ამიტომ ხელსაწყოებმა, რომლებიც ატვირთვებს ETag-ით ამოწმებენ, უნდა იცოდნენ, რომელი სახის ატვირთვა გააკეთეს. Amazon-ზე ერთი PUT 5 GiB-ით არის შეზღუდული, ობიექტი კი 5 TiB-ით; სხვა იმპლემენტაციები საკუთარ ლიმიტებს აწესებენ.
დაუმთავრებელი multipart upload ნაწილებს ინახავს, სანამ არ დასრულდება ან არ გაუქმდება. ხელსაწყოები ჩვეულებრივ თავის ნაგავს თავად ალაგებენ, მაგრამ ავარიულად შეწყვეტილმა ატვირთვამ შეიძლება დატოვოს ნაწილები, რომლებიც ადგილს იკავებს და ობიექტად არ ჩანს. aws s3api list-multipart-uploads --bucket NAME მათ გაჩვენებს.
API უბრალოდ HTTP-ია#
ყოველი ოპერაცია endpoint-ზე გაგზავნილი HTTP მოთხოვნაა. სწორედ ამიტომ არის S3-ის მხარდაჭერა ასე მარტივი და ამიტომ მუშაობს ის ჩვეულებრივი proxy-ებისა და firewall-ების გავლით.
| ოპერაცია | HTTP მოთხოვნა |
|---|---|
| ობიექტის ატვირთვა | PUT /bucket/key |
| ობიექტის ჩამოტვირთვა | GET /bucket/key (Range header მის ნაწილს იღებს) |
| მხოლოდ მეტამონაცემების წაკითხვა | HEAD /bucket/key |
| ობიექტის წაშლა | DELETE /bucket/key |
| ობიექტების ჩამონათვალი | GET /bucket?list-type=2&prefix=... |
| სერვერის მხარეს კოპირება | PUT /bucket/newkey x-amz-copy-source-ით |
| Bucket-ის შექმნა | PUT /bucket |
დიაპაზონიანი GET-ები ხდის object storage-ს გამოსადეგს ვიდეოს სტრიმინგისთვის და ისეთი backup ხელსაწყოებისთვის, როგორიცაა restic, რომელიც დიდი pack ფაილებიდან პატარა ნაწილებს კითხულობს. სერვერის მხარეს კოპირება კი "სახელის გადარქმევას" ჩამოტვირთვის გარეშე შესაძლებელს ხდის.
Credential-ები და ხელმოწერები
იღებ ორ სტრიქონს: access key ID-ს, რომელიც გაიდენტიფიცირებს და საიდუმლო არ არის, და secret access key-ს, რომელიც საიდუმლოა. საიდუმლო ქსელში არასოდეს იგზავნება. სამაგიეროდ, კლიენტი ყოველ მოთხოვნას Signature Version 4-ით ხელს აწერს: აგებს მოთხოვნის კანონიკურ აღწერას (მეთოდი, გზა, query, შერჩეული header-ები, body-ის hash) და ითვლის HMAC ჯაჭვს საიდუმლოდან, თარიღიდან, რეგიონიდან და სერვისის სახელიდან. სერვერი ხელმოწერას საიდუმლოს საკუთარი ასლით თავიდან ითვლის და მოთხოვნას უარყოფს, თუ ისინი განსხვავდება.
ორი პრაქტიკული შედეგი:
- რეგიონი ხელმოწერის ნაწილია. კლიენტი და სერვერი მასზე უნდა შეთანხმდნენ. Amazon-ს ნამდვილი რეგიონები აქვს; S3-თავსებადმა endpoint-მა შეიძლება ნებისმიერი სახელი მიიღოს. აირჩიე ერთი -
us-east-1ჩვეული შემავსებელია - და ყველა ხელსაწყოში ერთი და იგივე გამოიყენე. - დროს მნიშვნელობა აქვს. ხელმოწერა შეიცავს დროის ნიშნულს, და Amazon უარყოფს მოთხოვნებს, რომლებიც მისი საათიდან 15 წუთზე მეტით არის დაშორებული, შეცდომით
RequestTimeTooSkewed. სერვერი გაფუჭებული საათით გაუგებარ ხელმოწერის შეცდომებს იძლევა; ყველაფერზე ადრეdateშეამოწმე.
ხელმოწერა ასევე შესაძლებელს ხდის presigned URL-ებს: ბმულს ხელმოწერით query სტრიქონში, რომელიც შეზღუდული დროით მოქმედებს და credential-ების არმქონე ადამიანს ერთი კონკრეტული ობიექტის ატვირთვის ან ჩამოტვირთვის საშუალებას აძლევს. მათ ფარავს S3 presigned URL-ები ატვირთვებისთვის.
Endpoint-ები, მისამართები და HTTPS#
Endpoint სერვისის საბაზისო URL-ია. მოთხოვნები bucket-ს ორიდან ერთი გზით ასახელებს:
- Path-style:
https://s3.example.com/my-bucket/photos/cat.jpg- bucket გზის პირველი სეგმენტია. - Virtual-hosted style:
https://my-bucket.s3.example.com/photos/cat.jpg- bucket ქვედომენია.
Amazon virtual-hosted სტილს ამჯობინებს; ბევრი S3-თავსებადი სერვერი, განსაკუთრებით ერთმომხმარებლიანი, ერთ ჰოსტის სახელზე, path-style-ს იყენებს, რადგან მას wildcard DNS ან wildcard სერტიფიკატი არ სჭირდება. ხელსაწყოების უმეტესობა ნაგულისხმევად virtual-hosted-ს იყენებს და გადასართავად ერთი პარამეტრი სჭირდება. მიზეზებს დეტალურად განიხილავს Path-style თუ virtual-hosted S3.
გამოიყენე HTTPS ყველაფრისთვის, რაც ინტერნეტს კვეთს. SigV4 ხელმოწერა იცავს secret key-ს და ხელს უშლის მოთხოვნის ხელმოწერილი ნაწილების გაყალბებას, მაგრამ უბრალო HTTP-ზე ობიექტის მონაცემები, key-ების სახელები და შენი access key ID გზაზე მყოფ ნებისმიერს შეუძლია წაიკითხოს. RE:NODE-ზე endpoint უბრალო HTTP-ს თავის პორტზე პასუხობს და ყოველ გეგმას აქვს proxy slot: მიმართე ჰოსტის სახელის A ჩანაწერი მასზე და სერტიფიკატი ავტომატურად გაიცემა და განახლდება, ასე რომ კლიენტები შენს საკუთარ სახელს HTTPS-ით უკავშირდებიან.
რას გპირდება "S3-თავსებადი" და რას არა#
S3 API-ის ბირთვი - bucket-ები, PUT, GET, HEAD, DELETE, ჩამონათვალი, multipart upload-ები, კოპირება, presigned URL-ები - თითქმის ყველა თავსებად სერვერში ერთნაირად არის რეალიზებული და ეს არის ყველაფერი, რაც backup-ისა და სინქრონიზაციის ხელსაწყოებს სჭირდება. Amazon-ის S3-ს ასევე აქვს ფუნქციების გრძელი კუდი, რომელიც ამის თავზე დგას: ვერსიონირება, lifecycle წესები, რომლებიც ობიექტებს ვადას უსვამს ან გადააქვს, object lock ერთხელ ჩაწერადი შენახვისთვის, bucket policy-ები და IAM, საცავის კლასები, როგორიცაა Glacier, მოვლენების შეტყობინებები, რეპლიკაცია და სერვერის მხარის დაშიფვრის რამდენიმე სახეობა. თავსებადი სერვერები ამ კუდის სხვადასხვა ქვესიმრავლეს ახორციელებენ, ან არცერთს.
ამიტომ "S3-თავსებადი" ნიშნავს "შენი S3 ხელსაწყოები დაუკავშირდება და მონაცემებს გადაიტანს" და არა "AWS-ის დოკუმენტაციის ყველა ფუნქცია არსებობს". სანამ რაიმე ფუნქციაზე დაყრდნობით რამეს დააპროექტებ, შეამოწმე, რომ სერვისი, რომელსაც იყენებ, მას გთავაზობს.
RE:NODE-ის საცავის ხაზი ბირთვის ტერმინებით არის აღწერილი: S3-თავსებადი endpoint, access key და secret key, რომლებიც თითოეული სერვერისთვის გენერირდება, შენთვის შექმნილი პირველი bucket, path-style მისამართები, ნებისმიერი რეგიონის სახელი, და ის მუშაობს AWS CLI-თან, rclone-თან, Cyberduck-თან, restic-თან და აპლიკაციების S3 დრაივერებთან. ვერსიონირება, lifecycle წესები, object lock და bucket policy-ები ამ აღწერის ნაწილი არ არის, ამიტომ მათზე ნუ დაგეგმავ. backup-ების შენახვის ვადა backup ხელსაწყოს ეკუთვნის - მაგალითად, restic-ის forget პოლიტიკას - რასაც დამატებითი სარგებელიც აქვს: ის ერთნაირად მუშაობს ნებისმიერ S3 endpoint-თან, რომელზეც მოგვიანებით გადახვალ.
შემდეგ არის თანმიმდევრულობა. 2020 წლის დეკემბრიდან Amazon S3 იძლევა ჩაწერის შემდეგ წაკითხვის მკაცრი თანმიმდევრულობის გარანტიას: როგორც კი PUT დაბრუნდება, ყოველი GET და ჩამონათვალი მას ხედავს. ერთკვანძიანი თავსებადი სერვერების უმეტესობა ბუნებრივად ასე იქცევა, მაგრამ ეს იმპლემენტაციის თვისებაა და არა API-ის, და 2020 წლამდე დაწერილი ხელსაწყოები ნაკლების ასატანად არის აგებული.
რისთვის გამოდგება object storage და რისთვის არა#
კარგი შემთხვევები:
- Backup-ები და არქივები. ერთხელ ჩაწერილი, იშვიათად წაკითხული, ამისთვის შექმნილი ხელსაწყოებით. ორ მთავარ ხელსაწყოს ფარავს Restic backup-ები S3-ზე და rclone S3 საცავთან.
- მომხმარებლების ატვირთვები და მედია. ავატარები, მიმაგრებული ფაილები, სურათები. აპლიკაცია key-ს თავის ბაზაში ინახავს და ფაილს URL-ით ემსახურება; აპლიკაციის სერვერის დისკი პატარა რჩება და ატვირთვები deploy-ს გადაურჩება. კოდს აჩვენებს S3 Node-იდან და Python-იდან, ხოლო CMS ვერსიას - WordPress-ის მედიის გადატანა S3-ზე.
- სტატიკური ფაილები და build არტეფაქტები. ვერსიიანი ფაილის სახელები, ერთხელ ჩაწერილი.
- ლოგები და ექსპორტები. მხოლოდ მისაწერი მონაცემები, რომლებიც ახალ ობიექტებად ტრიალებს.
ცუდი შემთხვევები:
- ბაზები. ბაზა გამუდმებით წერს დიდი ფაილების პატარა ნაწილებს. Object storage-ს მხოლოდ მთლიანი ობიექტების ჩანაცვლება შეუძლია. მასში ბაზის dump-ები შეინახე და არა ბაზები.
- ადგილზე რედაქტირებადი ფაილები. ცხრილი, რომელიც ყოველ წუთს ინახება, ყოველ წუთს სრული ატვირთვაა.
- მილიონობით პაწაწინა ფაილი. ყოველი ობიექტი ერთ მოთხოვნას და გარკვეულ მეტამონაცემებს ჯდება. პატარა ფაილები არქივებში შეფუთე, რასაც ზუსტად backup ხელსაწყოები აკეთებენ.
- ფაილური სისტემის პირდაპირი შემცვლელი. Bucket-ის
rclone mount-ით ან მსგავსით მიერთება დათვალიერებისა და დროდადრო კოპირებისთვის მუშაობს, მაგრამ აპლიკაციები, რომლებიც POSIX სემანტიკას ელიან - lock-ები, სახელის გადარქმევა, ნაწილობრივი ჩაწერა - მასზე ცუდად იქცევიან.
საიმედოობა: ერთი ასლი მაინც ერთი ასლია#
Amazon S3 Standard-ისთვის თერთმეტი ცხრიანის საიმედოობას აცხადებს, რადგან ყოველ ობიექტს რამდენიმე მონაცემთა ცენტრში ჭარბად ინახავს. ეს მაჩვენებელი Amazon-ის საცავის დიზაინის თვისებაა და არა S3 API-ის, და S3-თავსებადი სერვისი ზუსტად იმდენად საიმედოა, რამდენადაც მის უკან მდგომი დისკები და ასლები.
RE:NODE-ის საცავის ხაზი შენი მონაცემების ერთ ასლს ინახავს, NVMe-ზე, ერთ ლოკაციაზე გერმანიაში. ის არ რეპლიცირდება. ეს მას backup-ებისთვის კარგ მეორე ადგილად აქცევს - იმ მანქანის გარეთ, რომელსაც იცავენ, და ფორმატში, რომელზეც ყველა backup ხელსაწყო ლაპარაკობს - და ცუდ ერთადერთ ადგილად. ყველაფრისთვის, რისი დაკარგვაც არ შეგიძლია, მიჰყევი 3-2-1 წესს: სამი ასლი, ორი სახის საცავზე, ერთი სულ სხვაგან. როგორ გამოიყურება ეს, დეტალურად განიხილავს S3 საცავის ზომა და 3-2-1 წესი, ხოლო სერვერის backup-ები, რომლებიც მართლა აღდგება ხსნის, რატომ აქვს აღდგენის ტესტს ასლზე მეტი მნიშვნელობა.
FAQ#
S3 და Amazon S3 ერთი და იგივეა?
S3 დაიწყო როგორც Amazon-ის Simple Storage Service, და სახელი ახლა მის API-საც აღნიშნავს, რომელსაც ბევრი სხვა პროვაიდერი და ღია კოდის სერვერი ახორციელებს. როცა ხალხი AWS-ის გარეთ "S3 საცავს" ამბობს, ჩვეულებრივ S3-თავსებადს გულისხმობს: იგივე მოთხოვნები, სხვა endpoint.
შემიძლია object storage-ში ფაილის ნაწილი დავარედაქტირო?
არა. ობიექტები მთლიანად იცვლება. ობიექტის ნაწილის წაკითხვა დიაპაზონიანი GET-ით შეგიძლია, მაგრამ ჩაწერა ნიშნავს სრული ახალი ვერსიის ატვირთვას. ხელსაწყოები, რომლებიც თითქოს ადგილზე არედაქტირებენ, სინამდვილეში ჩამოტვირთავენ, ცვლიან და თავიდან ტვირთავენ.
რა განსხვავებაა object storage-სა და block storage-ს შორის?
Block storage დისკია: ოპერაციული სისტემა მასზე ფაილურ სისტემას დებს და ნებისმიერ ბაიტს კითხულობს და წერს. Object storage სერვისია: მთლიან ფაილებს HTTP-ით აგზავნი და მათ key-ით მიმართავ. ბაზებსა და ოპერაციულ სისტემებს block storage სჭირდებათ; backup-ები და მედია object storage-ში უკეთ გრძნობენ თავს.
რატომ მჭირდება რეგიონი, თუ სერვერს არ აინტერესებს?
იმიტომ, რომ მოთხოვნის ხელმოწერა მას შეიცავს. კლიენტი რეგიონს ხელმოწერის key-ის გამოსათვლელად იყენებს და სერვერმა გადასამოწმებლად იგივე უნდა გამოიყენოს. Endpoint-ზე, რომელიც ნებისმიერ რეგიონის სახელს იღებს, აირჩიე ერთი და ყველა კლიენტი მასზე დააკონფიგურირე.
მჭირდება HTTPS, თუ მოთხოვნები ხელმოწერილია?
კი, ყველაფრისთვის, რაც ერთი კერძო ქსელის გარეთაა. ხელმოწერა იცავს შენს secret key-ს და ხელმოწერილი ნაწილების მთლიანობას, მაგრამ არა კონფიდენციალურობას: TLS-ის გარეშე შენი ფაილების შიგთავსი და მათი სახელები ღია ტექსტად მოგზაურობს.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.