UUID v7: Penjana ID Masa-Sortir Berasaskan Pelayar
Setiap kali anda memerlukan satu set pengecam unik yang boleh diisih mengikut masa, UUID v7 adalah pilihan yang tepat. Halaman ini membolehkan anda menjana antara 1 hingga 100 ID UUID v7 dengan serta-merta, terus dalam pelayar anda – tiada data dihantar ke pelayan. ID yang terhasil adalah rentetan 36 aksara yang bermula dengan cap waktu 48-bit Unix milisaat, diikuti dengan bit rawak. Ini menjadikannya boleh diisih secara kronologi (mengikut masa penciptaan) sambil kekal tidak boleh diagak secara kriptografi.
Struktur UUID v7: Cap Waktu + Rawak
UUID v7 menggunakan format 128-bit yang distandardkan oleh RFC 9562 (dahulunya draf). Bahagian pertama ID adalah cap waktu Unix dalam milisaat, disimpan dalam 48 bit. Ini bermakna 12 aksara pertama UUID (dalam perwakilan heksadesimal dengan tanda sempang) akan berubah mengikut masa. Baki 80 bit adalah rawak, memberikan 2^80 kemungkinan nilai – lebih daripada cukup untuk mengelakkan perlanggaran pada skala besar.
Contoh: 018f3a6e-1234-5678-abcd-ef0123456789 – 12 aksara pertama (018f3a6e1234) adalah cap waktu, selebihnya rawak. Jika anda menjana berbilang ID dalam mikrosaat yang sama, bahagian rawak akan menentukan susunan – ia tidak menjamin turutan ketat dalam milisaat yang sama.
Mengapa ID Masa-Sortir Penting untuk Pangkalan Data
Pengecam seperti UUID v4 (rawak sepenuhnya) menyebabkan masalah prestasi apabila digunakan sebagai kunci primer dalam pangkalan data yang menggunakan indeks B-tree. Oleh kerana UUID v4 tersebar secara rawak, indeks perlu disusun semula dengan kerap, menyebabkan fragmentasi dan mengurangkan prestasi tulis. UUID v7 mengelakkan masalah ini dengan meletakkan cap waktu di awal, menjadikan ID baru sentiasa lebih besar daripada ID lama. Ini bermakna indeks B-tree hanya perlu menyisipkan di hujung kanan, mengurangkan fragmentasi dan meningkatkan melalui data.
Walau bagaimanapun, perlu diingat: UUID v7 tidak menjamin turutan ketat untuk ID yang dijana dalam milisaat yang sama. Jika sistem anda memerlukan pesanan tepat pada tahap mikrosaat, pertimbangkan ULID atau format lain yang menambah bit urutan. Namun untuk kebanyakan kes penggunaan pangkalan data, UUID v7 adalah peningkatan besar berbanding v4.
Input dan Output: Apa yang Anda Kawal
Halaman ini memberikan tiga kawalan mudah:
- Kiraan: Antara 1 hingga 100. Tukar nilai ini akan menjana semula semua ID serta-merta.
- Huruf Besar: Togol untuk memaparkan UUID dalam huruf besar (contoh:
018F3A6E-...). Perhatikan bahawa UUID adalah case-insensitive secara spesifikasi, tetapi sesetengah sistem menyimpan dalam huruf besar untuk kebolehbacaan. - Sertakan Sempang: Togol untuk mengeluarkan tanda sempang. UUID standard menggunakan sempang pada kedudukan 8-4-4-4-12. Tanpa sempang, rentetan menjadi 32 aksara heksadesimal (contoh:
018f3a6e12345678abcdef0123456789). Ini berguna jika sistem storan anda tidak memerlukan sempang.
Selepas penjanaan, anda akan melihat senarai ID, dikira dengan ID count: N. Status berubah daripada "Ready." kepada "Generated." Selepas menyalin semua ID, status menjadi "Copied all!". Setiap ID individu boleh disalin dengan mengkliknya.
Siapa yang Memerlukan Alat Ini
Alat ini ditujukan kepada:
- Pembangun sistem teragih: Membutuhkan kunci primer yang boleh diisih mengikut masa untuk mengelakkan pertikaian dan mengurangkan fragmentasi.
- Pentadbir pangkalan data: Mencari alternatif kepada UUID v4 untuk meningkatkan prestasi sisipan dalam jadual besar.
- Jurutera keselamatan: Memerlukan ID yang tidak boleh diagak tetapi masih membolehkan pengisihan masa untuk log audit atau acara.
- Sesiapa yang berhijrah dari UUID v4: Format berasaskan masa seperti v7 memudahkan penyusunan data kronologi tanpa mengorbankan uniqueness.
Perbandingan Format: UUID v7 vs v4, ULID, NanoID
| Format | Panjang | Berasaskan Masa | Kebolehisihan | Rawak | Komen |
|---|---|---|---|---|---|
| UUID v7 | 36 aksara (128 bit) | Ya (cap waktu 48-bit) | Kronologi | 80 bit | Standard RFC, sesuai untuk pangkalan data. |
| UUID v4 | 36 aksara (128 bit) | Tidak | Rawak | 122 bit | Mudah tetapi menyebabkan fragmentasi indeks. |
| ULID | 26 aksara (128 bit) | Ya (cap waktu 48-bit) | Kronologi dalam milisaat | 80 bit | Pekat, huruf besar, tidak termasuk sempang. |
| NanoID | 21 aksara (pilihan) | Tidak secara lalai | Rawak | Tidak tetap | Sangat pendek, boleh disesuaikan, tetapi bukan UUID. |
UUID v7 adalah satu-satunya format yang mematuhi spesifikasi RFC dan menggunakan cap waktu diikuti rawak. ULID juga menggunakan cap waktu tetapi dienkod dalam base32; ia menawarkan kronologi yang lebih ketat dalam milisaat yang sama dengan bit urutan (pilihan). NanoID tidak direka untuk pengisihan masa.
Kelebihan Penjanaan Setempat (Pelayar)
Semua penjanaan berlaku dalam pelayar anda menggunakan window.crypto atau Math.random yang dipacu kriptografi. Tiada data dihantar ke pelayan BroBroGo. Ini bermakna:
- Privasi terpelihara: Tiada cap waktu atau ID anda meninggalkan peranti.
- Ketersediaan luar talian (jika halaman dimuatkan): Setelah skrip dimuat, penjanaan berfungsi tanpa sambungan internet.
- Kelajuan: Penjanaan 100 ID berlaku dalam milisaat – tiada latency rangkaian.
Walau bagaimanapun, kelemahannya ialah cap waktu bergantung pada jam sistem setempat. Jika jam pengguna tidak tepat, turutan kronologi mungkin terjejas. Untuk aplikasi pengeluaran, gunakan UUID v7 yang dijana di pelayan dengan jam NTP yang disegerakkan.
Soalan Lazim (FAQ)
1. Bolehkah UUID v7 dijamin unik jika saya menjana 100 ID dalam milisaat yang sama?
Ya, kerana bahagian rawak 80 bit memberikan ruang yang sangat besar. Kebarangkalian perlanggaran adalah diabaikan (kira-kira 1 dalam 2^80 untuk setiap pasangan).
2. Adakah UUID v7 lebih selamat daripada UUID v4 dari segi tidak boleh diagak?
Kedua-duanya menggunakan rawak kriptografi yang kukuh. UUID v7 juga tidak boleh diagak kerana 80 bit rawak tidak dapat diramal. Hanya cap waktu yang boleh diramal, tetapi itu tidak membantu meneka ID penuh.
3. Bolehkah saya menggunakan UUID v7 untuk kunci primer dalam pengkalan data hubungan?
Ya, sebenarnya ia lebih baik daripada UUID v4 kerana sifat masa-sortirnya mengurangkan fragmentasi indeks. Namun, untuk jadual besar, pertimbangkan untuk menggunakan jenis data uuid (jika pangkalan data menyokong) atau simpan sebagai rentetan.
4. Mengapa susunan ID dalam senarai mungkin tidak mengikut masa penjanaan?
Kredit alat ini menjana ID dalam kelompok – semua ID mendapat cap waktu yang sama (masa semasa penjanaan). Jadi dalam senarai, ia disusun mengikut bit rawak, bukan mengikut masa penciptaan yang berbeza. Jika anda menjana semula dengan selang masa, ID baru akan kelihatan lebih besar.
5. Apakah perbezaan antara UUID v7 dan ULID?
Kedua-dua menggunakan cap waktu 48-bit. ULID menggunakan pengekodan base32 (26 aksara, huruf besar) dan boleh mempunyai bit urutan untuk susunan dalam milisaat yang sama. UUID v7 menggunakan perwakilan heksadesimal 36 aksara dengan sempang dan tidak mempunyai mekanisme susunan dalam milisaat.
6. Bolehkah saya menghasilkan berjuta-juta UUID v7 dengan alat ini?
Alat ini terhad kepada 100 ID setiap kali. Untuk pengeluaran besar, gunakan perpustakaan seperti uuid (npm) atau fungsi terbina dalam pangkalan data seperti gen_random_uuid() (PostgreSQL) dengan sambungan pgcrypto yang menyokong UUID v7.