Generator UUID

• UUID v1 menggabungkan timestamp dengan alamat MAC mesin — dijamin unik tetapi menampilkan waktu pembuatan dan identitas perangkat keras, sehingga menimbulkan kekhawatiran privasi.
• UUID v3 dan v5 adalah hash deterministik: v3 menggunakan MD5, v5 menggunakan SHA-1. Jika diberikan namespace dan nama yang sama, keduanya selalu menghasilkan UUID yang sama — berguna untuk menghasilkan pengidentifikasi yang konsisten dari kunci alami (misalnya, mengubah alamat email menjadi ID pengguna).
• UUID v4 menggunakan 122 bit data acak, memberikan jaminan keunikan terkuat tanpa membocorkan informasi apa pun.
• UUID v7 (RFC 9562, 2024) menyematkan timestamp Unix dalam 48 bit pertama sambil mempertahankan 74 bit acak — dapat diurutkan berdasarkan waktu pembuatan, menjadikannya ideal untuk primary key basis data di mana performa indeks sangat penting.

Untuk sebagian besar aplikasi, v4 adalah pilihan bawaan utama; beralihlah ke v7 untuk primary key basis data di mana urutan penyisipan data (insertion order) berpengaruh.

UUID v4 menggunakan 122 bit acak, menghasilkan 5,3 × 10^36 kemungkinan nilai. Masalah paradoks ulang tahun (birthday problem) menentukan peluang tabrakan data: setelah menghasilkan 2,7 × 10^18 (2,7 kuintiliun) UUID, terdapat peluang 50% terjadinya satu tabrakan.

Dalam penerapan praktis, menghasilkan 1 miliar UUID per detik selama 85 tahun baru akan mencapai ambang batas ini. Pada skala yang lebih realistis — sistem yang menghasilkan 1 juta UUID per hari — peluang terjadinya tabrakan dalam 100 tahun adalah sekitar 1 banding 10^24.

Perhitungan ini mengasumsikan generator angka acak yang andal (CSPRNG); penggunaan Math.random() di JavaScript (yang tidak aman secara kriptografis) mengurangi entropi dan meningkatkan risiko tabrakan. Selalu gunakan crypto.randomUUID(), pustaka uuid v4, atau fungsi bawaan basis data untuk sistem produksi.

UUID sebagai primary key memungkinkan pembuatan ID terdesentralisasi (aplikasi membuat ID tanpa perlu bolak-balik ke basis data) dan mencegah serangan enumerasi (pengguna tidak dapat menebak ID entri lainnya).

Namun, nilai UUID v4 yang acak dapat membebani performa indeks B-tree — penyisipan data acak menyebabkan pemecahan halaman (page splits) dan fragmentasi, meningkatkan write amplification hingga 2-5x dibandingkan kunci integer sekuensial. UUID v7 mengatasi hal ini dengan keacakan yang berawalan timestamp, memberikan keunikan sekaligus pengurutan sekuensial.

Biaya penyimpanan juga lebih tinggi: 16 byte dibandingkan 4-8 byte untuk integer, hal ini signifikan pada tabel dengan miliaran baris dan banyak indeks.

Pola yang umum digunakan adalah menggabungkan UUID sebagai pengidentifikasi publik dengan kunci auto-increment integer untuk kebutuhan internal, menghubungkan tabel (join) menggunakan integer yang efisien sambil hanya mengekspos UUID yang aman ke API dan URL.

UUID (Universally Unique Identifier) adalah nilai 128-bit yang dirancang agar unik di berbagai ruang dan waktu tanpa memerlukan otoritas pendaftaran pusat, sebagaimana didefinisikan oleh IETF RFC 9562 (yang menggantikan RFC 4122 sebelumnya).

128 bit tersebut ditulis sebagai 32 karakter heksadesimal yang dikelompokkan dalam pola 8-4-4-4-12, seperti 550e8400-e29b-41d4-a716-446655440000. Bit tertentu telah dicadangkan: digit heksadesimal ke-13 menyandikan versi, dan bit teratas dari digit heksadesimal ke-17 menyandikan varian.

Bit sisanya membawa data acak, timestamp, atau nama yang di-hash tergantung versinya. Karena ruang alamat yang tersedia mencapai 2^122, sistem generator independen dapat mencetak pengidentifikasi dengan aman tanpa perlu saling berkoordinasi.

Cara tersederhana untuk membuat UUID adalah menggunakan fungsi bawaan bahasa pemrograman yang memanggil sumber acak aman secara kriptografis.

• Di JavaScript, crypto.randomUUID() mengembalikan UUID v4 dan didokumentasikan di MDN Web Docs sebagai bagian dari Web Crypto API, tersedia di peramban modern dan Node.js 14.17+.
• Di Python, modul uuid perpustakaan standar menyediakan uuid.uuid4() untuk nilai acak dan uuid.uuid1() untuk nilai berbasis stempel waktu.
• Di PostgreSQL, gen_random_uuid() menghasilkan UUID v4, sedangkan MySQL 8 menyediakan UUID() untuk nilai bergaya v1.

Semua fungsi ini menghasilkan string yang patuh pada RFC 9562, sehingga ID yang dibuat di satu bahasa dapat berinteroperasi dengan lancar di bahasa lain.

Ya, GUID dan UUID adalah pengenal 128-bit yang sama; GUID (Globally Unique Identifier) hanyalah terminologi Microsoft untuk UUID standar yang ditentukan oleh IETF RFC 9562. Keduanya kompatibel secara biner, sehingga nilai yang dibuat oleh Windows atau .NET dapat digunakan oleh sistem apa pun yang patuh pada RFC dan sebaliknya.

