Bedakan object storage dari basis data

Pertanyaan

Apa yang object storage janjikan, apa yang tidak, dan kapan kamu masih butuh basis data di sampingnya?

Setelah baca ini, kamu bisa memisahkan metadata dari byte, menjelaskan kenapa objek immutable, memakai range read dan checksum dengan benar, dan membandingkan biaya replikasi penuh dengan erasure coding.

Prasyarat dan contoh

Kamu sudah baca M09.05 Perhitungkan compaction, jadi paham kenapa menimpa data di tempat itu mahal. Replikasi dari M08 dan model akses dari M04 dianggap sudah kamu kenal.

Aplikasi menyimpan 50 juta foto, rata-rata 3 MB, total 150 TB. Menyimpannya sebagai kolom BLOB di basis data membuat backup, replikasi, dan buffer pool ikut membengkak. Menyimpannya di object storage dan menaruh hanya URL di basis data memperbaiki itu, tapi membawa aturan baru.

Mekanisme

1. Objek = byte immutable + metadata. Objek diidentifikasi oleh bucket + key (nama datar, bukan direktori sungguhan: foto/2026/a.jpg hanyalah string). Metadata berisi ukuran, tipe konten, waktu, checksum, dan atribut kustom. API dasarnya PUT, GET, DELETE, dan LIST berdasarkan prefix. Nggak ada "ubah 100 byte di tengah". Mengubah berarti menulis objek baru dengan key sama (atau key baru) sebagai versi utuh.

2. Pisahkan metadata dari data. Di dalam, sistem biasanya memakai layanan metadata (key -> lokasi potongan data, ukuran, checksum) dan layanan penyimpanan data (potongan byte besar). Alasannya sama dengan M09.03: metadata kecil, sering diakses, dan butuh transaksi. Byte besar sebaiknya dilayani sekuensial. Di sisi aplikasi, prinsip serupa: simpan metadata bisnis (pemilik, status, izin) di basis data, dan byte di object storage.

3. Range read. GET dengan header Range: bytes=1048576-2097151 hanya mengambil 1 MB tengah dari objek. Berguna untuk melanjutkan unduhan, membaca footer file Parquet tanpa mengunduh semuanya, atau memutar video dari tengah. Perhitungkan latensi: tiap permintaan punya biaya tetap puluhan milidetik, jadi 1.000 range kecil jauh lebih lambat dari satu range besar. Gabungkan rentang berdekatan.

4. Checksum. Hitung hash (misal SHA-256 atau CRC32C) di klien sebelum unggah dan kirim, supaya layanan bisa menolak byte yang rusak di jalan. Saat baca, hitung ulang dan bandingkan. Hati-hati dengan ETag: pada banyak layanan, ETag objek hasil multipart upload bukan MD5 isi, jadi jangan dipakai sebagai checksum isi tanpa membaca dokumentasi layananmu. Sistem juga melakukan scrubbing berkala: membaca ulang potongan dan membandingkan dengan checksum untuk menangkap bit rot sebelum replika terakhir ikut rusak.

5. Replikasi dan erasure coding.

• Tiga replika: 150 TB data memakai 450 TB. Toleran dua kehilangan, baca dan pemulihan sederhana, overhead 3x.
• Erasure coding 8+4: data dipotong jadi 8 bagian, ditambah 4 bagian paritas. Toleran kehilangan 4 bagian dari 12, overhead 12/8 = 1,5x, jadi 150 TB memakai 225 TB. Harganya: baca saat ada bagian hilang dan rekonstruksi harus membaca beberapa bagian lain, dan overhead CPU serta jaringan lebih besar.

Tempatkan replika atau bagian di failure domain berbeda (rak, zona), kalau tidak, satu kejadian bisa menghilangkan semuanya.

