Object storage vs block storage: co jest lepsze?

Object storage wygrywa dla plików wgrywanych przez użytkowników, zasobów statycznych, kopii zapasowych i archiwów — zasadniczo wszystkiego, do czego dostęp uzyskujesz przez HTTP i rzadko modyfikujesz w miejscu. Block storage wygrywa, gdy potrzebujesz losowych zapisów z niskim opóźnieniem: bazy danych, woluminy boot, wysokotransakcyjne systemy plików. Dla workloadów transferu plików object storage jest prawie zawsze właściwym wyborem, bo skaluje się horyzontalnie, kosztuje 0,015–0,023 USD/GB/miesiąc wobec 0,08–0,125 USD/GB/miesiąc dla bloku i obsługuje buckety petabajtowej skali bez repartycjonowania.

Jak faktycznie różnią się od środka

Block storage eksponuje surowe urządzenie (LUN lub wolumin EBS), które OS formatuje ext4, XFS lub NTFS. Odczyty i zapisy odbywają się w blokach o stałym rozmiarze, zazwyczaj 4 KB lub 16 KB, przez iSCSI, NVMe-oF lub SCSI. OS jest właścicielem systemu plików; urządzenie blokowe nic nie wie o plikach, zna tylko offsety.

Object storage eksponuje API HTTP (S3, Azure Blob, GCS), gdzie każdy obiekt ma klucz, bajty i metadane. Nie ma pod spodem systemu plików — obiekty to atomowe jednostki, które PUT-ujesz i GET-ujesz w całości. Zapisy generują nowe wersje; nie możesz modyfikować bajtu 1 000 000 w obiekcie 2 GB bez przepisania całego obiektu. Ta niemutowalność to funkcja: umożliwia replikację multi-region, wersjonowanie i reguły lifecycle, których block storage nie może łatwo odtworzyć.

Szybkie porównanie

| Wymiar | Object Storage | Block Storage | |--------|----------------|---------------| | Typowe API | S3 HTTP REST | POSIX + iSCSI/NVMe | | Koszt (AWS gorąca warstwa) | 0,023 USD/GB/mies. | 0,08 USD/GB/mies. (gp3) | | Maks. pojedynczy obiekt | 5 TB per obiekt | 64 TiB per wolumin EBS | | Latencja | 10–100 ms | Poniżej milisekundy | | Równoczesni czytelnicy | Nieograniczeni | Zazwyczaj jeden host naraz | | Deklarowana trwałość | 11 dziewiątek (S3) | 5–6 dziewiątek (EBS) | | Dobre dla | Pliki, media, backupy | Bazy danych, dyski boot | | Złe dla | Losowe zapisy do dużych plików | Skalowanie poza jeden wolumin |

Przepustowość vs latencja: różni zwycięzcy

Wolumin EBS gp3 obsługuje odczyty 4 KB poniżej 1 ms; GET S3 dla tych samych 4 KB zajmuje 20–80 ms w zależności od regionu. Dla dziennika write-ahead PostgreSQL wykonującego 5 000 transakcji na sekundę, ta przerwa latencji jest rujnująca. Dla użytkownika pobierającego plik .zip 500 MB — nieistotna, bo opóźnienie pierwszego bajtu zanika za przepustowością.

Przy sekwencyjnej przepustowości object storage często wygrywa w skali. S3 może obsługiwać jeden bucket z prędkością 5 500 żądań GET/sekundę na prefiks, a z partycjonowaniem częstości żądań (klucze z prefiksem hashu) to idzie w dziesiątki tysięcy. Jeden wolumin gp3 ma maksimum 1 000 MB/s i 16 000 IOPS. Dla dziesięciu użytkowników równocześnie pobierających plik 10 GB, object storage nasyca ich łącza; block storage staje się wąskim gardłem.

Koszt w skali

Dla 100 TB mediów o chłodnym dostępie:

• S3 Standard: 2 300 USD/miesiąc
• S3 Standard-IA: 1 250 USD/miesiąc
• S3 Glacier Instant Retrieval: 400 USD/miesiąc
• S3 Glacier Deep Archive: 99 USD/miesiąc
• EBS gp3: 8 000 USD/miesiąc
• EBS st1 (HDD zoptymalizowany pod przepustowość): 4 500 USD/miesiąc

