Versi UUID Dijelaskan — Berhenti Menggunakan v4 untuk Semua Hal

Di suatu tempat dalam kode Anda, ada baris yang terlihat seperti ini: id = uuid.v4(). Ini bekerja. Uji Anda lewat. Pengguna Anda tidak mengeluh. Dan setiap kali DBA melihat rencana query, dia diam-diam marah.

UUID v4 menjadi default karena sederhana, tersedia secara universal, dan cukup tahan terhadap kolisi sehingga Anda tidak akan pernah mengalami konflik. Namun, "ini bekerja" dan "ini adalah alat yang tepat" bukan hal yang sama — dan untuk kunci utama database, v4 secara aktif membuat sistem Anda lebih lambat saat skala meningkat.

Apa yang Dilakukan UUID v4 terhadap Database Anda

Database relasional menggunakan indeks B-tree untuk kunci utama. Indeks B-tree menyusun data secara terurut sehingga database dapat menemukan baris dalam waktu O(log n). Saat Anda memasukkan baris baru, database harus menempatkannya di posisi yang tepat dalam indeks yang terurut.

Dengan UUID v4, setiap ID baru adalah acak. 550e8400-e29b-41d4-a716-446655440000 mungkin diikuti oleh f47ac10b-58cc-4372-a567-0e02b2c3d479 — tidak ada hubungan antara pengisian berurutan. Database harus berpindah ke node daun acak di setiap kali pengisian.

Ini menyebabkan dua masalah saat skala besar:

• Pembagian halaman: Ketika halaman daun B-tree penuh, database harus membaginya menjadi dua halaman dan memperbarui orang tua. Dengan pengisian acak, pembagian terjadi sering di seluruh indeks — bukan hanya di ujung.
• Kesalahan cache: Pembuatan buffer database menyimpan halaman yang baru-baru ini digunakan di memori. Pengisian berurutan terus mengenai halaman "panas" yang sama. Pengisian acak menyebar pembacaan di seluruh indeks, menghancurkan cache dan memaksa bacaan dari disk.

Pada tabel dengan jutaan baris dan tingkat penulisan tinggi, fragmentasi indeks ini menambahkan keterlambatan nyata. Jika EXPLAIN ANALYZE menunjukkan bahwa waktu pemindaian indeks lebih lama dari yang seharusnya, UUID acak mungkin merupakan bagian dari diagnosis tersebut.

Pohon UUID

UUID v1: Waktu, Alamat MAC, dan Mengapa Kita Tidak Menggunakannya

UUID v1 adalah UUID awal yang "terurut". Ini mengkodekan waktu 60-bit dalam interval 100-nanosekon sejak 15 Oktober 1582, gabungan dengan urutan jam dan alamat MAC mesin Anda. Hasilnya hampir dapat diurutkan berdasarkan waktu.

Bagian alamat MAC adalah yang membunuh v1. Ini mengungkapkan identitas antarmuka jaringan server Anda ke dalam setiap ID yang dihasilkan — setiap catatan pengguna, setiap pesanan, setiap kejadian. Peneliti keamanan menunjukkan bahwa UUID v1 dari mesin yang sama dapat diprediksi setelah Anda memiliki satu contoh. Organisasi mulai menghindarinya untuk hal-hal yang terlihat oleh pengguna, dan kebanyakan library UUID menandai ini sebagai didekati.

UUID v4: Acak, Aman, dan Tidak Cocok untuk Kunci Utama

UUID v4 adalah 122 bit data acak kriptografi (bit sisa mengkodekan versi). Probabilitas kolisi untuk miliaran UUID adalah sekitar 1 dalam 10^18. Dalam praktiknya, ini nol.

Kecacatan ini tepat yang Anda inginkan untuk token keamanan, ID sesi, kunci API, dan ID korelasi — hal-hal di mana Anda membutuhkan ID yang tidak dapat ditebak atau dihitung. Untuk kasus-kasus ini, terus gunakan v4. Masalahnya adalah bahwa "tidak dapat ditebak" dan "cocok untuk database" adalah sifat yang berlawanan.

Ingin menguji generasi UUID? Generator UUID di IO Tools memungkinkan Anda menghasilkan v1, v4, v7, dan variasi lain secara bersamaan untuk melihat perbedaan struktur.

UUID v7: Default Baru yang Harus Anda Gunakan

UUID v7 disetujui oleh IETF dalam RFC 9562 pada Mei 2023. Ini menempatkan waktu Unix dalam satuan milidetik di 48 bit terpenting, diikuti oleh 4 bit versi, 12 bit penghitung urutan, dan 62 bit data acak.

Dalam praktiknya, ini berarti: UUID yang dihasilkan lebih awal lebih besar secara leksikal. Pengisian berurutan berada di posisi yang bersebelahan dalam B-tree. Tidak ada penyebaran acak, tidak ada pembagian halaman yang tidak perlu, tidak ada gangguan cache. Ini berperilaku seperti bilangan otomatis dari database dari segi perspektif — sambil tetap unik secara global tanpa koordinasi.

