UUID v4 หรือ v7: ควรใช้แบบไหน และทำไมถึงสำคัญ

ใช้ UUID v4 เมื่อคุณต้องการตัวระบุแบบสุ่มและไม่ต้องการอะไรเพิ่มเติม ใช้ UUID v7 เมื่อตัวระบุนั้นจะเป็นคีย์ของฐานข้อมูล หรือเมื่อคุณต้องการให้ ID เรียงตามเวลาที่สร้าง ทั้งสองแบบมีขนาด 128 บิต และเขียนในรูปแบบ 36 อักขระเหมือนกัน ความต่างอยู่ที่การจัดเรียงบิต ตัวสร้าง UUID ด้านล่างสร้างได้ทั้งสองเวอร์ชัน ครั้งละ 1 ถึง 500 รายการ ทำงานในเบราว์เซอร์ของคุณ

ตัวสร้าง UUIDต้องการ ID ที่ไม่ซ้ำสำหรับโค้ดใช้ฟรี

หน้าตาของ UUID

UUID หรือ universally unique identifier คือตัวเลข 128 บิตที่เขียนเป็นเลขฐานสิบหก 32 หลัก แบ่งเป็นห้ากลุ่ม ได้แก่ 8, 4, 4, 4 และ 12 หลัก คั่นด้วยขีดกลาง ตัวอย่างเช่น 3f2b8c1e-6d4a-4f7b-9c2e-8a1d5e0b7f63

มีสองส่วนของตัวเลขที่กำหนดตายตัว บิต 4 บิตใช้เก็บเวอร์ชัน ดังนั้นกลุ่มที่สามจะขึ้นต้นด้วย 4 สำหรับ v4 หรือ 7 สำหรับ v7 บิต 2 บิตใช้เก็บ variant ดังนั้นกลุ่มที่สี่จะขึ้นต้นด้วย 8, 9, a หรือ b ส่วนที่เหลือคือตัวระบุจริง ๆ บิตของ variant และเวอร์ชันคือเหตุผลที่ UUID v4 มีบิตสุ่มอยู่ 122 บิต ไม่ใช่ 128 บิต

UUID v4: สุ่ม

UUID v4 สุ่มทั้งหมด ยกเว้นบิตคงที่ที่กล่าวไปข้างต้น บิตสุ่ม 122 บิตทำให้โอกาสที่ค่าจะซ้ำกันต่ำมาก ลองสมมติว่าคุณสร้าง UUID v4 หนึ่งพันล้านรายการ โอกาสที่จะมีสองรายการตรงกันประมาณ n กำลังสองหารด้วยสองเท่าของจำนวนค่าที่เป็นไปได้ ซึ่งได้ราว 10 ยกกำลังลบ 19 กล่าวอีกอย่างคือ การชนกันของค่าไม่ใช่สิ่งที่คุณต้องออกแบบรับมือ

การประมาณนี้สมมติว่าตัวสร้างดึงบิตจากแหล่งสุ่มเชิงเข้ารหัส หากตัวสร้างคาดเดาได้ การประมาณนี้ก็ใช้ไม่ได้ เครื่องมือนี้ใช้แหล่งสุ่มเชิงเข้ารหัสของเบราว์เซอร์ ผ่าน crypto.randomUUID หรือ crypto.getRandomValues

UUID v7: เวลามาก่อน

RFC 9562 กำหนดมาตรฐาน v7 บิต 48 บิตแรกเก็บเวลายูนิกซ์เป็นมิลลิวินาที ดังนั้น ID ที่สร้างทีหลังจะมีส่วนแรกที่มากกว่า ID ที่สร้างก่อนหน้า หลังจากนั้นคือบิตเวอร์ชัน แล้วตามด้วยบิตสุ่ม บิต variant และบิตสุ่มส่วนที่เหลือ พื้นที่สุ่มบางส่วนอาจใช้เก็บตัวนับ ซึ่งช่วยให้ ID ยังคงเรียงลำดับได้ เมื่อสร้างหลายรายการในมิลลิวินาทีเดียวกัน