Block storage nie ma warstw. Płacisz ceny dostępu szczytowego za dane, których dotykasz raz w roku. Reguły lifecycle object storage przenoszą obiekty automatycznie: gorące przez 30 dni, Standard-IA przez 60, Glacier po 90. Dla serwisu transferu plików przechowującego uploady z wygaśnięciem 7 dni, object storage z regułą Expiration jest dramatycznie tańszy niż prowadzenie serwera opartego na EBS.

Spójność i współbieżność

S3 zapewnia teraz silną spójność read-after-write dla PUT i DELETE, globalnie. Azure Blob i GCS odpowiadają. To usunęło jeden z historycznych zarzutów wobec object storage — kiedyś zdarzały się niespodzianki z „eventual consistency", gdy świeżo wgrany plik dawał 404 przez kilka sekund.

Ale równoczesni pisarze nadal mają znaczenie. Block storage zazwyczaj zakłada jednego pisarza; tryby multi-attach istnieją, ale dodają złożoność. Object storage pozwala milionowi klientów PUT-ować jednocześnie, z semantyką last-writer-wins (lub wersjonowaniem, żeby zachować wszystkie). Dla systemu udostępniania plików, gdzie dwóch użytkowników może wgrać różne pliki z tym samym kluczem, wersjonowanie na buckecie zachowuje oba.

Kiedy aplikacje transferu plików i tak potrzebują block storage

Zastrzeżenie: aplikacja obsługująca object storage często działa na hostach opartych na bloku. API uploadu plików potrzebuje lokalnego dysku do tymczasowego buforowania (chunki multipart, skanowanie antywirusowe), storage metadanych (zazwyczaj PostgreSQL na EBS) i logów. Same obiekty trafiają do S3/R2/Blob; maszyneria wokół nich żyje na bloku.

Dla uploadów strumieniowych o wysokiej przepustowości, pipeline'y in-memory biją dysk. Biblioteki takie jak aws-sdk-js i boto3 obsługują strumieniowe uploady multipart, które nigdy nie trafiają na lokalny dysk. Dobrze dostrojony serwis uploadu może przepchnąć plik 5 GB od klienta do object storage przy mniej niż 500 MB RAM i zero plików tymczasowych.

Metadane: subtelna różnica

Object storage nosi metadane z każdym obiektem: metadane systemowe (rozmiar, mtime, etag), metadane użytkownika (dowolne pary klucz-wartość, nagłówki x-amz-meta-*) i tagi. Możesz wyszukiwać po metadanych przez S3 Object Lambda, raporty Inventory lub parując z DynamoDB. Block storage pozostawia metadane całkowicie systemowi plików, co oznacza, że otagowanie 10 milionów plików wymaga własnej bazy danych.

Dla aplikacji transferu, która musi natychmiast odpowiedzieć na pytanie „znajdź wszystkie pliki powyżej 100 MB wgrane w zeszłym tygodniu przez użytkowników z Polski", metadane obiektów plus inwentarz Parquet pozwalają zapytać przez Athena w sekundach. To samo pytanie na woluminie blokowym zamontowanym przez NFS to polecenie find, które trwa godziny.

Szyfrowanie i kontrola dostępu

Oba typy storage obsługują szyfrowanie at rest z AES-256. Object storage ułatwia kontrolę dostępu per-obiekt: polityki bucketu, presigned URL, ACL obiektów i warunki IAM. Dostęp do block storage jest grubszy — cały wolumin jest podłączony albo nie.

Dla bezpiecznego udostępniania plików z ograniczonymi czasowo linkami pobierania, presigned URL S3 (ważne maksymalnie 7 dni) to standardowy wzorzec. Dla transferów z zerową ekspozycją jawnego tekstu po stronie serwera, szyfrowanie po stronie klienta przed uploadem działa z każdym object store. HexaTransfer szyfruje AES-256-GCM w przeglądarce i przechowuje tylko szyfrogram — backend obiektowy widzi bezużyteczne bajty.

Prosta reguła decyzyjna

Zadaj trzy pytania:

1. Czy dostęp do danych uzyskujesz przez API systemu plików (POSIX, SMB, NFS)? Jeśli tak — block lub file storage.
2. Czy dostęp przez HTTP, rzadko mutację i chcesz nieograniczonej skali? Jeśli tak — object storage.
3. Czy zbiór danych przekracza 10 TB i rośnie? Prawie zawsze object storage.

Dla workloadów transferu plików odpowiedź na (2) jest zawsze twierdząca. Używaj S3, R2, Azure Blob lub GCS dla samych plików i rezerwuj block storage dla bazy danych i warstwy webowej, która nimi zarządza.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.