S3 adalah Teknologi Penyimpanan Berkas, Bukan Sistem Berkas

 (calpaterson.com)
2 poin oleh GN⁺ 2024-03-11 | 1 komentar | Bagikan ke WhatsApp
  • Amazon S3 adalah teknologi cloud awal yang muncul pada 2006; kuat untuk penyimpanan berkas, tetapi bukan sistem berkas yang menggantikan Unix file API secara langsung
  • Unix file API lebih mirip modul dalam yang menyembunyikan buffering, page cache, izin, dan penjadwalan IO di balik antarmuka sempit seperti open, read, write, seek, close
  • S3 terlihat sederhana dengan fokus pada GetObject dan PutObject, tetapi hanya memungkinkan pembacaan sebagian melalui Range dan tidak mendukung penimpaan sebagian
  • Database seperti Postgres, SQLite, MySQL, MongoDB, dan Elasticsearch bergantung pada penimpaan per halaman, sehingga pendekatan mengunggah berkas SQLite atau DuckDB apa adanya ke S3 sulit cocok kecuali untuk dataset kecil
  • Bandwidth baca-tulis yang tinggi dan beban operasional yang rendah adalah keunggulan S3, tetapi batasan seperti tidak adanya rename/move, listing yang lambat, API khusus XML, dan tidak adanya lingkungan pengujian lokal juga perlu dipertimbangkan

S3 menyimpan berkas, tetapi bukan sistem berkas

  • S3 adalah teknologi cloud awal yang muncul pada 2006, dan sesuai istilah yang populer saat itu, disebut “object store”
  • Dalam praktiknya S3 banyak digunakan sebagai penyimpanan berkas, tetapi memahaminya seperti “Amazon Cloud Filesystem” hanya sebagian benar
  • S3 memang bagus untuk menyimpan berkas, tetapi tidak bisa menggantikan perilaku dan ekspektasi sistem berkas tradisional secara langsung

Unix file API dan modul dalam

  • Inti Unix file API dapat diringkas menjadi lima panggilan berikut
    • open(filepath): membuka berkas
    • file.read(size=100): membaca dari posisi saat ini dan memajukan posisi
    • file.write("hello, world"): menulis di posisi saat ini dan memajukan posisi
    • file.seek(94): memindahkan posisi ke byte tertentu
    • file.close(): menutup berkas
  • Panggilan-panggilan ini merupakan inti dari seluruh system call yang sebenarnya, dan mendekati fungsi minimum yang diperlukan untuk membaca dan menulis berkas
  • Karena banyak pemrosesan terjadi di balik antarmuka yang sempit, Unix file API dapat dilihat sebagai modul dalam (deep module)
    • Buffering dan page cache
    • Penanganan fragmentasi
    • Manajemen izin
    • Penjadwalan IO
    • Bahkan fitur seperti wear-levelling pada kartu SD memberi manfaat tanpa pengguna harus memikirkannya langsung

Modul dangkal dan YAML, ORM

  • Modul dangkal memiliki permukaan API yang relatif besar dibanding fungsi yang ditanganinya
  • Salah satu petunjuk untuk mengenali modul dangkal saat ini adalah ketika antarmukanya berupa YAML
    • YAML terlihat seperti bahasa markup, tetapi dalam praktiknya digunakan seperti sintaks yang dapat dipakai ulang untuk menambahkan hampir segala jenis semantik
    • Di ranah DevOps, YAML sering berperilaku seperti “bahasa pemrograman”
    • Jika mini-language YAML menyediakan struktur perulangan, ada kemungkinan ia Turing-complete
  • Modul dangkal tidak selalu buruk
    • SQL ORM pada dasarnya adalah abstraksi yang bocor dan sulit digunakan tanpa memahami SQL
    • Dalam beberapa kasus, modul dangkal bisa menjadi bentuk terbaik yang mungkin
  • Dengan kondisi yang sama, modul yang lebih dalam lebih baik

API S3 sederhana, tetapi berbeda dari file API

  • Unix file API terbentuk pada awal 1970-an, dan demi kompatibilitas antarmukanya tetap dipertahankan sementara implementasi internalnya berkali-kali berubah
  • Amazon S3 tidak mengimplementasikan ulang API sistem berkas Unix
  • Operasi dasar S3 hanya sebagian berpadanan dengan Unix file API
    • GetObject(Bucket, Key, Range=None): membaca seluruh atau sebagian objek
    • PutObject(Bucket, Key): menulis seluruh objek
  • Ada konsep tambahan bernama bucket, tetapi jika hanya melihat rasio antara fungsi dan antarmuka, S3 bisa dianggap lebih sederhana daripada Unix file API
  • Perbedaan penentunya adalah tidak adanya penimpaan sebagian
    • Argumen Range pada GetObject memungkinkan pembacaan sebagian objek
    • Menimpa hanya sebagian objek tidak dimungkinkan
    • Penimpaan harus dilakukan pada seluruh berkas
  • Karena perbedaan ini, S3 hanya cocok untuk sebagian use case berkas tradisional

