Bahasa Indonesia

Alat pengembang · generator UUID

ULID, Snowflake, KSUID dan UUIDv7: ID yang Dapat Diurutkan Dibandingkan

· Latar belakang

uuid kriptografi browser-apis

Empat tata letak pengenal berdampingan: ULID, Snowflake, KSUID, dan UUIDv7, menampilkan bagian stempel waktu dan keacakan
Ilustrasi vektor ToolAcre asli

UUID acak tidak mengurutkan berdasarkan waktu pembuatan, jadi beberapa format mencantumkan stempel waktu terlebih dahulu. Posting ini membandingkan ULID, Snowflake, KSUID dan UUIDv7 dalam hal tata letak, ukuran, monotonisitas, dan kompatibilitas.

ID acak dan indeks yang membencinya — masalah yang dipecahkan oleh pengidentifikasi berdasarkan waktu

UUID v4 acak menyebarkan titik penyisipan di seluruh kunci utama pohon-B saat data baru tiba, menyebabkan pemisahan halaman dan reorganisasi. Penyisipan pada posisi acak menurunkan kinerja penulisan dan meningkatkan fragmentasi disk secara signifikan. Basis data dengan throughput tinggi menoleransi biaya ini—harga dari pengidentifikasi yang benar-benar independen dan tidak terkoordinasi—namun biayanya nyata. Jika Anda memerlukan UUID untuk mengurutkan berdasarkan waktu pembuatan, Anda dapat meningkatkan karakteristik indeks secara signifikan dengan menambahkan awalan stempel waktu. Beberapa format telah muncul: ULID, Snowflake, KSUID, dan RFC 9562 v7. Masing-masing membuat pengorbanan yang berbeda dalam ukuran (26 karakter hingga 128 bits), presisi stempel waktu (detik hingga nanodetik), kompatibilitas UUID, dan apakah koordinasi generator ID memerlukan sentralisasi. Tolok ukur basis data menunjukkan kinerja penyisipan meningkat secara signifikan.

ULID — stempel waktu milidetik 48-bit ditambah 80 bit acak dalam 26 karakter base32 Crockford, dengan opsi monotonik

ULID (Pengidentifikasi yang Dapat Diurutkan Secara Leksikografis Unik Secara Universal) mengkodekan stempel waktu 48-bit milidetik dan muatan acak 80-bit dalam 26 karakter Crockford base32. Representasi teks diurutkan dengan benar dalam urutan leksikografis, sehingga membuat ULID cocok untuk sistem yang mengutamakan pengurutan stempel waktu dan keterbacaan—pemrosesan log, penelusuran terdistribusi, layanan mikro yang mengharuskan pengidentifikasi mudah dibaca dalam keluaran yang dilihat manusia. ULID menawarkan varian monotonik di mana beberapa pengidentifikasi yang dihasilkan dalam milidetik yang sama meningkatkan bagian acak alih-alih mengulanginya, sehingga memastikan ledakan ID yang cepat mempertahankan urutan pembuatan yang ketat. Imbalannya adalah ULID bukan UUID: tidak sesuai dengan kolom database 128-bit UUID standar tanpa konversi pengkodean. Presisi ULID mencakup sekitar 8925 tahun.

Kepingan Salju — 64-bit ID dari stempel waktu, ID pekerja dan urutan, serta koordinasi yang diperlukan

Snowflake adalah pengidentifikasi 64-bit yang awalnya dirancang oleh Twitter, disusun sebagai stempel waktu milidetik 41-bit, ID pekerja 10-bit, dan nomor urut 12-bit. Stempel waktu 41-bit mencakup sekitar 69 tahun dan meluap di 2106, sehingga memerlukan koordinasi zaman dan perencanaan migrasi. ID pekerja membedakan pengidentifikasi yang dihasilkan oleh server atau proses yang berbeda—setiap generator Snowflake harus mengetahui ID pekerja uniknya sendiri tanpa menimbulkan konflik dengan yang lain. Kepingan salju adalah 64 bits bukannya 128, menjadikannya setengah ukuran UUID, lebih cepat untuk diindeks, dan lebih hemat penyimpanan per pengidentifikasi. Ini mengurutkan berdasarkan waktu dan ID pekerja, berguna untuk merutekan permintaan atau log berdasarkan sumber. Kekurangannya bersifat operasional: setiap generator harus diberi ID pekerja, jam harus tetap tersinkronisasi.

KSUID — stempel waktu detik dengan muatan acak besar, diurutkan berdasarkan byte

