เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
ULID, Snowflake, KSUID และ UUIDv7: เมื่อเปรียบเทียบ ID ที่จัดเรียงได้
· พื้นหลัง
uuid การเข้ารหัส เบราว์เซอร์-apis
UUID แบบสุ่มจะไม่เรียงลำดับตามเวลาที่สร้าง ดังนั้นหลายรูปแบบจึงต้องมีการประทับเวลาก่อน โพสต์นี้เปรียบเทียบ ULID, Snowflake, KSUID และ UUIDv7 ในรูปแบบ ขนาด ความซ้ำซากจำเจ และความเข้ากันได้
ID แบบสุ่มและดัชนีที่เกลียดชัง — ปัญหาที่ตัวระบุตามลำดับเวลาแก้ไขได้
UUID แบบสุ่ม v4 กระจายจุดแทรกไปทั่วคีย์หลัก B-tree เมื่อมีบันทึกใหม่มาถึง ทำให้เกิดการแตกหน้าและจัดระเบียบใหม่ การแทรกที่ตำแหน่งสุ่มจะลดประสิทธิภาพการเขียนและเพิ่มการกระจายตัวของดิสก์อย่างมาก ฐานข้อมูลที่มีปริมาณงานสูงสามารถทนต่อต้นทุนนี้ได้ ซึ่งเป็นราคาของตัวระบุที่เป็นอิสระและไม่ประสานกันอย่างแท้จริง แต่ต้นทุนนั้นเกิดขึ้นจริง หากคุณต้องการให้ UUID จัดเรียงตามเวลาที่สร้าง คุณสามารถปรับปรุงลักษณะดัชนีได้อย่างมากโดยการเพิ่มคำนำหน้าการประทับเวลา มีหลายรูปแบบ: ULID, Snowflake, KSUID และ RFC 9562 v7 แต่ละรายการมีการแลกเปลี่ยนขนาดที่แตกต่างกัน (26 อักขระถึง 128 bits) ความแม่นยำในการประทับเวลา (วินาทีเป็นนาโนวินาที) ความเข้ากันได้ UUID และการประสานงานตัวสร้าง ID จำเป็นต้องรวมศูนย์หรือไม่ การวัดประสิทธิภาพฐานข้อมูลแสดงประสิทธิภาพการแทรกที่ดีขึ้นอย่างมาก
ULID — การประทับเวลา 48 บิตมิลลิวินาทีบวก 80 บิตสุ่มใน 26 อักขระฐาน Crockford 32 ตัว พร้อมตัวเลือกแบบโมโนโทนิก
ULID (ตัวระบุที่เรียงลำดับตามพจนานุกรมที่ไม่ซ้ำแบบสากล) เข้ารหัสการประทับเวลา 48 บิตมิลลิวินาทีและ 80-บิต เพย์โหลดแบบสุ่มใน 26 อักขระของ Crockford base32 การแสดงข้อความจัดเรียงอย่างถูกต้องตามลำดับพจนานุกรม ทำให้ ULID เหมาะสำหรับระบบที่การเรียงลำดับการประทับเวลาและความสามารถในการอ่านมีความสำคัญ เช่น การประมวลผลบันทึก การติดตามแบบกระจาย ไมโครเซอร์วิสที่ตัวระบุจำเป็นต้องอ่านได้ง่ายในเอาต์พุตที่ต้องเผชิญกับมนุษย์ ULID นำเสนอตัวแปรแบบโมโนโทนิกที่ตัวระบุหลายตัวที่สร้างขึ้นภายในมิลลิวินาทีเดียวกันจะเพิ่มส่วนที่สุ่มแทนการทำซ้ำ เพื่อให้มั่นใจว่า ID ที่ออกมาอย่างรวดเร็วแม้จะรักษาลำดับการสร้างที่เข้มงวด ข้อเสียคือ ULID ไม่ใช่ UUID: มันไม่พอดีกับคอลัมน์ฐานข้อมูล 128-bit UUID มาตรฐานที่ไม่มีการเข้ารหัสการแปลง ความแม่นยำ ULID ครอบคลุมประมาณ 8925 ปี
Snowflake — ID 64 บิตจากการประทับเวลา ID ผู้ปฏิบัติงานและลำดับ และการประสานงานที่พวกเขาต้องการ
Snowflake คือตัวระบุ 64 บิตที่ออกแบบโดย Twitter โดยมีโครงสร้างเป็นการประทับเวลา 41 บิตมิลลิวินาที ID ผู้ปฏิบัติงาน 10 บิต และหมายเลขลำดับ 12 บิต การประทับเวลา 41 บิตครอบคลุมประมาณ 69 ปีและล้นใน 2106 ซึ่งจำเป็นต้องมีการประสานงานในยุคและการวางแผนการย้ายข้อมูล ID ผู้ปฏิบัติงานจะแยกความแตกต่างระหว่างตัวระบุที่สร้างโดยเซิร์ฟเวอร์หรือกระบวนการที่แตกต่างกัน ตัวสร้าง Snowflake แต่ละตัวจะต้องทราบ ID ผู้ปฏิบัติงานเฉพาะของตัวเองโดยไม่ขัดแย้งกับรหัสอื่น Snowflake คือ 64 bits แทนที่จะเป็น 128 ทำให้มีขนาดเพียงครึ่งหนึ่งของ UUID จัดทำดัชนีได้เร็วกว่า และประหยัดพื้นที่จัดเก็บต่อตัวระบุมากขึ้น โดยจะจัดเรียงตามเวลาและรหัสผู้ปฏิบัติงาน ซึ่งมีประโยชน์สำหรับคำขอกำหนดเส้นทางหรือบันทึกตามแหล่งที่มา ข้อเสียเปรียบคือใช้งานได้: เครื่องกำเนิดไฟฟ้าทุกเครื่องจะต้องกำหนด ID ผู้ปฏิบัติงาน นาฬิกาจะต้องซิงโครไนซ์อยู่เสมอ
KSUID — การประทับเวลาวินาทีพร้อมเพย์โหลดแบบสุ่มขนาดใหญ่ จัดเรียงเป็นไบต์
KSUID (K-Sortable Unique Identifier) เป็นตัวระบุ 128 บิตที่ประกอบด้วยการประทับเวลาวินาทีของ Unix 32-บิต และเพย์โหลดแบบสุ่ม 96-บิต โดยทั่วไปจะเข้ารหัสเป็นอักขระ 27 base62 รูปแบบสามารถจัดเรียงตามลำดับพจนานุกรม และส่วนที่สุ่มจะมีการเข้ารหัสเสียงตามขนาดของมัน KSUID ถูกนำมาใช้กันอย่างแพร่หลายน้อยกว่า ULID หรือ Snowflake แต่มีความหมายที่แตกต่างกัน: การประทับเวลาสามารถถอดรหัสได้อย่างง่ายดายเป็นวินาทีที่มนุษย์อ่านได้ (มีประโยชน์ในบันทึกและการดีบัก) และส่วนสุ่ม 96 บิตมีขนาดใหญ่เพียงพอที่ KSUID หลายรายการที่สร้างขึ้นในวินาทีเดียวกันมีความน่าจะเป็นที่ซ้ำกันเป็นศูนย์อย่างมีประสิทธิภาพโดยไม่มีการประสานงานของลำดับ ต่างจาก Snowflake ตรงที่ KSUID ไม่ต้องมีการประสานงานรหัสผู้ปฏิบัติงานหรือการจัดสรรจากส่วนกลาง KSUID ทำงานเป็นวินาทีแทนที่จะเป็นมิลลิวินาที ดังนั้น ID หลายรายการภายในหนึ่งวินาทีจึงเรียงลำดับแบบสุ่ม เว้นแต่คุณจะใช้ตรรกะเพิ่มเติม
UUIDv7 - คำตอบแบบมาตรฐานที่เหมาะกับคอลัมน์และเครื่องมือ uuid ที่มีอยู่
RFC 9562 v7 คือ 128-บิต ตัวระบุที่ประกอบด้วย 48-บิต การประทับเวลามิลลิวินาทีของ Unix, 12 bits ที่มีความแม่นยำต่ำกว่ามิลลิวินาที (ใช้เป็นเครื่องนับลำดับ) และ 62 บิตสุ่มทั้งหมดรวมกัน โดยเรียงลำดับอย่างถูกต้องทั้งในรูปแบบสตริงพจนานุกรมและเป็นไบต์ 128 บิตในฐานข้อมูล สิ่งสำคัญที่สุดคือ UUID ที่ถูกต้อง โดยจะตั้งค่าเวอร์ชัน nibble เป็น 7 และบิตตัวแปรเป็น RFC 9562 มาตรฐาน ทำให้เข้ากันได้กับทุกเครื่องมือ คอลัมน์ฐานข้อมูล และ API ที่จัดการ UUID ไม่จำเป็นต้องแปลงการเข้ารหัส และโครงสร้างพื้นฐาน UUID ที่มีอยู่ไม่จำเป็นต้องแก้ไข หากมีการสร้างตัวระบุ v7 หลายตัวในมิลลิวินาทีเดียวกัน RFC 9562 ขอแนะนำให้ใช้ฟิลด์ย่อยมิลลิวินาทีเป็นตัวนับแบบโมโนโทนิกแทนที่จะเป็นบิตสุ่ม V7 แสดงถึงตัวเลือกในทางปฏิบัติเพื่อรักษาความเข้ากันได้ UUID
ความซ้ำซากจำเจภายในหนึ่งมิลลิวินาที — แต่ละรูปแบบจัดการกับการระเบิดอย่างไร และเหตุใดจึงมีความสำคัญต่อการรับประกันการสั่งซื้อ
Monotonicity เป็นคุณสมบัติที่หากเหตุการณ์สองเหตุการณ์เกิดขึ้นตามลำดับที่สังเกตได้ ID ของเหตุการณ์จะเปรียบเทียบกันในลำดับเดียวกันนั้น ที่รายละเอียดระดับมิลลิวินาทีบนฮาร์ดแวร์สมัยใหม่ เหตุการณ์ต่างๆ มักเกิดขึ้นภายในขีดนาฬิกาเดียวกัน ดังนั้น Scheme ID ที่จัดเรียงได้ใดๆ จะต้องจัดการการจัดลำดับที่ต่ำกว่ามิลลิวินาทีอย่างถูกต้อง ULID เสนอโหมดโมโนโทนิกที่ชัดเจน โดยส่วนที่สุ่มจะเพิ่มขึ้นแทนที่จะสุ่ม Snowflake มีหมายเลขลำดับ 12 บิตที่เพิ่มขึ้นภายในเครื่องหมายมิลลิวินาที KSUID ขาดกลไกในตัว ดังนั้นเหตุการณ์ย่อยวินาทีจึงเรียงลำดับแบบสุ่ม เว้นแต่จะเพิ่มตรรกะเพิ่มเติม RFC 9562 v7 ขอแนะนำให้ใช้ฟิลด์ย่อยมิลลิวินาทีเป็นตัวนับแบบโมโนโทนิก หากระบบของคุณสร้าง UUID หลายพัน UUID ต่อวินาที ความซ้ำซ้อนภายในหนึ่งมิลลิวินาทีจะส่งผลต่อลำดับการสืบค้นอย่างมาก
สิ่งนี้ไม่ครอบคลุม — เกณฑ์มาตรฐานปริมาณงาน ซึ่งขึ้นอยู่กับฮาร์ดแวร์และภาษา โพสต์ยังคงมีคุณภาพ
การวัดประสิทธิภาพปริมาณงานและข้อมูลประสิทธิภาพจะไม่รวมอยู่ด้วย เนื่องจากขึ้นอยู่กับสถาปัตยกรรมฮาร์ดแวร์ การใช้งานภาษา กลไกฐานข้อมูล และกลยุทธ์การแคชเป็นหลัก ลักษณะประสิทธิภาพของฐานข้อมูลจะแตกต่างกันอย่างมากไม่ว่าคุณจะวัดการแทรกแบบสุ่ม การสืบค้นช่วง โอเวอร์เฮดของดัชนี หรือปริมาณงานทั้งหมดภายใต้ปริมาณงานจริงที่โหลดจริง โพสต์ยังคงมีคุณภาพ โดยเปรียบเทียบรูปแบบตามแนวคิดตามการออกแบบ แทนที่จะระบุตัวเลขเฉพาะสภาพแวดล้อมที่อาจทำให้เข้าใจผิด การประเมินประสิทธิภาพในโลกแห่งความเป็นจริงจำเป็นต้องมีการทดสอบในสภาพแวดล้อมของคุณเองโดยมีปริมาณงาน โค้ดเบส และข้อจำกัดในการปฏิบัติงานของคุณเอง การเปรียบเทียบรูปแบบ ID ต่างๆ ถือเป็นแบบฝึกหัดที่มีคุณค่า
ประเด็นสำคัญ: ความเข้ากันได้มักจะเป็นตัวกำหนด — ตัวสร้าง ToolAcre สร้าง UUID แบบสุ่ม ใช้การตรวจสอบที่มีรูปแบบที่ดีเพื่อยืนยันว่า UUIDv7 จากไลบรารีของคุณแยกวิเคราะห์เป็น UUID
ความเข้ากันได้มักเป็นตัวกำหนดว่าจะเลือกรูปแบบใด หากสคีมาฐานข้อมูลของคุณต้องการคอลัมน์ UUID อยู่แล้ว v7 คือคำตอบสมัยใหม่สำหรับความสามารถในการจัดเรียงโดยไม่ต้องออกจากระบบนิเวศ UUID หากสร้างระบบใหม่ด้วยประเภท ID ที่กำหนดเอง ULID นำเสนอการแสดงข้อความที่เล็กลงและข้อดีด้านความแม่นยำในระดับมิลลิวินาที หากคุณต้องการพื้นที่จัดเก็บ 64 บิตและสามารถจัดการการประสานงาน ID ผู้ปฏิบัติงานผ่านการจัดสรรแบบรวมศูนย์ Snowflake เป็นตัวเลือกที่ได้รับการพิสูจน์แล้วในระบบที่มีปริมาณมาก ข้อดีข้อเสียพื้นฐานคือระหว่างความเข้ากันได้มาตรฐาน (เลือก v7) และคุณสมบัติทางเลือก เช่น ขนาดที่เล็กกว่า (Snowflake) หรือความสามารถในการอ่าน base32 (ULID) ตัดสินใจเลือกตามข้อจำกัดของระบบและการตัดสินใจเกี่ยวกับระบบนิเวศ