USDB ByteDance: Latensi Tulis Turun 85,8 Persen, Biaya Infrastruktur 42,1 Persen

ByteDance melaporkan USDB, lapisan penyimpanan sekuens untuk sistem rekomendasi mereka, memangkas rata-rata latensi tulis 85,8 persen dan menurunkan biaya infrastruktur 42,1 persen setelah migrasi produksi. Angka itu tercantum di abstrak makalah arXiv 2611.02618 yang dikirim 2 November 2026, berisi 17 halaman, 18 gambar, dan 5 tabel. Inti perbaikannya bukan perangkat keras baru, melainkan pengakuan bahwa beban tulis kecil dan pembacaan riwayat panjang adalah dua hal yang saling bertabrakan di mesin yang sama.

TL;DR

• USDB memisahkan kebutuhan tulis kecil dan baca panjang lewat CascadeLSM dengan tahap kompaksi berbasis waktu.
• Rata-rata latensi tulis di catatan migrasi produksi turun 85,8 persen, biaya infrastruktur 42,1 persen lebih rendah.
• Aggregation pushdown mempertahankan throughput 8,5 kali lipat pembacaan biasa pada anggaran terima yang dibatasi.
• Replika terdiferensiasi berbagi berkas persisten, jadi data yang sama tidak disalin ulang per peran.
• Format kolumnar hibrida mempercepat proyeksi kolom tanpa mengubah seluruh pipeline.

Apa masalah storage yang diselesaikan USDB?

Model rekomendasi modern membaca riwayat pengguna yang makin panjang dan makin kaya atribut. Pola aksesnya jadi asimetris: penulisan datang sebagai pembaruan kecil dan terus-menerus, sementara pembacaan menuntut potongan riwayat yang besar sekaligus. Abstrak makalah menyebutnya "storage asymmetry" dan menempatkannya sebagai pusat masalah, bukan sebagai efek samping.

Di sistem berbasis LSM tree, asimetri ini mahal. Setiap penulisan kecil masuk ke memtable, lalu di-flush menjadi file di disk, lalu file-file itu dikompaksi berulang kali. Kompaksi menulis ulang data yang sama berkali-kali, dan biaya itu tumbuh seiring volume. Sementara itu, pembacaan panjang harus menyentuh banyak file dan banyak level, sehingga latensi ekornya melebar. Kalau lo pernah mengelola RocksDB atau Cassandra, bentuk masalahnya familiar: tulis cepat di awal, lalu menua jadi beban kompaksi.

Yang membuat kasus ByteDance menarik adalah skalanya. Sistem rekomendasi bukan basis data transaksional dengan kunci tunggal, tapi kumpulan sekuens perilaku yang dibaca berulang untuk inference dan training. Pekerjaan yang sama dilakukan tiga kali dengan tujuan berbeda: menyerap data masuk, menyiapkan input inference, dan menyusun data latih. USDB dibangun untuk memakai ulang hasil satu pekerjaan di tiga tempat itu.

Bagaimana CascadeLSM bekerja?

CascadeLSM memakai tahap kompaksi yang dipisahkan berdasarkan waktu. Idenya, riwayat pengguna punya struktur temporal: bagian terbaru dipakai untuk inference, bagian lama dipakai untuk training dan analisis. Kalau kompaksi memperlakukan semuanya sama, sistem memindahkan data panas dan data dingin dengan frekuensi yang sama, dan itu pemborosan.

Dengan tahap berbasis waktu, tiap tahap membentuk riwayat yang sesuai kebutuhan aplikasi. Data baru tetap murah ditulis, sementara data lama dipadatkan dalam bentuk yang lebih cocok untuk pembacaan panjang. Hasil kompaksi tidak dibuang setelah dipakai satu jalur, tapi disimpan sebagai materialisasi yang bisa dipakai jalur lain.

Mekanisme	Fungsi	Dampak yang dilaporkan
CascadeLSM	Kompaksi bertahap berbasis waktu	Riwayat dipadatkan sesuai pola akses, bukan seragam
Replika terdiferensiasi	Beberapa peran berbagi berkas persisten	Duplikasi penyimpanan berkurang
Partial dump	Merekonstruksi input inference dari state terbaru dan riwayat berversi	Waktu rekonstruksi lebih pendek
Format kolumnar hibrida	Mempercepat pembacaan kolom terpilih	Proyeksi kolom lebih efisien
Aggregation pushdown	Agregasi dikerjakan di lapisan penyimpanan	Throughput 8,5 kali pembacaan biasa

