Generator UUID

Isi dari 128 bit itu

UUID terdiri dari enam belas byte, ditulis sebagai 32 digit heksadesimal dalam pengelompokan 8-4-4-4-12 yang sudah dikenal. Tidak semuanya bebas: empat bit menandai versi, dan dua atau tiga bit lagi menandai varian, itulah sebabnya digit ketiga belas setiap UUID di sini adalah 4 atau 7, dan digit ketujuh belas selalu salah satu dari 8, 9, a, atau b.

Sisanya 122 bit yang diisi acak oleh UUID versi 4. Versi 7 memakai 48 bit pertamanya untuk timestamp milidetik dan mengisi 74 bit sisanya secara acak, menukar sebagian ketidakterdugaan dengan keterurutan.

Tanda hubung tidak membawa informasi, begitu pula huruf besar-kecil, meskipun RFC 9562 menyatakan output sebaiknya huruf kecil dan input boleh keduanya. Prefiks urn:uuid: dan kurung kurawal yang disukai tool Windows hanyalah tampilan, bukan isi.

Mengapa v7 ada

UUID versi 4 acak secara merata, persis yang Anda inginkan untuk identifier yang tidak boleh mengungkap apa pun, dan persis yang tidak Anda inginkan untuk primary key.

Indeks B-tree menyimpan entrinya dalam urutan yang tersortir. Masukkan kunci acak dan kunci itu bisa jatuh di mana saja dalam urutan tersebut, sehingga setiap insert menyentuh halaman yang berbeda, dan begitu kumpulan halaman yang aktif melebihi memori, setiap insert juga memerlukan pembacaan selain penulisan. Halaman terisi tidak merata dan terpecah, indeks tumbuh lebih besar dari data yang diindeksnya, dan throughput penulisan menurun seiring tabel membesar. Dengan kunci berurutan, insert selalu masuk di akhir, hanya satu halaman yang sibuk, dan semua masalah itu tidak terjadi.

Versi 7 menaruh timestamp di bit-bit tinggi sehingga ID yang dibuat belakangan terurut setelah ID yang dibuat lebih dulu, memulihkan lokalitas itu sambil tetap unik secara global dan tanpa perlu koordinasi antarmesin. Itulah alasan RFC 9562 menambahkannya, dan kini v7 adalah pilihan bawaan yang tepat untuk kolom kunci.

Konsekuensinya nyata: UUID v7 mengungkap kira-kira kapan baris dibuat, dan ID yang berurutan mengungkap urutan serta perkiraan laju pembuatan. Jika identifier ditampilkan ke publik dan salah satu informasi itu sensitif, v4 tetap pilihan yang tepat.

Collision

Dua UUID versi 4 bertabrakan ketika 122 bit acaknya sama persis. Cara umum agar angka ini mudah dipahami adalah batas paradoks ulang tahun: Anda harus membuat sekitar satu miliar UUID per detik selama kira-kira 85 tahun sebelum peluang terjadinya satu collision di seluruh kumpulan mencapai 50%.

Jadi dalam praktiknya, tidak. Kegagalan yang realistis bukan soal statistik. Penyebabnya adalah generator dengan seed yang buruk - mesin virtual yang dikloning dari snapshot yang sama, perangkat embedded tanpa entropi saat boot - atau kode yang memotong UUID agar muat di kolom sehingga sebagian besar keacakannya hilang, atau pustaka yang diam-diam beralih ke sumber acak non-kriptografis. Bit di sini berasal dari generator kriptografis browser, dan kebiasaan yang berguna di tempat lain adalah memeriksa apa yang benar-benar dipakai pustaka Anda, bukan berasumsi.

Cara menyimpannya

Bentuk teksnya 36 karakter. Nilainya 16 byte. Menyimpan UUID sebagai char(36) membuat ruang yang dipakai lebih dari dua kali lipat, dan di database yang setiap indeks sekundernya membawa salinan primary key, biaya itu berlipat di seluruh skema.