Penghitung urutan dalam satu milidetik memastikan urutan monoton meskipun generator berfrekuensi tinggi. Jika Anda menghasilkan 10.000 UUID dalam satu milidetik, mereka tetap diurutkan dengan benar. Suffix acak mempertahankan cukup entropi sehingga peluang kolisi antar sistem terdistribusi tetap sangat kecil.

Untuk sistem baru yang menggunakan PostgreSQL, MySQL, atau database relasional lainnya, UUID v7 harus menjadi default untuk kunci utama.

ULID: Alternatif yang Muncul Sebelum UUID v7

ULID (Universally Unique Lexicographically Sortable Identifier) memecahkan masalah yang sama sebelum UUID v7 ada. Ini menggunakan 48 bit untuk waktu Unix dalam milidetik dan 80 bit data acak, dienkripsi dalam Crockford's Base32.

Hasilnya adalah string 26 karakter yang terlihat seperti 01ARZ3NDEKTSV4RRFFQ69G5FAV alih-alih format UUID terpotong 36 karakter. Ini aman untuk URL tanpa enkripsi, diurutkan secara benar sebagai string, dan tidak case-sensitive.

ULID tidak memiliki RFC IETF — ia memiliki spesifikasi komunitas di ulid.github.io. Ini cukup untuk kebanyakan tim, tetapi jika Anda berada dalam lingkungan yang memerlukan identifikasi secara resmi, UUID v7 adalah pilihan yang lebih aman. ULID memiliki dukungan kuat dalam ekosistem JavaScript dan Go, dan jika tim Anda sudah menggunakan ULID, tidak ada alasan mendesak untuk beralih.

Perbandingan Berdampingan

Properti	UUID v1	UUID versi 4	UUID v7	ULID
Dapat diurutkan	Secara parsial	TIDAK	Ya	Ya
Tahan terhadap kolisi	Ya	Ya	Ya	Ya
Cocok untuk database	Secara parsial	TIDAK	Ya	Ya
Aman secara privasi	Tidak (alamat MAC)	Ya	Ya	Ya
Badan standar	IETF RFC 4122	IETF RFC 4122	IETF RFC 9562	Spesifikasi komunitas
Panjang biasa	36 karakter	36 karakter	36 karakter	26 karakter
Sumber entropi	MAC + jam	Acak	Waktu + acak	Waktu + acak

Kapan Menggunakan Setiap Salah Satu

UUID v7 — gunakan ini untuk kunci utama database dalam sistem baru. Ini adalah standar IETF, memiliki dukungan perangkat lunak yang berkembang (native di PostgreSQL 17, tersedia melalui perangkat lunak di setiap bahasa utama), dan memberikan urutan B-tree yang sesuai tanpa koordinasi yang diperlukan.

UUID versi 4 — tetap gunakan ini untuk hal-hal yang terkait keamanan di mana keacakan penting: token sesi, token pemulihan kata sandi, kunci API, parameter keamanan OAuth, ID korelasi dalam log. Ketidakpastian ini adalah fitur, bukan kekurangan.

ULID — gunakan jika tim Anda sudah menggunakan ULID, terutama dalam proyek JavaScript atau Go. Format yang lebih pendek benar-benar lebih baik dalam URL dan log. Jika Anda baru memulai, UUID v7 adalah pilihan yang lebih aman jangka panjang karena didukung oleh IETF.

UUID v1 — jangan. Tidak ada skenario di mana v1 adalah pilihan yang tepat untuk kode baru.

Pertimbangan Pemindahan

Jika Anda menjalankan sistem yang sudah ada dengan kunci utama UUID v4, Anda tidak perlu memindahkannya segera — dan Anda tidak seharusnya melakukannya secara sembarangan. Hubungan kunci asing, kode aplikasi, dan nilai yang mungkin disimpan di cache semua merujuk pada ID tersebut. Pemindahan membutuhkan perencanaan hati-hati dan hampir pasti membutuhkan jendela pemeliharaan.

Untuk kebanyakan tim, pendekatan pragmatis adalah: gunakan UUID v7 (atau ULID) untuk semua tabel dan layanan baru. Terima bahwa tabel lama Anda menggunakan v4 dan atasi fragmentasi dengan pemulihan indeks secara berkala jika dampak kinerja terukur. Jangan biarkan sempurna menjadi lawan dari yang baik.

Jika Anda adalah proyek baru — database baru, tabel baru — tidak ada alasan untuk menggunakan v4 untuk kunci utama. Alat yang tersedia. Buat beberapa sampel UUID v7 dan lihat apa yang Anda kerjakan.

Intinya

UUID v4 tidak salah — hanya sering digunakan secara salah. Keacakan ini adalah sifat keamanan, dan Anda harus mempertahankannya di tempat keamanan penting. Untuk kunci utama database, keacakan ini berubah menjadi beban kinerja saat skala meningkat.

UUID v7 memecahkan masalah secara bersih: meningkat secara monoton, unik secara global, standar, dan sudah didukung oleh database dan ORM yang Anda gunakan. Jika Anda menulis skema database hari ini, buat v7 sebagai default. Masa depan Anda — dan DBA Anda — akan menyadari perbedaannya.

Anda mungkin juga menyukai