Replika terdiferensiasi menjawab masalah yang sering diabaikan: kalau setiap peran butuh salinan sendiri, biaya penyimpanan naik linear terhadap jumlah peran. Dengan berbagi berkas persisten, satu salinan fisik bisa melayani beberapa kebutuhan baca. Partial dump melengkapi ini dengan merekonstruksi input inference hanya dari bagian yang berubah, bukan dari seluruh riwayat.

Format kolumnar hibrida masuk di lapisan terakhir. Banyak query rekomendasi hanya butuh beberapa atribut dari puluhan yang tersedia, dan format baris memaksa membaca semuanya. Dengan penyimpanan kolumnar untuk bagian yang sering diproyeksikan, pembacaan bisa melewati kolom yang tidak dipakai.

Apakah angka 85,8 persen berlaku umum?

Tidak, dan makalahnya sendiri tidak mengklaim begitu. Angka 85,8 persen berasal dari catatan migrasi produksi, artinya kondisi sebelum dan sesudah di lingkungan ByteDance dengan pola beban mereka. Angka 42,1 persen juga dihitung lewat "normalized deployment accounting", bukan tagihan bulanan mentah.

Pembanding yang dipakai adalah baseline sekuens berbasis RocksDB yang sudah dioptimalkan. Makalah melaporkan pembacaan riwayat panjang yang lebih cepat di berbagai proyeksi dan beban klien, jadi perbandingannya bukan melawan sistem yang sengaja dibuat lambat. Tapi tetap ada batas: hasil pada satu perusahaan dengan pola akses tertentu tidak otomatis pindah ke beban transaksional biasa.

Angka 8,5 kali untuk aggregation pushdown juga punya syarat. Abstrak menyebutnya "under a constrained receive budget", jadi keuntungan itu muncul ketika jaringan atau jalur terima menjadi batas, bukan ketika CPU yang menjadi batas. Kalau agregasi di sisi klien sudah cukup cepat dan bandwidth bukan kendala, dorongan ke lapisan penyimpanan tidak memberi selisih sebesar itu.

Apa yang bisa dipelajari tim dengan skala lebih kecil?

Pelajaran paling berguna bukan menyalin arsitekturnya, tapi menyalin cara mereka memisahkan pertanyaan. Sebelum menambah mesin atau mengganti basis data, ada baiknya mengukur dulu berapa banyak pekerjaan yang terbuang karena data yang sama diproses ulang untuk tiga tujuan berbeda.

• Ukur biaya kompaksi secara terpisah dari biaya tulis. Kalau keduanya digabung dalam satu metrik, perbaikan di satu sisi akan terlihat seperti kemunduran di sisi lain.
• Periksa apakah data panas dan data dingin benar-benar perlu perlakuan yang sama. Sering tidak, dan pemisahannya bisa dilakukan tanpa mengganti engine.
• Hitung duplikasi penyimpanan antar peran. Satu salinan yang dipakai bersama biasanya lebih murah daripada tiga salinan yang masing-masing dioptimalkan.
• Sebelum memindahkan agregasi ke storage, pastikan jalur terima memang menjadi batas. Kalau tidak, keuntungannya kecil.

Untuk tim yang memakai PostgreSQL atau MySQL, sebagian ide ini sudah tersedia dalam bentuk yang lebih sederhana: partisi berbasis waktu, materialized view, dan tabel ringkasan. Yang jarang dilakukan adalah mengukur berapa besar biaya pemeliharaan yang tersembunyi di balik pembaruan kecil yang terus-menerus. Di sistem dengan pembaruan per detik, biaya itu sering menjadi pos terbesar tanpa pernah muncul di dashboard.

Yang juga layak dicatat, makalah ini menyebut pekerjaan mereka sebagai "practice", bukan produk. Tidak ada janji rilis open source di abstrak, dan tidak ada klaim bahwa komponennya tersedia untuk publik. Dokumentasi RocksDB di wiki resmi proyek tetap menjadi rujukan paling praktis kalau lo ingin memahami dasar kompaksi dan level yang dipakai USDB sebagai pembanding. Versi lengkap makalahnya bisa dibaca di PDF arXiv.

Kapan pendekatan seperti ini justru tidak cocok?