PostgreSQL punya tipe uuid bawaan yang menyimpan 16 byte dan menerima bentuk teks sebagai input. MySQL tidak punya tipe seperti itu; pendekatan yang lazim adalah binary(16) dengan konversi di batas aplikasi, dan untuk UUID versi 1 ada trik terkenal menata ulang byte waktu agar bisa diurutkan, sesuatu yang tidak lagi diperlukan dengan versi 7.

Jika Anda menampilkan UUID di URL dan panjangnya mengganggu, encode 16 byte yang sama dengan base32 atau base64url alih-alih memendekkan nilainya. Pemotongan tampak berhasil sampai tiba-tiba tidak lagi.

Semua versi yang ada

Versi 1 menyimpan timestamp 60 bit dan alamat MAC mesin, sehingga identifikasinya bisa diurutkan sekaligus dilacak - sifat yang kedua inilah yang membuatnya ditinggalkan, karena ia membocorkan mesin mana yang membuat identifier tersebut. Versi 2 adalah varian keamanan DCE yang nyaris tidak dipakai siapa pun. Versi 3 dan versi 5 bersifat deterministik: keduanya melakukan hash terhadap sebuah namespace dan sebuah nama, masing-masing dengan MD5 dan SHA-1, sehingga masukan yang sama selalu menghasilkan identifier yang sama.

Versi 4 murni acak dan menjadi pilihan bawaan di mana-mana karena tidak memerlukan koordinasi, jam, maupun identitas mesin. Versi 6 adalah versi 1 yang disusun ulang agar timestamp-nya terurut dengan benar, sedangkan versi 7 adalah jawaban modernnya: timestamp milidetik di bit-bit tinggi lalu diikuti bagian acak, dan dibakukan dalam RFC 9562 pada tahun 2024.

Versi 5 sebenarnya pantas lebih sering dipakai. Ketika Anda memerlukan identifier yang stabil dan diturunkan dari sesuatu yang sudah Anda miliki - sebuah URL, sebuah path berkas, sebuah nama tenant - meng-hash-nya menjadi UUID membuat setiap sistem memperoleh identifier yang sama tanpa tabel rujukan dan tanpa langkah koordinasi apa pun.

Pilihan lain dan kapan lebih cocok dipakai

ULID mengemas timestamp dan bagian acak ke dalam 26 karakter Crockford base32: bisa diurutkan, tidak membedakan huruf besar-kecil, dan dalam bentuk teks lebih pendek daripada UUID. Ia muncul lebih dulu daripada versi 7 dan menyelesaikan masalah yang sama, jadi sistem baru biasanya cukup memakai v7 saja dan tetap berada di dalam standar.

Identifier Snowflake, yang awalnya dari Twitter, mengemas timestamp, id mesin, dan nomor urut ke dalam 64 bit. Bentuknya ringkas, bisa diurutkan, dan nyaris tidak butuh koordinasi, dengan konsekuensi setiap node harus punya id yang berbeda. Nilainya juga melampaui apa yang bisa diwakili number JavaScript secara persis, itulah sebabnya API yang memakainya mengembalikannya sebagai string.

nanoid menghasilkan string acak pendek untuk URL, dengan alfabet yang bisa diatur - panjang bawaannya 21 karakter dan membawa entropi kira-kira setara UUID v4 dengan teks setengahnya saja. Dan bilangan bulat yang bertambah otomatis pun masih merupakan pilihan terbaik di banyak sistem: paling kecil, paling cepat diindeks, dan sepenuhnya memadai selama identifier-nya hanya dipakai secara internal.

Apa yang terbuka ketika identifier dipublikasikan

Bilangan bulat berurutan di URL publik memberi tahu semua orang berapa volume Anda dan memungkinkan siapa pun menyusuri rentangnya: /orders/1001 menyiratkan /orders/1000 juga ada. Digabung dengan pemeriksaan otorisasi yang terlewat, itulah kelas kerentanan yang dikenal sebagai insecure direct object reference, yang sampai sekarang masih menjadi salah satu celah yang paling sering ditemukan di aplikasi web.