เนื่องจากเวลาอยู่ข้างหน้า การเรียงลำดับ ID v7 เป็นข้อความ โดยใช้ตัวพิมพ์เดียวกันทั้งหมด จะเรียงตามเวลาที่สร้างได้ถึงระดับมิลลิวินาที ซึ่งทำได้เพราะเลขฐานสิบหกมีความกว้างคงที่ และเวลาอยู่ในตัวอักษรนำหน้า

เวลาก็มองเห็นได้เช่นกัน ใครก็ตามที่อ่าน UUID v7 จะเห็นได้คร่าว ๆ ว่าสร้างเมื่อไร คุณลองตรวจสอบได้เอง ด้วยช่อง Inspect ในตัวสร้าง UUID ซึ่งจะแปลงบิต 48 บิตแรกกลับเป็นวันที่และเวลา

ทำไม v7 เหมาะกับดัชนีฐานข้อมูล

ดัชนีฐานข้อมูลโดยทั่วไปคือ B-tree ซึ่งเป็นโครงสร้างที่เก็บเรียงตามคีย์ เมื่อคีย์เป็นแบบสุ่มอย่าง v4 แถวใหม่แต่ละแถวจะไปอยู่ในตำแหน่งสุ่มของดัชนี ฐานข้อมูลจึงต้องเขียนลงในส่วนต่าง ๆ ของดัชนีหลายจุด ทำให้เกิดการแยกหน้า (page split) และการไม่พบข้อมูลในแคชมากขึ้น เมื่อตารางมีขนาดใหญ่ งานส่วนนี้จะสะสมจนเห็นผล

คีย์ v7 มีค่ามากกว่าคีย์เกือบทั้งหมดที่อยู่ในดัชนีอยู่แล้ว เพราะส่วนเวลาเพิ่มขึ้นเรื่อย ๆ แถวใหม่จึงถูกเพิ่มใกล้ท้ายดัชนี คล้ายกับการใช้เลขที่เพิ่มอัตโนมัติ หน้าดัชนีล่าสุดจึงคงอยู่ในหน่วยความจำ และการเขียนก็เป็นระเบียบ ความต่างนี้เห็นได้ชัดที่สุดในตารางขนาดใหญ่ที่เติบโตตลอดเวลา ส่วนในตารางขนาดเล็กจะแทบมองไม่เห็น

เลือกระหว่าง v4 กับ v7

• คีย์หลักของฐานข้อมูล หรือตารางใดก็ตามที่เติบโตตามเวลา: v7 ดัชนีจะเป็นระเบียบ
• บันทึก เหตุการณ์ หรือข้อความที่คุณมักเรียงตามเวลา: v7 เพราะตัว ID เองมีลำดับอยู่แล้ว
• ID สาธารณะที่ควรเก็บเวลาที่สร้างไว้เป็นความลับ: v4 เพราะ ID v7 เปิดเผยว่าสร้างเมื่อไร
• หลายอุปกรณ์ที่นาฬิกาไม่น่าเชื่อถือ: ทั้ง v4 และ v7 ยังคงไม่ซ้ำกัน เพราะบิตสุ่มทำหน้าที่นั้น มีเพียงลำดับการเรียงของ v7 เท่านั้นที่ขึ้นอยู่กับความถูกต้องของนาฬิกา

ทั้งสองเวอร์ชันเป็นมาตรฐาน แต่ไลบรารีรุ่นเก่าอาจรู้จักเฉพาะ v4 RFC 4122 อธิบายเวอร์ชัน 1 ถึง 5 มาเป็นเวลานาน RFC 9562 เผยแพร่ในพฤษภาคม 2024 ใช้แทน RFC 4122 และกำหนดเวอร์ชัน 6, 7 และ 8 ก่อนพึ่งพาไลบรารีใด ควรตรวจสอบว่าไลบรารีนั้นรองรับ v7 หรือไม่

การจัดเก็บ UUID

UUID ที่เขียนเป็นข้อความใช้ 36 อักขระ ส่วน 16 ไบต์ของมันสามารถเก็บในรูปแบบไบนารีได้ ซึ่งใช้พื้นที่น้อยกว่ามาก ฐานข้อมูลหลายตัวมีชนิดข้อมูล UUID มาในตัว หรือคอลัมน์ไบนารี 16 ไบต์สำหรับใช้งานนี้โดยเฉพาะ และการเปรียบเทียบจะเร็วกว่าข้อความ