Satu-satunya perbedaan rutin terletak pada penyajiannya: perkakas Microsoft sering kali membungkus nilai tersebut dalam kurung kurawal, misalnya {550e8400-e29b-41d4-a716-446655440000}, dan beberapa COM API secara historis menggunakan huruf kapital untuk hex.

Catatan kecil yang perlu diperhatikan adalah urutan byte — GUID biner Microsoft menyimpan tiga bidang pertama dalam format little-endian, yang hanya penting saat menguraikan byte mentah, bukan bentuk string standar ber-tanda hubung.

UUID bukanlah sebuah rahasia dan tidak boleh diperlakukan sebagai rahasia, bahkan ketika bit acaknya berasal dari generator yang aman secara kriptografis. RFC 9562 secara tegas memperingatkan bahwa UUID tidak menawarkan keamanan bawaan dan tidak boleh dianggap sulit ditebak; OWASP juga memperingatkan agar tidak menggunakan pengenal sebagai token otorisasi.

Versi 4 mengambil 122 bit dari CSPRNG, sehingga tidak praktis untuk diprediksi, tetapi versi 1 dan versi 7 menyematkan stempel waktu yang membocorkan waktu pembuatan, serta versi 3 dan versi 5 adalah hash deterministik dari ruang nama dan nama yang diketahui.

Untuk token sesi, penyetelan ulang kata sandi, atau kunci API, buatlah rahasia berentropi tinggi khusus daripada mengandalkan struktur UUID untuk perlindungan.

Bidang versi dan varian adalah pola bit tetap yang disematkan dalam setiap UUID RFC 9562 yang memberi tahu pengurai cara nilai tersebut dibuat.

Versi menempati empat bit paling signifikan dari byte ketujuh (digit hex ke-13), sehingga UUID v4 selalu menampilkan angka 4 di sana dan v7 selalu menampilkan angka 7. Varian berada di dua atau tiga bit paling signifikan dari byte kesembilan (digit hex ke-17), yang untuk varian IETF standar menjadikan digit tersebut salah satu dari 8, 9, a, atau b.

Inilah sebabnya mengapa UUID v4 yang valid cocok dengan pola xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Memeriksa posisi tetap ini adalah cara yang benar untuk memvalidasi atau mengklasifikasikan UUID daripada pemeriksaan panjang yang tidak ketat.

Pembuatan UUID secara massal sangat berguna untuk seeding basis data, membuat fixture pengujian, load-testing, dan mengisi API tiruan (mock API), dan alat ini dapat menghasilkan banyak pengenal valid hanya dengan satu klik. Karena setiap UUID dibuat secara independen dari sumber acak atau stempel waktu sesuai RFC 9562, pembuatan batch tidak memiliki risiko tabrakan yang berarti bahkan dalam jumlah besar.

Untuk data pengujian yang dapat diulang, lebih disukai UUID versi 5 deterministik yang diturunkan dari ruang nama dan nama tetap sehingga input yang sama selalu menghasilkan pengenal yang sama di setiap pengujian.

Saat melakukan seeding pada tabel berskala produksi, pertimbangkan versi 7 agar baris yang dimasukkan secara massal berada dalam urutan indeks yang cukup berurutan, sehingga menjaga halaman B-tree tetap ringkas dan mengurangi amplifikasi penulisan selama impor.

Simpan UUID dalam tipe biner 16-byte bawaan kapan pun basis data Anda mendukungnya, karena menyimpannya sebagai teks 36-karakter membuang lebih dari dua kali lipat ruang dan memperlambat perbandingan indeks. PostgreSQL menyediakan tipe kolom uuid khusus, sedangkan MySQL dan SQL Server biasanya menggunakan BINARY(16) dengan fungsi konversi ke dan dari string ber-tanda hubung.

Seperti yang dicatat RFC 9562, UUID tidak sensitif huruf besar/kecil (case-insensitive) dan harus dinormalisasi — biasanya menjadi huruf kecil — sebelum disimpan agar pencarian tetap konsisten.

Jika Anda menggunakan UUID sebagai kunci utama (primary key), lebih disukai versi 7 untuk mempertahankan lokalitas penyisipan; jika Anda harus menggunakan versi 4, beberapa mesin memungkinkan Anda mengatur ulang byte stempel waktu, meskipun versi 7 adalah solusi berbasis standar untuk masalah fragmentasi yang sama.

Kesalahan UUID yang paling umum adalah menggunakan sumber acak non-kriptografis seperti Math.random() milik JavaScript, yang bukan merupakan CSPRNG dan dapat menghasilkan nilai yang terbias atau dapat diprediksi; MDN merekomendasikan crypto.randomUUID() atau Web Crypto API sebagai gantinya.

Kesalahan umum lainnya meliputi:

• memperlakukan nil UUID (semua nol) sebagai pengenal nyata
• menganggap UUID cukup rahasia untuk mengotorisasi akses
• menyimpannya sebagai teks ketika kolom biner 16-byte akan jauh lebih efisien

Pengembang juga sering mencampur versi secara tidak konsisten, atau mengandalkan versi 1 dalam konteks yang sensitif terhadap privasi di mana stempel waktu tersirat dan alamat MAC historisnya membocorkan informasi. Terakhir, membandingkan UUID secara sensitif huruf besar/kecil menyebabkan ketidakcocokan palsu, karena RFC 9562 menetapkannya sebagai tidak sensitif huruf besar/kecil.