KSUID (K-Sortable Unique Identifier) ​​adalah pengidentifikasi 128-bit yang terdiri dari stempel waktu kedua Unix 32-bit dan payload acak 96-bit, biasanya dikodekan sebagai 27 karakter base62. Formatnya dapat diurutkan berdasarkan urutan leksikografis, dan bagian acaknya sesuai secara kriptografis sesuai ukurannya. KSUID kurang diadopsi secara luas dibandingkan ULID atau Snowflake tetapi menawarkan semantik yang berbeda: stempel waktu mudah didekodekan ke detik yang dapat dibaca manusia (berguna dalam log dan debugging), dan porsi acak 96-bit cukup besar sehingga beberapa KSUID yang dihasilkan pada detik yang sama secara efektif memiliki nol kemungkinan duplikat tanpa koordinasi urutan. Berbeda dengan Snowflake, KSUID tidak memerlukan koordinasi ID pekerja atau alokasi terpusat. KSUID beroperasi dalam hitungan detik, bukan milidetik, jadi beberapa ID dalam satu detik diurutkan secara acak kecuali Anda menerapkan logika tambahan.

UUIDv7 - jawaban jalur standar yang sesuai dengan kolom dan peralatan uuid yang ada

RFC 9562 v7 adalah pengidentifikasi 128-bit yang terdiri dari stempel waktu milidetik Unix 48-bit, 12 bits dengan presisi sub-milidetik (dapat digunakan sebagai penghitung urutan), dan 62 bit acak yang semuanya digabungkan. Ini mengurutkan dengan benar baik sebagai string leksikografis dan sebagai 128-bit byte dalam database. Yang terpenting, ini adalah UUID yang valid—ini menyetel nibble versi ke 7 dan bit varian ke standar RFC 9562, sehingga kompatibel dengan setiap alat, kolom database, dan API yang menangani UUID. Tidak diperlukan konversi pengkodean, dan infrastruktur UUID yang ada tidak memerlukan modifikasi. Jika beberapa pengidentifikasi v7 dihasilkan dalam milidetik yang sama, RFC 9562 merekomendasikan penggunaan bidang sub-milidetik sebagai penghitung monotonik, bukan bit acak. V7 mewakili pilihan pragmatis untuk menjaga kompatibilitas UUID.

Monotonisitas dalam satu milidetik — cara setiap format menangani burst dan mengapa hal ini penting untuk jaminan pemesanan

Monotonisitas adalah properti yang jika dua peristiwa terjadi dalam urutan yang dapat diamati, ID mereka dibandingkan dalam urutan yang sama. Pada tingkat perincian milidetik pada perangkat keras modern, beberapa peristiwa secara rutin terjadi dalam waktu yang sama, sehingga setiap skema ID yang dapat diurutkan harus menangani pengurutan sub-milidetik dengan benar. ULID menawarkan mode monotonik eksplisit di mana porsi acak bertambah, bukan mengacak. Kepingan salju menyertakan nomor urut 12-bit yang bertambah dalam hitungan milidetik. KSUID tidak memiliki mekanisme bawaan, sehingga peristiwa sub-detik diurutkan secara acak kecuali logika tambahan ditambahkan. RFC 9562 v7 merekomendasikan penggunaan bidang sub-milidetik sebagai penghitung monotonik. Jika sistem Anda menghasilkan ribuan UUID per detik, monotonisitas dalam satu milidetik berdampak signifikan pada pengurutan kueri.

Apa yang tidak tercakup dalam hal ini — tolok ukur throughput, yang bergantung pada perangkat keras dan bahasa; postingannya tetap kualitatif

Tolok ukur throughput dan data kinerja tidak disertakan karena sangat bergantung pada arsitektur perangkat keras, implementasi bahasa, mesin basis data, dan strategi caching. Karakteristik performa database sangat bervariasi tergantung apakah Anda mengukur penyisipan acak, kueri rentang, overhead indeks, atau total throughput dalam beban produksi yang realistis. Postingan ini tetap bersifat kualitatif, membandingkan format secara konseptual berdasarkan desainnya, bukan memberikan angka spesifik lingkungan yang dapat menyesatkan. Penilaian kinerja dunia nyata memerlukan pengujian di lingkungan Anda sendiri dengan beban kerja, basis kode, dan batasan operasional Anda sendiri. Membandingkan format ID yang berbeda merupakan latihan yang berharga.

Kesimpulan: kompatibilitas sering kali menentukan — generator ToolAcre menghasilkan UUID acak; gunakan pemeriksaan yang baik untuk mengonfirmasi bahwa UUIDv7 dari perpustakaan Anda diurai sebagai UUID

Kompatibilitas sering kali menentukan format mana yang akan dipilih. Jika skema database Anda sudah memerlukan UUID kolom, v7 adalah jawaban modern untuk kemampuan penyortiran tanpa meninggalkan ekosistem UUID. Jika membangun sistem baru dengan tipe ID khusus, ULID menawarkan representasi teks yang lebih kecil dan keunggulan presisi milidetik. Jika Anda memerlukan penyimpanan 64-bit dan dapat mengelola koordinasi ID pekerja melalui alokasi terpusat, Snowflake adalah pilihan yang terbukti dalam sistem bervolume tinggi. Pengorbanan mendasar adalah antara kompatibilitas standar (pilih v7) dan properti alternatif seperti ukuran lebih kecil (Snowflake) atau keterbacaan base32 (ULID). Buatlah pilihan berdasarkan kendala sistem dan keputusan ekosistem.