UUID v4 yang acak menghilangkan kemungkinan penyusuran, dan hanya itu. Ia bukan kontrol akses: identifier yang tidak bisa ditebak siapa pun tetaplah identifier yang bisa dipakai oleh siapa saja yang berhasil memperolehnya, sementara URL bocor lewat header referrer, riwayat peramban, log, tangkapan layar, dan tautan yang dibagikan. Setiap permintaan tetap harus memeriksa apakah pengguna ini memang boleh melihat sumber daya ini.

Versi 7 menyerahkan kembali sedikit dari ketertutupan itu. Ia menyingkap kira-kira kapan sebuah catatan dibuat, dan identifier yang berurutan memperlihatkan urutan serta laju pembuatannya - cukup untuk menyimpulkan berapa banyak pelanggan yang mendaftar dalam sepekan. Jika salah satu dari hal itu bersifat sensitif pada identifier publik, gunakan v7 secara internal sebagai primary key dan tampilkan v4 atau slug terpisah ke luar.

Primary key, indeks, dan penyimpanan

Indeks B-tree menjaga entri tetap terurut, sehingga kunci acak menyebarkan operasi insert ke seluruh indeks. Begitu indeksnya tidak lagi muat di memori, setiap insert berubah menjadi operasi baca sekaligus tulis, halaman terisi tidak merata lalu terbelah, dan throughput tulis menurun seiring tabel membesar. Kunci berurutan hanya menambah di bagian akhir, membuat satu halaman saja tetap panas, dan menghindari semua itu - dan inilah seluruh alasan memakai versi 7.

Cara penyimpanan juga penting. Sebuah UUID berukuran 16 byte; bentuk teksnya 36 karakter. PostgreSQL punya tipe uuid bawaan yang menyimpan bentuk binernya dan menerima teks sebagai masukan. MySQL tidak punya tipe semacam itu, sehingga kebiasaannya adalah memakai BINARY(16) dengan konversi di batas aplikasi. Menyimpannya sebagai teks membuat kebutuhan ruang lebih dari dua kali lipat, dan pada mesin basis data yang setiap indeks sekundernya ikut membawa salinan primary key, biaya itu berlipat ganda ke seluruh skema.

Jalan tengah yang umum dipakai adalah primary key berupa bilangan bulat kecil untuk join internal, ditambah UUID sebagai identifier eksternal dengan indeks unik. Tata letak fisiknya tetap padat, sementara dunia luar tetap mendapat pegangan yang tidak menyingkap apa pun.

Membuatnya dengan aman di dalam kode

Pakailah fungsi bawaan platform, jangan merakitnya sendiri: crypto.randomUUID di peramban dan Node, uuid4 di Python, UUID.randomUUID di Java. Fungsi-fungsi ini mengambil nilai dari generator kriptografis, dan itulah yang membuat argumen soal peluang tabrakan tetap sahih. Pustaka yang jatuh kembali ke Math.random - beberapa paket JavaScript lama memang begitu - menghasilkan identifier yang tampak sama persis padahal bisa ditebak.

Kegagalan yang benar-benar terjadi di lapangan bukanlah soal statistik. Mesin virtual yang dikloning dari snapshot yang sama bisa menyala dengan kolam entropi yang identik; perangkat embedded kadang nyaris tidak punya entropi saat baru menyala; dan kode yang memangkas UUID agar muat di sebuah kolom akan menghancurkan sebagian besar keacakannya sambil menyisakan sesuatu yang tetap terlihat seperti identifier.

Dua kebiasaan bisa menghindari sisanya. Bandingkan identifier tanpa membedakan huruf besar-kecil, karena RFC 9562 menyebutkan agar keluarannya huruf kecil tetapi keduanya harus diterima, dan buang kurung kurawal serta awalan urn:uuid: yang ditambahkan perkakas Windows. Lalu lakukan validasi pada masukan alih-alih memercayai bentuknya, sebab string yang mirip UUID di dalam sebuah URL tetaplah masukan dari pengguna.