6. Konsistensi dan konkurensi. Pastikan apa yang layananmu jamin untuk baca setelah tulis dan untuk LIST setelah PUT. Banyak layanan modern memberi read-after-write yang kuat untuk objek, tapi itu kontrak per layanan, bukan sifat umum. Dua penulis ke key yang sama biasanya berarti yang terakhir menang, kecuali kamu memakai kondisi (misal If-None-Match atau versi) yang didukung layananmu.

Saat rancangan ini gagal

• Basis data dan objek tidak sinkron. Unggah sukses tapi insert ke basis data gagal (atau sebaliknya). Hasilnya objek yatim atau URL yang mengarah ke tidak ada. Perlu urutan yang jelas dan pembersihan terjadwal (dibahas di M15).
• Update kecil yang sering. Mengubah satu field di JSON 2 MB 100 kali per menit berarti menulis 200 MB per menit untuk 100 perubahan. Objek bukan tempat untuk itu.
• Listing yang mahal. LIST ratusan juta key dengan prefix buruk lambat dan berbiaya. Rancang key dan indeks sendiri di basis data kalau butuh pencarian.
• Banyak objek kecil. 100 juta objek 1 KB menghabiskan overhead metadata dan biaya permintaan jauh lebih besar dari byte-nya. Gabungkan jadi objek lebih besar dengan indeks internal.
• Contoh tandingan: tim memakai ETag sebagai bukti integritas. Setelah migrasi ke multipart, ETag berubah dan verifikasi gagal untuk file valid, sementara file rusak lolos di jalur lain karena tidak pernah dicek hash isinya.

Latihan

Aplikasi punya 40 juta video pendek, rata-rata 12 MB. Pemutar sering melompat ke tengah video. Metadata (pemilik, judul, status publikasi) dicari lewat query.

1. Hitung total data, dan ruang di disk untuk 3 replika vs erasure coding 8+4.
2. Di mana kamu menyimpan metadata, dan di mana byte-nya?
3. Pemutar melompat ke menit ke-3 pada video 12 MB berdurasi 6 menit dengan bitrate rata-rata. Seperti apa permintaannya? Bagaimana memastikan potongan utuh?

Lihat pembahasan+

1. 40 juta x 12 MB = 480 TB (480.000.000 MB). Tiga replika: 1.440 TB. Erasure coding 8+4 (1,5x): 720 TB. Selisih 720 TB, dengan harga pemulihan dan baca-degradasi yang lebih berat.
2. Metadata di basis data (butuh query, filter, transaksi status), byte di object storage. Basis data menyimpan bucket, key, ukuran, dan checksum.
3. Menit ke-3 dari 6 menit kira-kira di tengah, sekitar byte 6.000.000 (perkiraan kasar, bitrate sebenarnya bervariasi, atau pakai indeks segmen). Pemutar mengirim Range: bytes=6000000-7000000 dan seterusnya, memakai potongan cukup besar (sekitar 1 MB), bukan puluhan permintaan kecil. Untuk integritas: simpan checksum seluruh objek saat unggah dan verifikasi ulang di jalur proses atau scrubbing. Checksum per potongan range hanya ada kalau kamu menyimpan checksum per segmen. Jangan andalkan ETag multipart.

Terkait

• Sebelumnya: M09.05 Perhitungkan compaction.
• Struktur pemakaian ulang byte di sisi pengguna, seperti Sajikan gambar lewat CDN dan unggah langsung ke storage (M15), memakai dasar ini.
• Replikasi dan failure domain dibahas di M08. Studi kasus C05 (Google File System), lab L09, dan proyek B05 belum tersedia.

Catatan

• Asumsi: satu layanan object storage generik. Detail konsistensi, ETag, dan batas ukuran berbeda antarpenyedia, jadi baca dokumentasi layananmu.
• Skema erasure coding 8+4 hanya contoh hitungan, bukan klaim tentang konfigurasi penyedia tertentu.
• Yang nggak dibahas: versioning, lifecycle policy, enkripsi, dan kontrol akses.
• Terakhir ditinjau: 26 Oktober 2026.