Setiap basis data modern, sistem terdistribusi, dan API menggunakan pengidentifikasi unik — dan pada 2026, standar yang mengaturnya telah berubah secara mendasar. UUID (Universally Unique Identifier, pengidentifikasi unik universal) adalah label 128-bit yang dapat mengidentifikasi informasi antar sistem komputer tanpa koordinasi pusat apa pun. Di bawah RFC 9562 baru (yang menggantikan RFC 4122 pada Mei 2024), lanskapnya telah bergeser: UUID v4 tetap menjadi pilihan untuk ID acak, tetapi UUID v7 kini menjadi standar yang direkomendasikan untuk kunci utama basis data karena strukturnya yang terurut waktu mencegah fragmentasi indeks B-tree.
Panduan ini mencakup gambaran utuh: bagaimana UUID bekerja, versi mana yang dipakai kapan, dan bagaimana menerapkannya dengan benar.
Memahami RFC 9562: Standar UUID Modern
UUID adalah angka 128-bit yang keunikkannya praktis terjamin — tanpa otoritas pusat apa pun. Menurut Wikipedia, peluang dua UUID bertabrakan sangat mendekati nol sehingga dianggap mustahil untuk aplikasi dunia nyata. Tim yang berbeda dapat melabeli data secara independen, yakin ID mereka tidak akan bentrok.
Pada Mei 2024, IETF menerbitkan RFC 9562, mempensiunkan RFC 4122 yang lama. Pembaruan itu merespons tuntutan sistem terdistribusi modern, yang membutuhkan ID yang unik dan dapat diurutkan berdasarkan waktu. Tiga versi baru diperkenalkan: v6, v7, dan v8.
Anatomi UUID: Versi dan Varian
Anda biasanya melihat UUID sebagai 32 karakter heksadesimal yang dibagi menjadi lima grup dengan tanda hubung (8-4-4-4-12):
550e8400-e29b-41d4-a716-446655440000
^
version
Dua field utama memberi tahu Anda bagaimana UUID dihasilkan:
| Field | Lokasi | Apa yang Diberitahukan |
|---|---|---|
| Bit versi | 4 bit pertama dari byte ke-7 (karakter pertama grup ke-3) | Algoritma mana yang digunakan (mis. “4” = v4, “7” = v7) |
| Bit varian | byte ke-9 | Varian UUID — RFC 9562 menggunakan pola bit 10 |
Seperti yang dijelaskan SnapUtils, bit varian memisahkan UUID RFC 9562 modern dari format Apollo atau Microsoft yang lebih lama.
Mengapa UUID v7 Adalah Standar Emas Baru untuk Basis Data
Kerugian terbesar UUID v4 adalah bahwa ia sepenuhnya acak. Saat digunakan sebagai kunci utama dalam indeks B-tree, basis data harus menyisipkan baris baru pada posisi yang tidak terduga. Menurut CreateUUID, hal ini menyebabkan “pemisahan halaman” (page splits) — basis data harus terus-menerus menata ulang data untuk membuat ruang, yang mengakibatkan penulisan lebih lambat dan memori terbuang.
UUID v7 mengatasinya dengan menempatkan stempel waktu Unix Epoch 48-bit (presisi milidetik) di awal ID. Ini membuat ID monoton meningkat — yang baru selalu lebih besar dari yang lama. Basis data cukup menambahkannya ke akhir indeks, memberi Anda performa bilangan bulat berurutan dengan keunikan global UUID.
Bagaimana UUID v7 Menyeimbangkan Waktu dan Entropi
UUID v7 mengisi 74 bit sisanya menggunakan CSPRNG (generator angka pseudo-acak yang aman secara kriptografi). Menurut Wikipedia, Anda perlu menghasilkan sekitar 1 miliar UUID per detik selama 85 tahun untuk mencapai probabilitas tabrakan 50 %. Untuk aplikasi nyata apa pun, UUID v7 secara efektif kebal terhadap tabrakan.
Praktik Terbaik Penyimpanan: Binary(16) vs. String(36)
Bagaimana Anda menyimpan UUID sama pentingnya dengan versi mana yang Anda gunakan:
| Format Penyimpanan | Ruang | Performa Indeks | Rekomendasi |
|---|---|---|---|
| Binary(16) | 16 byte | Tinggi (ringkas) | Praktik terbaik |
| Tipe UUID native | 16 byte | Tinggi (dioptimalkan) | Terbaik untuk PostgreSQL |
| String (Char 36) | 36–72 byte | Rendah (terfragmentasi) | Hindari |
SnapUtils merekomendasikan agar selalu menggunakan tipe native daripada string. Di PostgreSQL, tipe native uuid menyimpan data dalam format biner ringkas 16-byte sambil tetap mendukung kueri standar berbasis string.
UUID vs. GUID: Adakah Perbedaan?
GUID (Globally Unique Identifier, pengidentifikasi unik global) adalah implementasi Microsoft dari standar UUID. Secara historis, ada perbedaan dalam urutan byte (endianness) — GUID Microsoft awal menggunakan little-endian untuk tiga field pertama, sedangkan UUID standar menggunakan big-endian (urutan byte jaringan) (SnapUtils).
Pada 2026, ini sebagian besar menjadi konvensi penamaan. Di bawah RFC 9562, keduanya bekerja identik. Guid.NewGuid() di .NET sepenuhnya kompatibel dengan uuid.uuid4() di Python. Anda akan mendengar “GUID” di lingkaran Windows/Azure dan “UUID” di komunitas Linux dan sumber terbuka.
Menerapkan UUID Modern: Per Bahasa
| Bahasa | UUID v4 | UUID v7 |
|---|---|---|
| Python | Modul uuid bawaan |
Paket uuid6 atau uuid7 |
| JavaScript | crypto.randomUUID() |
Paket npm uuid (v10+) |
| PostgreSQL | gen_random_uuid() (PG 13+) |
uuidv7() native (PG 17+) atau ekstensi |
| .NET | Guid.NewGuid() |
Paket komunitas |
| Rust | crate uuid (v1.7+) |
crate uuid dengan fitur v7 |
ID Deterministik: UUID v5
Jika Anda memerlukan ID yang sama setiap kali untuk masukan tertentu (seperti URL atau nama pengguna), gunakan UUID v5. Ia melakukan hash pada UUID ruang nama dan string nama menggunakan SHA-1 — sempurna untuk deduplikasi ketika Anda tidak dapat memeriksa basis data pusat.
Pelajaran Privasi dari UUID v1
UUID v1 menggunakan stempel waktu dan alamat MAC komputer. Ia sebagian besar telah ditinggalkan karena membocorkan informasi perangkat keras. Contoh terkenal: pembuat virus Melissa tertangkap karena UUID dalam dokumen Word yang terinfeksi memuat alamat MAC spesifiknya.
RFC 9562 Lanjutan: v6, v8, dan UUID Khusus
RFC 9562 menambahkan versi khusus untuk kebutuhan sistem terdistribusi tertentu:
| Versi | Tujuan | Kapan Digunakan |
|---|---|---|
| v6 | Stempel waktu v1 yang disusun ulang — dapat diurutkan dengan tetap mempertahankan presisi v1 | Migrasi sistem v1 lama |
| v8 | Kustom — 122 bit untuk data yang ditentukan pengembang | Skema eksperimental atau khusus vendor |
| Nil UUID | 00000000-0000-0000-0000-000000000000 |
Placeholder null |
| Max UUID | FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |
Penanda titik akhir rentang |
Kesimpulan
RFC 9562 telah memperbarui pengidentifikasi unik untuk era cloud modern. Panduan praktis:
- Kunci utama basis data → Gunakan UUID v7 untuk penyisipan terurut waktu dan bebas fragmentasi
- Keacakan umum → UUID v4 masih sepenuhnya baik
- Deduplikasi → UUID v5 memberi Anda ID deterministik
- Penyimpanan → Selalu gunakan Binary(16) atau tipe UUID native, jangan pernah string
Tindakan: Periksa skema basis data Anda. Jika Anda menggunakan UUID v4 sebagai kunci utama dalam tabel dengan jutaan baris, migrasi ke UUID v7 adalah perubahan sederhana yang dapat mengurangi fragmentasi indeks secara signifikan dan mempercepat kueri.
Pertanyaan yang Sering Diajukan
Apakah UUID sama dengan GUID?
Secara fungsional, ya. GUID adalah implementasi Microsoft dari standar UUID. Di bawah RFC 9562, perilakunya identik — Anda dapat menggunakannya secara bergantian antar aplikasi .NET, Java, dan Python.
Bisakah dua UUID pernah bertabrakan dalam skenario dunia nyata?
Secara matematis mungkin, secara praktis mustahil. Untuk UUID v4, Anda perlu menghasilkan sekitar 2,71 kuintiliun ID untuk mencapai probabilitas tabrakan 50 %. Menurut Generate-Random.org, menghasilkan 1 miliar UUID per detik selama 85 tahun hanya memberi Anda peluang 50 % untuk satu tabrakan.
Haruskah saya menyimpan UUID sebagai string atau biner di basis data saya?
Selalu utamakan Binary(16) atau tipe UUID native (tersedia di PostgreSQL). String 36-karakter mengonsumsi lebih dari dua kali lipat ruang dan secara signifikan memperlambat pencarian indeks dan gabungan.SnapUtils mencatat bahwa manfaat performa RFC 9562 dimaksimalkan ketika penyimpanan tetap ringkas.
Kapan saya harus menggunakan UUID v5 alih-alih UUID v4?
Gunakan v5 ketika Anda membutuhkan ID deterministik — masukan yang sama selalu menghasilkan UUID yang sama, tanpa memeriksa basis data. Gunakan v4 ketika Anda membutuhkan keacakan total dan ingin memastikan pengidentifikasi tidak dapat direkayasa balik ke sumbernya.
Tinggalkan Balasan