Database sulit dipindahkan begitu saja ke S3

  • Banyak database menyimpan data dalam berkas di atas sistem berkas
    • Postgres mempertahankan 2–3 berkas per tabel serta berbagai berkas manajemen
    • SQLite dikenal menyimpan semua data dalam satu berkas
    • MySQL, MongoDB, dan Elasticsearch juga menyimpan data dalam berkas
  • Masalahnya, database umumnya bergantung pada penimpaan sebagian per halaman
    • Data biasanya disimpan dalam halaman seperti 4KB atau 8KB
    • Di dalam heap file bisa terdapat ribuan halaman
    • Halaman ditimpa sebagian untuk menyimpan data yang diperlukan
  • Jika database SQLite ditempatkan di S3, setiap penulisan harus menulis ulang seluruh berkas database
  • S3 dapat memproses penulisan besar dengan cepat, tetapi kecuali untuk dataset paling kecil, strategi menimpa seluruh berkas setiap kali sulit ditanggung
  • Jika berkas database ditulis ulang setiap saat, integritas transaksi yang dibuat oleh implementor database juga sulit dimanfaatkan
  • Di S3, penulisan terakhir yang menang

Hal yang dikuasai dan tidak dikuasai S3

  • Keunggulan S3 adalah bandwidth baca dan tulis yang sangat tinggi
    • Tidak sulit menemukan contoh di internet yang menulis atau membaca lebih dari 10GB per detik ke/dari S3
    • Ada juga pengalaman ketika operasi tulis S3 memenuhi jaringan kantor pelanggan finansial
  • Selain tidak adanya penimpaan sebagian, ada batasan lain yang membedakannya dari sistem berkas
  • S3 tidak memiliki operasi rename atau move
    • Perubahan nama ditangani dengan CopyObject lalu DeleteObject
    • CopyObject membutuhkan waktu linear yang sebanding dengan ukuran berkas
    • Menulis banyak berkas ke lokasi yang salah lalu mengembalikannya akan sangat lambat
  • Listing berkas lambat
    • Bandwidth baca-tulis sangat tinggi, tetapi operasi mendaftar item yang tersimpan jauh lebih lambat
    • Bahkan bisa lebih lambat daripada sistem berkas lokal yang lambat
  • Sebaliknya, beban operasional lebih rendah dibanding sistem berkas
    • Cukup tentukan bucket dan nama key, sisanya ditangani cloud
    • Mengurangi beban pekerjaan berulang seperti backup, replikasi offsite, dan provisioning
    • Provisioning berlaku bukan hanya untuk kapasitas, tetapi juga untuk operasi IO

Modul dalam lebih penting pada antarmuka antarorganisasi

  • Fakta bahwa S3 adalah API cloud populer pertama terkait dengan keunggulan API yang dalam
  • API yang dalam berguna untuk menyembunyikan kompleksitas antar modul di dalam satu sistem, dan menjadi lebih penting dalam hubungan berbiaya tinggi seperti interaksi antara dua perusahaan
  • Koneksi sistem komputer antarperusahaan secara tradisional disebut integration, dan diperlakukan seperti sinonim dari penderitaan
  • Perangkat lunak enterprise besar seperti SAP bukanlah modul dalam
    • Hampir seluruh organisasi harus memahami SAP
    • Harus terus disesuaikan dengan cara kerja yang sudah ada
    • Proyek integrasi SAP mahal dan besar, dengan kasus kegagalan yang berulang
  • Kompleksitas internal S3 bukan berarti jauh lebih kecil daripada instalasi SAP
    • Amazon menyebut S3 “Simple Storage Service”, tetapi kompleksitas S3 yang sebenarnya besar
    • Mencakup teori antrean, kontensi IO, sharding, dan berbagai masalah yang ditangani sistem berkas
  • “Simple” pada S3 lebih dekat pada antarmuka yang dalam daripada kesederhanaan nyata

Pengecualian yang cocok untuk S3 dan batasan yang tersisa

  • Ini bukan berarti mengesampingkan masalah bahwa S3 bisa mahal untuk use case tertentu
  • Konsep modul dalam dan modul dangkal berasal dari A Philosophy of Software Design karya John Ousterhout
  • Ada juga database yang sejak awal dirancang untuk menggunakan API S3 sebagai lapisan penyimpanan
    • Snowflake adalah salah satu contohnya
    • Namun ini bukan pemindahan transparan, melainkan memerlukan keputusan desain sejak awal
    • Snowflake adalah contoh yang mengambil keputusan ini sangat awal, setidaknya hingga 2016
  • Bukan hanya database yang mengalami kesulitan di S3
    • Banyak format berkas mengasumsikan seek yang murah
    • Berkas Zip adalah contoh utama yang performanya lebih baik di disk daripada di S3