เลือกรูปแบบหนึ่งแล้วใช้ให้สม่ำเสมอ ตัวพิมพ์ใหญ่ ตัวพิมพ์เล็ก ขีดกลาง และวงเล็บปีกกา สำหรับคนแล้วเป็น UUID เดียวกันทั้งหมด แต่ฐานข้อมูลหรือการเปรียบเทียบสตริงอาจมองว่าเป็นค่าต่างกัน ตัวเลือกตัวพิมพ์ใหญ่ ไม่มีขีดกลาง และวงเล็บปีกกาในตัวสร้างมีไว้สำหรับระบบที่ต้องการรูปแบบเหล่านั้น

อย่าใช้ UUID เป็นความลับ

UUID เป็นตัวระบุ ไม่ใช่รหัสผ่าน โทเค็นของเซสชัน หรือกุญแจเข้าถึง มันถูกออกแบบให้ไม่ซ้ำ ไม่ได้ออกแบบให้คาดเดาไม่ได้ UUID v7 ยังบรรจุเวลาที่สร้างไว้ด้วย อีกทั้งตัวระบุมักถูกคัดลอกไปวางในลิงก์ บันทึก อีเมล และภาพหน้าจอ ซึ่งใครก็ตามที่เห็นก็นำไปใช้ซ้ำได้

การควบคุมการเข้าถึงต้องทำที่เซิร์ฟเวอร์ คนที่รู้ ID ไม่ควรได้สิทธิ์ดูหรือแก้ไขข้อมูลที่ ID นั้นชี้ไปโดยอัตโนมัติ สำหรับรหัสผ่าน วลีรหัสผ่าน หรือโทเค็น ให้ใช้เครื่องมือสร้างที่ออกแบบมาเพื่อความลับ ตัวสร้างรหัสผ่าน สร้างรหัสผ่านแบบสุ่มหรือวลีรหัสผ่านจากคำต่าง ๆ บนอุปกรณ์ของคุณโดยใช้ความสุ่มที่ปลอดภัย และประเมินความแข็งแรงให้ด้วย หากต้องการทำความเข้าใจว่าทำไมความยาวและความสุ่มจึงสำคัญ อ่านรหัสผ่านที่แข็งแรงและเอนโทรปี

วิธีใช้เครื่องมือ

1. เลือกเวอร์ชัน 4 สำหรับ ID แบบสุ่ม หรือเวอร์ชัน 7 สำหรับ ID ที่เรียงตามเวลา
2. กำหนดจำนวน ตั้งแต่ 1 ถึง 500 รายการต่อครั้ง
3. เลือกตัวพิมพ์ใหญ่ ไม่มีขีดกลาง หรือไม่มีวงเล็บ หากโค้ดของคุณต้องการรูปแบบเฉพาะ
4. คัดลอกทั้งหมด หรือดาวน์โหลดรายการเป็นไฟล์ .txt
5. วาง UUID ใดก็ได้ในช่อง Inspect เพื่ออ่านเวอร์ชัน variant และสำหรับ v7 เวลาที่ฝังอยู่ในตัวมัน

คำตอบสั้น ๆ

UUID v4 ไม่ซ้ำกันจริงหรือ? ในทางปฏิบัติ ใช่ บิตสุ่ม 122 บิตทำให้โอกาสซ้ำต่ำมากจนคุณไม่จำเป็นต้องตรวจหา

ควรใช้ v7 กับทุกอย่างไหม? ไม่จำเป็นเสมอไป ใช้ v7 กับคีย์ฐานข้อมูลและทุกอย่างที่เรียงตามเวลา ใช้ v4 เมื่อเวลาที่สร้างควรซ่อนไว้

ใช้ UUID เป็นรหัสผ่านได้ไหม? ไม่ได้ UUID เป็นตัวระบุ สำหรับสิ่งที่ต้องเก็บเป็นความลับ ให้ใช้ตัวสร้างรหัสผ่าน

เครื่องมือส่ง ID ไปที่ไหนหรือไม่? ไม่ ID ถูกสร้างและแสดงในเบราว์เซอร์ของคุณ และไม่ถูกส่งไปยังเซิร์ฟเวอร์