Ringkas: UUID v4 adalah pilihan default yang aman untuk ID unik acak, ULID lebih baik saat Anda juga ingin ID yang terurut menurut waktu pembuatan, dan NanoID ideal saat butuh ID pendek yang ramah URL. Ketiganya menghindari koordinasi antarsistem, tetapi menyeimbangkan panjang, keterurutan, dan perilaku indeks secara berbeda. Panduan ini menjelaskan apa masing-masing dan kapan memakainya.

Pengidentifikasi unik memungkinkan sistem-sistem independen membuat catatan tanpa bertanya ke server pusat «berapa nomor berikutnya?». Kemandirian itulah intinya: dua layanan, atau dua perangkat luring, masing-masing dapat membuat ID dengan yakin nilainya tak akan bertabrakan.

Apa sebenarnya UUID itu

UUID adalah nilai 128 bit, biasa ditulis sebagai 36 karakter — 32 digit heksadesimal ditambah empat tanda hubung, seperti 550e8400-e29b-41d4-a716-446655440000. Versi yang hampir selalu Anda inginkan adalah UUID v4, yang mengisi 122 bit di antaranya dengan keacakan. Ini menghasilkan sekitar 5,3 × 10³⁶ nilai mungkin, jadi tabrakan bukan hal yang perlu diantisipasi: Anda harus menghasilkan sekitar satu triliun miliar UUID sebelum peluang tabrakan mencapai 50%.

«Dapat diabaikan» bukan «mustahil», tetapi dalam praktik v4 memberi keunikan tanpa koordinasi pusat apa pun.

UUID v4 versus v1

UUID v1 dibangun dari stempel waktu ditambah alamat jaringan (MAC) mesin pembuat. Itu membuat v1 kira-kira terurut menurut waktu, tetapi bisa membocorkan di mana dan kapan sebuah ID dibuat — kadang masalah privasi. UUID v4 meninggalkan semua itu demi keacakan murni: tanpa urutan, tanpa metadata tertanam, tak ada yang bocor. Untuk kebanyakan aplikasi v4 adalah default yang tepat, dan v1 hanya sepadan bila Anda memang menginginkan komponen waktunya.

ULID: terurut secara desain

Sebuah ULID juga 128 bit, tetapi dikodekan sebagai 26 karakter Crockford base32 alih-alih heksadesimal bertanda hubung. 48 bit pertamanya adalah stempel waktu milidetik dan 80 sisanya acak. Karena stempel waktu memimpin, ULID terurut secara leksikografis sesuai urutan pembuatannya: urutkan stringnya dan Anda mendapat urutan kronologis secara gratis. Properti yang benar-benar berguna: membuat kueri «terbaru dulu» murah dan menjaga penyisipan basis data tetap terurut, bukan tersebar.

NanoID: pendek dan ramah URL

Sebuah NanoID secara default memakai 21 karakter dari alfabet URL-safe, sehingga masuk ke tautan tanpa percent-encoding. Panjangnya dapat dikonfigurasi, memungkinkan Anda menyeimbangkan ukuran dan ketahanan tabrakan: ID lebih pendek lebih rapi tetapi menyisakan lebih sedikit keacakan, jadi buat lebih panjang untuk pengidentifikasi publik atau bervolume tinggi. NanoID unggul untuk tautan berbagi, ID publik singkat, dan di mana UUID 36 karakter tampak janggal dalam URL.

Mana untuk kunci basis data?

Di sini pilihan berdampak nyata pada kinerja. UUID v4 sepenuhnya sah sebagai kunci utama, tetapi keacakannya membuat baris baru tersisip di posisi acak pada indeks B-tree, menimbulkan fragmentasi dan lebih banyak pemisahan halaman seiring tabel membesar. Pengidentifikasi terurut waktu — ULID, atau UUID v7 yang lebih baru — tersisip dalam urutan kira-kira menaik, yang menjaga indeks ringkas dan penulisan lokal. Jika memilih kunci untuk tabel besar dengan banyak tulis, utamakan ID terurut waktu; untuk tabel kecil perbedaannya jarang penting.

Kesalahan umum yang harus dihindari

  • Mengekspos ID bilangan bulat berurutan secara publik padahal Anda ingin ID yang tak bisa ditebak — itu tugas ID acak, bukan auto-increment.
  • Memakai UUID v4 acak sebagai kunci berkluster tabel raksasa lalu heran mengapa penyisipan melambat.
  • Memotong UUID untuk «menghemat ruang» — Anda membuang keacakan yang menjamin keunikan.
  • Memendekkan NanoID terlalu agresif untuk pengidentifikasi bervolume tinggi dan menaikkan risiko tabrakan.

Sesuaikan ID dengan tugasnya: gunakan Pembuat UUID untuk membuat nilai v4, v1, ULID, atau NanoID, pilih v4 untuk keunikan umum, ULID saat urutan penting, dan NanoID saat ID harus hidup di dalam URL.