Hal yang disayangkan dari S3

  • API S3 hanya XML
    • JSON sudah ada pada 2006, tetapi saat itu XML lebih dominan
    • Sayang Amazon tidak merilis versi JSON saat beralih dari SOAP ke REST
  • Amazon juga menghentikan pemeliharaan XSD schema
    • Salah satu keunggulan utama API XML adalah skema, tetapi dokumen standar saat ini adalah situs web
  • Amazon tidak menyediakan lingkungan pengujian lokal
    • Di Python, untuk pengujian yang teliti, sebagian orang menggunakan library moto
    • Meski moto adalah alat pengujian untuk layanan komersial, ia dikelola oleh para sukarelawan
  • Amazon S3 mendukung checksum, tetapi tidak diaktifkan secara default
    • Amazon membuat berbagai klaim tentang durabilitas
    • Saya belum pernah mendengar adanya masalah nyata, tetapi juga belum melihat contoh klaim semacam itu diuji
  • Dahulu S3 memiliki jebakan eventual consistency
    • Setelah membaca dan menimpa berkas lalu membacanya lagi, Anda bisa melihat konten yang belum berubah
    • Ini sesekali terjadi dalam waktu singkat dan menimbulkan kebingungan
    • Implementasi S3 lain tidak meniru karakteristik ini, dan Amazon juga memperbaikinya beberapa tahun lalu dengan strong read-after-write consistency

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-11
Pendapat Hacker News

  • Durabilitas S3 mungkin terlihat dilebih-lebihkan, tetapi dapat dipercaya, dan sulit dibandingkan dengan sistem berkas tradisional
    Perbedaannya bukan hanya pada perangkat lunak, tetapi juga mencakup infrastruktur fisik dan budaya keselamatan; isolasi Availability Zone AWS terasa lebih baik dibanding cloud lain
    Saat bekerja di S3, sering sekali dibandingkan dari sisi harga dengan GCP Blob Storage, tetapi Google bisa menaruh data di gedung yang sama atau di ruangan berbeda dalam gedung yang sama, sehingga itu bukan perbandingan yang adil dengan pemisahan ala AWS
    Seluruh organisasi sangat terobsesi dengan integritas data, memberi checksum pada segala hal, dan juga bersiap menghadapi peristiwa besar seperti bencana alam
    Pada skala S3, bahkan bit rot seperti pembalikan bit acak akibat sinar gamma mengenai platter hard disk pun dapat dideteksi, dan mereka mengukur tingkat kegagalan berdasarkan produsen disk serta periode produksi, sehingga menurunkan kemungkinan kehilangan data bahkan jika batch tertentu rusak
    Sampai-sampai saya tidak akan menyimpan data penting di tempat lain, dan saya sendiri membangun sistem deployment S3

    • Penasaran seperti apa pengalaman di perusahaan storage lain
      Penjelasan ini terdengar seperti memuji Cinnabon karena membuat adonannya sendiri; hal-hal yang disebutkan itu biasanya memang dilakukan perusahaan storage
      Memberi checksum pada semuanya adalah fitur dasar banyak sistem berkas, dan jika komputer rumahan pun bisa mendeteksi bit rot serta memberi notifikasi, perusahaan storage besar tentu melakukannya
      Pelacakan tingkat kegagalan berdasarkan produsen disk juga umum, perusahaan storage bahkan menerbitkan laporan, dan organisasi IT berisi 6 orang pun pernah mengelolanya dengan spreadsheet
      Di luar AWS pun, jauh sebelum AWS ada, sudah banyak orang pintar yang bekerja di bidang storage
    • Isolasi Availability Zone AWS tidak lebih baik daripada semua penyedia lain
      Akun geo-redundant rsync.net, misalnya, berada di negara bagian atau negara berbeda, seperti storage utama di Fremont dan storage sekunder di Denver
      Klaim bahwa S3 dapat mendeteksi bit rot karena skalanya juga tidak tepat; menjalankan ZFS di server pribadi pun dapat mendeteksi bit rot dengan baik pada skala kecil
      [1] kantor pusat he.net
    • Memberi checksum pada data bukan semata-mata karena paranoia, melainkan karena untuk menjalankan algoritma Reed-Solomon, kita perlu tahu blok mana yang tidak dapat digunakan, sehingga hal itu memang diperlukan secara alami
      Jika kejadian kerusakan seperti ini cukup banyak, tampaknya itu juga bisa dipakai sebagai sinyal untuk “menyembuhkan” sistem dengan memindahkan blok data individual ke mesin lain
      Secara umum, hal-hal yang disebutkan cukup lazim dalam sistem storage, dan bukan ciri khas S3 saja
    • Klaim bahwa Google menyimpan data di gedung yang sama tampaknya tidak benar
      Menurut dokumentasi Google Cloud Storage, data direplikasi ke beberapa zona, dan tiap zona dipetakan ke kluster yang berbeda
      https://cloud.google.com/compute/docs/regions-zones/zone-vir...
    • Daripada “percaya saja”, saya ingin mempercayai hasil pengujian
      Saya penasaran apakah ada pihak ketiga netral yang memverifikasi durabilitas, integritas, dan konsistensi S3 seketat Jepsen
      Jika seseorang membandingkan berbagai cloud storage yang kompatibel dengan S3 secara ketat, mungkin akan terungkap masalah-masalah besar yang menakutkan, atau mungkin perbandingan semacam itu sudah ada

  • Menurut saya, yang benar-benar berguna di S3 bukan kecepatan baca/tulis, melainkan listing
    Pada bucket tanpa versi atau tanpa delete marker, listing untuk prefix tertentu pada dasarnya berjalan seperti waktu konstan, sehingga bahkan pada bucket berisi 100 miliar objek, kita bisa meminta 1000 key menurut urutan alfabet yang muncul setelah string acak tertentu
    Menggunakan / sebagai delimiter hanyalah nilai default, dan karakter apa pun bisa digunakan untuk mendapatkan kumpulan prefix bersama; direktori sebenarnya tidak ada, hanya tampak seolah dibuat saat dibutuhkan
    Berkat karakteristik ini, data dapat dipartisi dengan berbagai cara berdasarkan identifier yang dibutuhkan tanpa perlu mengkhawatirkan performa
    Jika listing hanya lambat, tidak bisa melakukan pencarian berbasis prefix file, dan melambat sebanding dengan jumlah key seperti sistem berkas Unix tradisional, S3 sama sekali tidak akan berguna

    • Saya tidak terlalu yakin
      Kemampuan mengambil key di sekitar sebelum dan sesudah sebuah prefix adalah dasar indeks database yang sudah ada sejak 1970-an, jadi tidak terlalu mengesankan
      Use case bisa saja berbeda, tetapi sering kali listing bucket lambat dan mengganggu, dan ketika bucket sedikit saja membesar, waktu untuk menampilkan daftar key menjadi lebih lama daripada waktu membacanya
      Sepingat saya, listing berada di bawah 1Mbps, tetapi saya tidak punya bucket besar untuk langsung diuji sekarang
    • Perbedaan antara hierarki key leksikografis yang datar dan hierarki sistem berkas yang tersarang sebagai direktori menjadi jelas lewat contoh
      Jika ada dir1/a/000000 sampai dir1/a/999999 dan ada dir1/b, maka pada sistem berkas hierarkis sungguhan, ls dir1/ cukup menelusuri dan mengembalikan dua item, yaitu "a" dan "b"
      Sebaliknya, storage key-value dengan indeks string datar tanpa pemrosesan delimiter harus melewati 1 juta entri direktori dari "a/00000" hingga "a/999999" sebelum mencapai "b"
      Jadi hierarki datar sederhana membuat listing isi satu direktori menjadi O(semua anak rekursif), bukan O(anak langsung) seperti sistem berkas sungguhan, sehingga jauh lebih lambat
      Namun jika algoritma listing diberi tahu karakter delimiter seperti /, trie prefix leksikografis dapat melewati subtree secara efisien pada / berikutnya
      Dokumentasi Amazon S3 juga menyatakan bahwa field CommonPrefixes melewati dan merangkum jutaan key yang tersarang di level lebih dalam
      https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-...
      Saya belum menguji apakah implementasi nyatanya benar-benar menghemat traversal, atau hanya mengurangi hasil setelah traversal, tetapi saya berharap memang menghemat
    • Sejak XFS pada 1993, sistem berkas UNIX yang bagus dan dipengaruhi HPFS telah mengimplementasikan direktori dalam suatu bentuk B-tree
      Karena itu, kinerjanya tidak melambat sebanding dengan jumlah entri, dan listing berbasis prefix file juga sangat cepat
    • Sepertinya 99% penggunaan S3 adalah mengambil objek dengan key yang sudah diketahui
      Rasanya aneh melihat listing prefix sebagai fitur inti
    • Saya tidak tahu apakah definisi “waktu konstan” di sini sama
      Mendapatkan 1000 key dalam satu panggilan jaringan tidak menjamin apa pun tentang kompleksitas di backend

  • Baru-baru ini saat mengutak-atik skrip manajemen aset S3, saya kaget dengan kecepatan listing-nya
    Seorang rekan bilang perlu cache daftar file dan mengirimkan cache yang sudah dipraisi; awalnya saya pikir itu pasti tidak diperlukan, tetapi setelah mengeceknya sendiri ternyata berbeda
    Ada sekitar 100 ribu direktori root untuk aset individual, masing-masing berisi 5–6 direktori dan beberapa file, total file mungkin di bawah 1 juta, dengan kedalaman maksimal sekitar 3 level
    Untuk mencantumkan file-file ini secara rekursif, secara harfiah butuh 15 menit
    Saya mencoba berbagai saran peningkatan kecepatan dari Stack Overflow dan ChatGPT, tetapi tidak ada hasil yang berarti, dan saya tidak mengerti kenapa selambat ini
    Saya tidak tahu kenapa Amazon belum memperbaikinya, dan dari luar kelihatannya cukup menambahkan beberapa B-tree pada tiap bucket
    Kalau ini memang masalah yang sulit, alasannya tampaknya menarik, jadi saya ingin mendengarnya

    • S3 pada dasarnya adalah penyimpanan key-value
      Objek bisa terlihat seperti “direktori” hanya karena filter prefiks; ini bukan file system dan tidak punya konsep direktori
    • Saya agak khawatir dengan penggunaan kata “rekursif” serta penjelasan panjang soal “direktori” dan “level”
      Cara tercepat untuk mencantumkan objek di S3 sama sekali tidak membutuhkan rekursi; cukup cantumkan semua objek di bawah suatu prefiks
      Kalau memakai pemisah path untuk berpura-pura bahwa key S3 berbentuk struktur folder lalu melakukan iterasi “per folder”, itu akan jauh lebih lambat
      Saat memanggil ListObjectsV2, jangan kirim delimiter; jika tidak memakai fitur delimiter, “direktori” dan “level” tidak memengaruhi performa
      Untuk mencapai total waktu yang diinginkan, satu pekerjaan listing bisa dipecah menjadi listing paralel untuk beberapa prefiks
    • Konsekuensi menarik dari masalah ini adalah menghapus bucket S3 tidaklah sederhana
      Bucket yang berisi objek tidak bisa dihapus, dan kita juga tidak bisa sekali perintah meminta S3 menghapus semua objek
      Untuk tiap objek, kita harus mengirim permintaan API hapus tersendiri; untuk itu kita juga harus mengirim permintaan listing per 1000 objek, dan panggilan listing ini memakan waktu sekaligus biaya
      Artikel ini menjelaskan situasinya dengan baik: https://cloudcasts.io/article/deleting-an-s3-bucket-costs-mo...
      Cara tercepat untuk membersihkan bucket S3 pada akhirnya adalah menghapus akun AWS tempat bucket itu berada
    • Alasannya bisa jauh lebih biasa
      Dalam satu permintaan kita bisa mencantumkan 10 ribu objek, dan untuk mendapatkan 10 ribu berikutnya kita membutuhkan hasil permintaan sebelumnya, jadi semuanya serial
      Untuk mencantumkan 1 juta file diperlukan 100 permintaan berurutan; kalau round-trip time saja 50 ms, round trip-nya sudah 5 detik, belum termasuk biaya membuat daftar itu sendiri dalam iterasi datar
      Biaya listing 10 ribu item mirip dengan biaya write, dan ini sendiri tergolong cukup lambat; tiap listing juga mungkin berupa snapshot dengan konsistensi kuat, sehingga biayanya bertambah
      B-tree sepertinya tidak banyak membantu kecuali untuk traversal direktori, dan bahkan dalam kasus itu bottleneck kemungkinan besar ada pada operasi jaringan dan API yang diekspos ke luar
      Pada akhirnya, listing daftar file bukanlah use case yang begitu penting; biasanya kita menyerahkan pekerjaan yang diinginkan ke S3 lewat fitur seperti object lifecycle, lalu membiarkannya diproses efisien di lapisan file system internal
    • Menganggap ada direktori di dalam bucket S3 bukan model yang bagus
      Semuanya objek, dan antarmuka web hanya menyajikan prefiks yang dipisahkan slash agar enak dilihat
      Tiap objek punya key, dan key itu bisa berisi slash; kita boleh saja dengan nyaman menganggap tiap segmen sebagai direktori
      Namun ketika mencoba operasi yang biasanya dilakukan pada direktori, ilusi itu akan runtuh

  • Orang-orang yang membuat S3 tahu bahwa ini bukan file system, dan menurut saya nama object storage dimaksudkan untuk menjelaskan perbedaan-perbedaan yang ditunjukkan dalam tulisan itu
    “Objek sedang populer” merujuk pada objek sebagai komponen perangkat lunak yang menggabungkan kode eksekusi dan state lokal, tetapi contoh awal S3 bukanlah semacam “men-serialisasi objek live lalu men-deserialisasikannya di proses lain”
    Contohnya semuanya berupa aset statis situs web dan semacamnya, dan di dunia database waktu itu, makna objek juga dipakai dalam istilah “binary large object” atau “blob”
    S3 lebih mirip tempat menyimpan hal-hal yang canggung dimasukkan ke database, dan use case peluncuran saat desain awal mengasumsikan indeks konten berada di tempat lain, sehingga listing yang lambat justru menjelaskan karakter tersebut

    • Penulis tampaknya tidak tahu bahwa “object storage” adalah istilah sistem penyimpanan yang tidak ada hubungannya dengan pemrograman berorientasi objek
      https://en.wikipedia.org/wiki/Object_storage
    • Saya khawatir penulis mencampuradukkan pemrograman berorientasi objek dengan object storage
      Menurut penjelasan GCP, object storage adalah arsitektur yang membagi data tidak terstruktur menjadi unit objek dan menyimpannya dalam lingkungan data yang secara struktur datar
      https://cloud.google.com/learn/what-is-object-storage
      Dengan kata lain, hal intinya adalah data tidak terstruktur, susunan datar, serta operasi baca dan tulis pada tingkat item secara utuh

  • S3 bukan file, apalagi sistem file
    Yang diharapkan dari abstraksi file adalah kemampuan untuk diubah: harus bisa mengedit sebagian file, memperbesar, memperkecil, serta membaca dan menulis pada offset sembarang
    Setelah memegang sebuah file, seharusnya tidak perlu kembali lagi ke konsep root atau induk; tetapi S3 hanya menyediakan objek yang tidak dapat diubah di atas daftar yang dapat diubah, dan untuk mengubahnya harus menyalin lalu mengunggah ulang
    Abstraksi file yang asli adalah mencari sektor-sektor pada disk dan menampilkannya kepada klien seolah-olah sebagai buffer kontinu, sedangkan S3 memecahkan masalah yang berbeda
    Banyak orang salah memahami gagasan bagus UNIX “semuanya adalah file” sebagai berarti semuanya harus terlihat seperti buffer virtual kontinu
    Inti sebenarnya adalah ada leaf node dasar, entah itu file atau objek lain yang ingin ditampilkan sistem kepada proses, semua hal termasuk direktori dapat dicantumkan di dalam direktori, dan ada pohon rekursif
    Yang membuat sesuatu menjadi sistem file bukan tipe leaf node tertentu, melainkan direktori
    Menambahkan tipe leaf baru seperti soket atau framebuffer hampir sepele dan tidak merusak gagasan ini, tetapi menambahkan jenis container lain seperti list membuat struktur sistem file menjadi rumit dan merusak konsistensi konseptual
    S3 tidak melakukan hal-hal seperti ini, tetapi itu tidak apa-apa
    Kita hanya ingin menyimpan hal-hal yang tidak cocok dimasukkan ke database dan berharap tidak terjadi bit rot saat tidak dilihat
    Saya pikir dorongan untuk membuat S3 seperti sistem file berasal dari pelanggan yang salah memahami apa yang dikerjakan S3 dengan baik, dan manajemen produk yang menerima kesalahpahaman itu alih-alih mencegahnya

    • Saya setuju bahwa S3 bukan sistem file
      Analogi yang lebih tepat adalah perangkat penyimpanan blok, hanya saja lebih mirip perangkat blok yang sangat aneh dengan ukuran blok sembarang dan bisa diberi key
      Sistem file adalah abstraksi yang diletakkan di atas perangkat penyimpanan blok, jadi “sistem file S3” juga seharusnya merupakan abstraksi yang berada di atas S3 dengan S3 diperlakukan seperti penyimpanan blok dasar
    • Saya penasaran bagaimana sistem file read-only cocok dengan definisi ini

  • Sistem file adalah abstraksi yang dibuat di atas perangkat blok
    Perangkat blok menyediakan array byte raksasa dan memungkinkan baca/tulis per blok, misalnya “tulis 300 byte ini di posisi 273041”
    Perangkat blok itu sendiri juga merupakan abstraksi yang dibuat di atas hardware nyata, jadi perintah “tulis 300 byte ini” pada kenyataannya berujung pada tindakan seperti “gerakkan jarum pada platter nomor 2 ke posisi nomor 6”
    S3 hanyalah abstraksi lain yang dibuat di atas penyimpanan mentah, dan secara ketat merupakan penyimpanan key-object yang datar
    Jika membutuhkan fitur sistem file, implementasikan di aplikasi atau gunakan sistem file
    Jika hanya butuh append, lacak rantai append dengan database dan simpan chunk di S3; jika tidak cocok, gunakan yang lain
    Jika butuh penyalinan, buat referensi baru ke objek yang sama di database; jika tidak cocok, gunakan yang lain
    S3 cocok untuk banyak orang, jadi jangan mencoba mengubahnya menjadi sesuatu yang lain
    Kita juga harus berhenti mencoba mengubah makna istilah bidang yang sudah mapan; sistem file adalah konsep yang dijelaskan di buku teks, dan S3 tidak pernah mengklaim dirinya sebagai sistem file
    Mempelajari sedikit desain sistem operasi juga benar-benar membantu dan menyenangkan

  • Ada diskusi yang membandingkan API object_store Apache Arrow dan Apache OpenDAL di https://github.com/apache/arrow-rs/issues/3888
    Apache OpenDAL adalah library yang menyediakan API mirip sistem file di atas berbagai backend, termasuk S3 dan beberapa penyimpanan cloud
    Beberapa sistem database seperti GreptimeDB dan Databend menggunakan OpenDAL sebagai semacam SDK S3 yang lebih baik untuk mengakses data di penyimpanan cloud
    Ada juga solusi lain untuk mengelola antarmuka mirip sistem file di atas S3, seperti Alluxio dan JuiceFS, tetapi berbeda dengan Apache OpenDAL, keduanya memerlukan deployment terpisah dan layanan metadata internal khusus

    • Saya tidak begitu yakin apakah Alluxio dapat digantikan dengan OpenDAL sebagai lapisan cache lokal untuk TrinoDB

  • Saat membicarakan S3, Backblaze B2 juga layak disebut
    Harganya 3 kali lebih murah daripada S3, jadi saya sangat menyukainya, dan saya bukan orang Backblaze

    • Backblaze B2 memang murah, tetapi jika dipakai di lingkungan produksi ada hal-hal yang harus dimasukkan ke biaya
      Ada jendela pemeliharaan 2 jam setiap minggu pukul 11:30–13:30 PST, dan biasanya tidak ada downtime, tetapi kadang terjadi gangguan total tepat di tengah jam kerja AS
      Ketika tingkat error naik sampai tidak dapat digunakan, kami harus membuka tiket dukungan, dan dalam beberapa tahun terakhir hal itu terjadi kira-kira setahun sekali
      Dukungan hanya mengajukan banyak pertanyaan seolah-olah tidak punya log error atau visibilitas di sisi mereka, dan tidak benar-benar menyelidiki masalahnya
      Ada juga false success, yaitu respons mengatakan unggahan berhasil tetapi sebenarnya tersimpan sebagai 0 byte di sistem B2, jadi unggahan tetap harus diverifikasi meskipun mendapat kode sukses
      Jika muncul kerentanan dengan tingkat keparahan tinggi seperti CVE Log4j2, gangguan panjang seperti pemadaman 10 jam juga bisa terjadi
      Harganya terbaik, tetapi produknya tidak bisa dibandingkan langsung dengan layanan penyimpanan cloud yang lebih matang
    • Pada layanan alternatif, poin kuncinya selalu bahwa data hanya seaman tingkat kepercayaan kita kepada perusahaan tersebut
      Namun menurut saya hal itu bisa ditambal sampai batas tertentu dengan dua lapis backup eksternal
    • B2 bagus, tetapi tidak sampai layak dipakai jika harus membayar biaya alamat IPv4
      Mengherankan bahwa meski mengiklankan diri sebagai solusi multicloud, situasi ketika biaya NAT gateway dan IPv4 menempel di mana-mana praktis menghilangkan kemungkinan adopsinya
      Dengan pola pemakaian yang banyak membaca dan sedikit menulis, kami masih bisa menghemat uang meskipun membayar biaya bandwidth B2, tetapi tidak demikian jika harus melewati gateway NAT64 atau membayar biaya per jam untuk mengakses B2

  • Artikel yang bagus, dan akan berguna seandainya saya membacanya sebelum memulai perjalanan me-mount penyimpanan cloud sebagai FUSE dengan rclone mount
    Setelah beberapa kali iterasi, rclone akhirnya memiliki lapisan VFS yang menyesuaikan penyimpanan seperti S3, Google Cloud Storage, Azure Blob, OpenStack Swift, dan Oracle Object Storage menjadi lapisan sistem berkas yang mirip POSIX, dan kode rclone mount sebenarnya hanyalah lapisan tipis di atasnya
    Lapisan VFS memiliki beberapa tingkat kompatibilitas; pada off, ia hanya melakukan caching direktori
    Dalam mode ini, seperti yang disebutkan di artikel, Anda tidak bisa membaca dan menulis berkas yang sama secara bersamaan, tidak bisa menulis di tengah berkas, dan berkas hanya bisa ditulis secara berurutan
    Mengejutkannya, cukup banyak hal tetap berjalan baik bahkan dengan batasan seperti ini
    Tingkat berikutnya, writes, mendukung sebagian besar fitur POSIX yang diinginkan aplikasi, seperti membaca dan menulis berkas yang sama secara bersamaan serta menulis di tengah berkas, tetapi biayanya adalah membuat salinan lokal berkas dan mengunggahnya secara asinkron saat ditutup
    Dokumentasi mode caching VFS mencerminkan dengan baik batasan yang dibahas dalam artikel: https://rclone.org/commands/rclone_mount/#vfs-file-caching
    Pada dasarnya, S3 juga tidak memiliki direktori sungguhan, sehingga tidak bisa memiliki direktori tanpa berkas, dan direktori pun tidak memiliki metadata valid seperti waktu modifikasi
    Anda bisa membuat penanda direktori, yaitu berkas 0 byte yang diakhiri dengan /, dan banyak alat termasuk rclone mendukungnya
    Ketiadaan direktori kosong biasanya bukan masalah besar, karena lapisan VFS memalsukannya dan sebagian besar aplikasi segera menulis sesuatu ke dalamnya
    Pada akhirnya, mengubah sesuatu yang tampak seperti S3 agar terlihat seperti sistem berkas POSIX membutuhkan cukup banyak pekerjaan, dan ada banyak trik di balik perilaku seperti mengganti nama berkas yang sedang terbuka serta berbagai kasus tepi yang rumit
    Perintah level rendah rclone seperti move/sync/copy tidak melakukan penanganan seperti itu dan menggunakan API S3 hampir apa adanya
    Jika ada satu hal yang bisa diubah di API S3, saya ingin ada opsi untuk juga membaca metadata saat melakukan listing
    rclone menyimpan waktu modifikasi berkas di metadata objek, tetapi tidak ada cara untuk membacanya secara massal, sehingga harus melakukan HEAD untuk setiap objek
    Atau akan bagus juga jika Last-Modified objek bisa disetel saat mengunggah

    • Saya pikir mungkin bisa diakali dengan menyimpan metadata langsung di nama key
      Batas panjang key adalah 1024, jadi jumlah metadata yang bisa disimpan terbatas, tetapi bahkan dengan memperhitungkan path berkas, itu masih cukup longgar
      Anda bisa menggunakan pemisah yang tidak valid pada path yang dinormalisasi, seperti //, dan menaruhnya seperti /path/to/file.txt//mtime=1710066090
      Anda tetap bisa mengambil “direktori” dengan prefiks, dan mengambil berkas secara langsung dengan menggunakan // seperti prefiks
      Namun format seperti ini tampaknya akan sangat merusak kompatibilitas dengan perangkat lunak lain
    • Saya setuju bahwa akan bagus jika ada opsi untuk menyertakan metadata dalam listing
      Di MinIO, mereka menambahkan parameter “rahasia” metadata=true yang menyertakan metadata dan tag dalam listing ketika memiliki izin yang sesuai
      Karena ini ekstensi, tidak bisa digunakan secara andal, tetapi rclone selalu bisa mencobanya dan memakainya jika tersedia
      Berkas 0 byte yang diakhiri dengan / juga dimungkinkan, tetapi prefiks bersama dalam listing itu sendiri juga bisa dianggap sebagai direktori
      Dengan begitu, direktori menjadi tanpa status dan tidak bisa ada jika tidak ada objek di dalamnya; ini punya kelebihan dan kekurangan
      Jika Last-Modified bisa disetel saat mengunggah, batasan di sisi klien akan berkurang, tetapi ada juga keuntungan dari menjadikan waktu server sebagai acuan
      Replikasi atau mirroring di sisi klien juga harus menangani batasan yang sama
      Secara pribadi, keluhan terbesar saya adalah tidak adanya HeadObjectVersions yang mengembalikan informasi versi untuk satu objek
      ListObjectVersions tidak bisa mengetahui apakah prefiks yang diberikan adalah prefiks sungguhan atau key objek, sehingga selalu berpotensi menjadi operasi di seluruh klaster
      AWS baru-baru ini menambahkan GetObjectAttributes, tetapi informasi versi yang sebenarnya cocok dimasukkan di sana tidak disertakan

  • “Simple” dalam S3 bukan berarti “tidak dalam”, melainkan bahwa ia memiliki komponen paling sedikit yang diperlukan untuk mencapai kebutuhannya
    Jika Anda membutuhkan penyimpanan objek yang terdistribusi, tersentralisasi, tereplikasi, ber-availability tinggi, berdurabilitas tinggi, ber-bandwidth tinggi, berlatensi rendah, berkonsistensi kuat, sinkron, dapat diskalakan, ditambah HTTP REST API, saya rasa sulit membuatnya lebih sederhana daripada S3
    AWS S3 telah ditambahi banyak fitur selama bertahun-tahun, tetapi perilaku dasarnya tetap sama

    • Dengan istilah yang dipakai artikel, “komponen minimum yang diperlukan” justru berarti dalam
      Menurut 『A Philosophy of Software Design』 karya Ousterhout, sederhana berarti tidak rumit, dan “Simple Made Easy” dari Rich Hickey juga berada dalam konteks yang sama
      Sebaliknya, “dalam” berarti menyediakan banyak fungsi yang kompleks secara internal melalui antarmuka kecil, jadi untuk S3 istilah ini lebih cocok daripada “sederhana”
      Ini berbeda dari kesederhanaan dalam arti bahwa S3 tidak punya banyak hal
      https://www.infoq.com/presentations/Simple-Made-Easy/
    • Mengikuti ungkapan artikel, kesederhanaan hampir bisa dianggap mengimplikasikan kedalaman dan antarmuka yang sempit