Ketika beban kerja lo tidak punya asimetri yang sama. USDB dirancang untuk sekuens perilaku yang dibaca berulang dalam potongan besar. Kalau aplikasi lo menulis satu baris lalu membacanya dengan kunci tunggal, memisahkan tahap kompaksi berbasis waktu hanya menambah kompleksitas tanpa manfaat.

Karakter beban	Cocok untuk pemisahan berbasis waktu	Lebih baik pakai pendekatan biasa
Ukuran pembacaan	Ribuan baris per permintaan	Satu atau beberapa baris per kunci
Pola tulis	Pembaruan kecil berulang pada entitas yang sama	Insert sekali, jarang diubah
Kebutuhan konsistensi	Riwayat berversi, toleran terhadap jeda materialisasi	Transaksi ketat dengan isolasi penuh
Jumlah konsumen	Inference, training, dan analitik membaca data yang sama	Satu aplikasi dengan satu pola akses

Baris terakhir yang paling sering diabaikan. Nilai USDB muncul karena satu hasil kompaksi dipakai tiga jalur sekaligus. Kalau hanya ada satu jalur, tidak ada yang bisa dipakai ulang, dan seluruh mesin tambahan itu menjadi ongkos tanpa pendapatan.

Ada juga biaya operasional yang tidak muncul di abstrak. Sistem dengan beberapa tahap kompaksi butuh pemantauan per tahap, alat untuk merekonstruksi state, dan prosedur pemulihan yang jelas ketika satu tahap tertinggal. Untuk tim kecil, beban itu bisa lebih mahal daripada penghematan yang didapat. Aturan praktisnya: tambahkan lapisan hanya ketika biaya pemeliharaannya lebih kecil dari selisih yang bisa diukur.

Yang terakhir, jangan lupa bahwa angka produksi selalu punya konteks. Migrasi di ByteDance terjadi pada sistem yang sudah berjalan, dengan data historis, beban campuran, dan tim yang memahami sistemnya. Membandingkan hasil itu dengan benchmark sintetis di laptop hanya menghasilkan kesimpulan yang menyesatkan ke dua arah: terlalu optimistis kalau percaya angkanya pindah utuh, terlalu pesimistis kalau menganggapnya tidak mungkin tercapai sama sekali.

Cara membaca makalah semacam ini yang paling aman: ambil mekanismenya, lalu uji asumsinya di beban lo sendiri. Empat mekanisme USDB bisa dipakai sebagai daftar pertanyaan. Apakah data panas dan dingin di sistem lo punya pola akses berbeda? Apakah ada salinan yang bisa dibagi antar peran? Apakah input inference bisa direkonstruksi dari sebagian state? Apakah query lo hanya butuh sebagian kolom? Kalau satu jawabannya ya, ada ruang perbaikan yang tidak menuntut penggantian engine.

Arah riset penyimpanan saat ini juga bergerak menjauh dari gagasan satu engine untuk semua beban. Pemisahan peran, materialisasi bertahap, dan format yang menyesuaikan pola baca muncul berulang di banyak sistem skala besar, dan USDB adalah salah satu contoh terbaru yang angkanya bisa diperiksa langsung di makalah.

Angka-angka ini juga berguna sebagai pembanding saat membaca klaim serupa dari perusahaan lain. Yang perlu dicari selalu sama: ukuran data, baseline yang dipakai, dan apakah angkanya dari produksi atau dari pengujian terkontrol.

FAQ

Apakah USDB bisa dipakai di luar ByteDance?

Belum ada data publik soal ketersediaan kode atau lisensi. Abstrak menyebutnya praktik internal, jadi sampai ada rilis resmi, USDB lebih tepat dibaca sebagai studi arsitektur daripada kandidat adopsi.

Apa itu LSM tree secara singkat?

Struktur penyimpanan yang menumpuk penulisan di memori, lalu menuliskannya ke berkas berurutan di disk dan menggabungkannya secara berkala. Tulis jadi cepat, tapi pembacaan dan pemeliharaan butuh kompaksi.

Kenapa sistem rekomendasi butuh penyimpanan khusus?

Karena pola aksesnya berbeda dari transaksi biasa: pembaruan kecil terus-menerus, pembacaan riwayat panjang berulang, dan data yang sama dipakai untuk inference maupun training.

Apakah angka 42,1 persen berarti tagihan turun segitu?

Tidak langsung. Angka itu hasil penghitungan biaya deployment yang dinormalisasi, bukan potongan tagihan bulanan. Komposisi harga, tenaga kerja, dan kapasitas cadangan bisa mengubah hasil akhirnya.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.