Pengidentifikasi Unik Universal (UUID) adalah bentuk pengenal tertentu yang dapat dengan aman dianggap unik untuk sebagian besar tujuan praktis. Dua UUID yang dibuat secara sah memiliki peluang identik yang hampir dapat diabaikan, meskipun keduanya dibuat di dua lingkungan yang berbeda oleh pihak yang berbeda. Inilah sebabnya mengapa UUID dikatakan semua seutuhnya aneh
Dalam artikel ini, kita akan melihat properti UUID, cara kerja keunikannya, dan situasi di mana mereka dapat menyederhanakan identifikasi sumber daya. Meskipun kami akan mendekati UUID dari perspektif perangkat lunak tipikal yang berinteraksi dengan catatan basis data, ini berlaku secara luas untuk setiap kasus penggunaan di mana pembuatan ID unik yang terdesentralisasi diperlukan.
Apa sebenarnya UUID itu?
UUID hanyalah nilai yang dapat Anda anggap unik dengan aman. Risiko tabrakan sangat rendah sehingga Anda dapat memilih untuk mengabaikannya sepenuhnya. Anda mungkin melihat UUID yang dirujuk menggunakan istilah yang berbeda (GUID, atau Pengidentifikasi Unik Global, adalah semantik pilihan Microsoft) tetapi arti dan efeknya tetap sama.
UUID asli adalah pengidentifikasi unik yang dihasilkan dan diwakili oleh format standar. UUID yang valid ditentukan oleh RFC 4122; spesifikasi ini menjelaskan algoritme yang dapat digunakan untuk menghasilkan UUID yang mempertahankan keunikan di seluruh implementasi, tanpa otoritas penerbit pusat.
RFC mencakup lima algoritma berbeda yang masing-masing menggunakan mekanisme berbeda untuk menghasilkan nilai. Berikut adalah ringkasan singkat dari “versi” yang tersedia:
- Versi 1 – Berbasis Waktu – Menggabungkan stempel waktu, urutan jam, dan nilai khusus untuk perangkat pembangkit (biasanya alamat MAC-nya) untuk menghasilkan keluaran yang unik untuk host tersebut pada waktu itu.
- Versi 2 – Keamanan DCE – Versi ini dikembangkan sebagai evolusi dari Versi 1 untuk digunakan di Lingkungan Komputasi Terdistribusi (DCE). Ini tidak digunakan secara luas.
- Versi 3 – Berdasarkan Nama (MD5) – MD5 hash “namespace” dan “name” untuk membuat nilai unik untuk nama itu di dalam namespace. Membuat UUID lain dengan namespace dan nama yang sama akan menghasilkan output yang identik sehingga metode ini memberikan hasil yang dapat direproduksi.
- Versi 4 – Acak – Sebagian besar sistem modern cenderung memilih UUID v4 karena menggunakan sumber host nomor acak atau pseudo-acak untuk mendapatkan nilainya. Peluang UUID yang sama dibuat dua kali hampir dapat diabaikan.
- Versi 5 – Berdasarkan Nama (SHA-1) – Ini mirip dengan Versi 3 tetapi menggunakan algoritma SHA-1 yang lebih kuat untuk meng-hash namespace dan nama input.
Meskipun RFC mengacu pada algoritme sebagai versi, itu tidak berarti Anda harus selalu menggunakan Versi 5 karena tampaknya yang terbaru. Pilihannya tergantung pada kasus penggunaan Anda; dalam banyak kasus v4 dipilih karena sifatnya yang acak. Ini menjadikannya kandidat ideal untuk skenario sederhana “beri saya identitas baru”.
Algoritme pembangkitan menghasilkan bilangan bulat tidak bertanda 128-bit. Namun, UUID lebih sering dilihat sebagai string heksadesimal dan juga dapat disimpan sebagai urutan biner dari 16 karakter. Berikut adalah contoh string UUID:
16763be4-6022-406e-a950-fcd5018633ca
Nilai direpresentasikan sebagai lima kelompok karakter alfanumerik yang dipisahkan oleh karakter tanda hubung. Tanda hubung bukan merupakan bagian wajib dari string; kehadiran mereka sesuai dengan detail sejarah dari spesifikasi UUID. Mereka juga membuat identifikasi lebih mudah dilihat oleh mata manusia.
Kasus Penggunaan UUID
Kasus penggunaan utama untuk UUID adalah pembuatan pengidentifikasi unik yang terdesentralisasi. Anda dapat membuat UUID di mana saja dan dengan aman menganggapnya unik, baik itu berasal dari kode backend, perangkat klien, atau mesin basis data Anda.
UUID menyederhanakan pengidentifikasian dan pemeliharaan identitas objek di lingkungan yang tidak terhubung. Secara historis, sebagian besar aplikasi menggunakan bidang bilangan bulat yang bertambah otomatis sebagai kunci utama. Saat Anda membuat objek baru, Anda tidak tahu ID-nya sampai setelah sudah masuk ke database. UUID memungkinkan Anda menentukan identitas lebih awal di aplikasi Anda.
Berikut demo PHP dasar yang menunjukkan perbedaannya. Mari kita lihat sistem berbasis integer terlebih dahulu:
class BlogPost { public function __construct( public readonly ?int $Id, public readonly string $Headline, public readonly ?AuthorCollection $Authors=null) {} } #[POST("/posts")] function createBlogPost(HttpRequest $Request) : void { $headline = $Request -> getField("Headline"); $blogPost = new BlogPost(null, $headline); }
Kita harus memulai $Id properti dengan null karena kita tidak akan tahu itu ID yang sebenarnya sampai setelah itu tetap di database. Itu tidak sempurna – $Id seharusnya tidak benar-benar dapat dibatalkan dan itu memungkinkannya BlogPost peluang untuk eksis dalam keadaan tidak lengkap.
Mengubah UUID mengatasi masalah:
class BlogPost { public function __construct( public readonly string $Uuid, public readonly string $Headline, public readonly ?AuthorCollection $Authors=null) {} } #[POST("/posts")] function createBlogPost(HttpRequest $Request) : void { $headline = $Request -> getField("Headline"); $blogPost = new BlogPost("16763be4-...", $headline); }
Pengidentifikasi posting sekarang dapat dihasilkan dalam aplikasi tanpa mempertaruhkan nilai duplikat. Ini memastikan bahwa objek instan selalu mewakili status yang valid dan tidak memerlukan properti ID nullable yang kikuk. Model ini juga membuat logika transaksional lebih mudah ditangani; catatan anak yang memerlukan referensi ke orang tua mereka (seperti posting kami Author asosiasi) dapat dimasukkan segera, tanpa database bolak-balik untuk mengambil ID yang ditetapkan ke induk.
Di masa mendatang, aplikasi blog Anda dapat memindahkan lebih banyak logika ke klien. Mungkin frontend mendapat dukungan untuk penyusunan offline penuh, membuat secara efektif BlogPost instance yang sementara tetap ada di perangkat pengguna. Sekarang klien dapat membuat UUID kiriman dan mengirimkannya ke server ketika konektivitas jaringan dipulihkan. Jika klien kemudian mengambil salinan draf server, salinan tersebut dapat dicocokkan dengan status lokal lainnya karena UUID akan diketahui.
UUID juga membantu Anda menggabungkan data dari berbagai sumber. Menggabungkan tabel database dan cache yang menggunakan kunci integer bisa menjadi membosankan dan rawan kesalahan. UUID menawarkan keunikan tidak hanya di dalam tabel tetapi di tingkat seluruh alam semesta. Ini menjadikannya kandidat yang lebih baik untuk struktur dan data yang direplikasi yang sering dipindahkan di antara sistem penyimpanan yang berbeda.
Catatan Saat UUID Memenuhi Basis Data
Manfaat UUID cukup menarik. Namun, ada beberapa gotcha yang harus diperhatikan saat menggunakannya di sistem nyata. Faktor besar yang mendukung ID bilangan bulat adalah mudah untuk diskalakan dan dioptimalkan. Mesin basis data dapat dengan mudah mengindeks, mengurutkan, dan memfilter daftar angka yang hanya mengarah ke satu arah.
Hal yang sama tidak dapat dikatakan untuk UUID. Untuk memulainya, UUID empat kali lebih besar dari bilangan bulat (36 byte vs 4 byte); untuk kumpulan data besar, ini bisa menjadi pertimbangan yang signifikan. Nilai juga lebih sulit untuk diurutkan dan diindeks, terutama dalam kasus UUID acak yang paling umum. Sifat acak mereka berarti mereka tidak memiliki tatanan alam. Ini akan merusak kinerja pengindeksan jika Anda menggunakan UUID sebagai kunci utama.
Masalah-masalah ini dapat mencakup database yang dinormalisasi dengan baik yang banyak menggunakan kunci asing. Sekarang Anda dapat memiliki beberapa tabel relasional, masing-masing berisi referensi ke UUID 36-byte Anda. Akhirnya, memori ekstra yang diperlukan untuk melakukan penggabungan dan pengurutan dapat berdampak signifikan pada kinerja sistem Anda.
Anda dapat sedikit mengurangi masalah dengan menyimpan UUID Anda sebagai data biner. Itu berarti BINARY(16) kolom bukannya VARCHAR(36). Beberapa database seperti PostgreSQL datang dengan built-in UUID tipe data; yang lain seperti MySQL memiliki fungsi yang dapat mengubah string UUID menjadi representasi binernya, dan sebaliknya. Pendekatan ini lebih efisien tetapi perhatikan bahwa Anda masih akan menggunakan sumber daya tambahan untuk menyimpan dan memilih data Anda.
Pendekatan yang efektif mungkin untuk menjaga bilangan bulat sebagai kunci utama Anda tetapi menambahkan bidang UUID tambahan untuk referensi aplikasi Anda. Tabel tautan relasional dapat menggunakan ID untuk meningkatkan kinerja saat kode Anda mengambil dan menempatkan objek tingkat atas dengan UUID. Itu semua tergantung pada sistem Anda, ukurannya, dan prioritas Anda: ketika Anda membutuhkan pembuatan ID terdesentralisasi dan integrasi data langsung, UUID adalah pilihan terbaik tetapi Anda perlu mengenali trade off.
Ringkasan
UUID adalah nilai unik yang dapat Anda gunakan dengan aman untuk pembuatan identitas terdesentralisasi. Tabrakan adalah mungkin tetapi harus sangat jarang sehingga dapat diabaikan. Jika Anda menghasilkan satu miliar UUID per detik selama satu abad penuh, kemungkinan menemukan duplikat akan menjadi sekitar 50% dengan asumsi entropi yang cukup.
Anda dapat menggunakan UUID untuk menetapkan identitas secara independen dari database Anda, sebelum penyisipan terjadi. Ini menyederhanakan kode tingkat aplikasi dan mencegah objek yang didefinisikan secara tidak benar dari yang ada di sistem Anda. UUID juga membantu replikasi data dengan menjamin keunikan terlepas dari penyimpanan data, perangkat, atau lingkungan, tidak seperti kunci integer tradisional yang beroperasi pada tingkat tabel.
Sementara UUID ada di mana-mana dalam pengembangan perangkat lunak, mereka bukan solusi yang sempurna. Pendatang baru cenderung menyesuaikan diri dengan kemungkinan tabrakan tetapi ini tidak boleh menjadi pertimbangan utama Anda, kecuali sistem Anda sangat sensitif sehingga keunikan harus dijamin.
Tantangan yang lebih jelas bagi sebagian besar pengembang adalah seputar penyimpanan dan pengambilan UUID yang dihasilkan. Naif menggunakan VARCHAR(36) (atau hilangkan tanda hubung dan gunakan VARCHAR(32)) dapat merusak aplikasi Anda dari waktu ke waktu karena sebagian besar pengoptimalan pengindeksan basis data tidak akan efektif. Teliti kemampuan penanganan UUID bawaan sistem basis data Anda untuk memastikan Anda mendapatkan kinerja terbaik dari solusi Anda.