PostgreSQL 18 ตอนนี้ใกล้จะคลอดเต็มที่แล้ว เพราะว่า อยู่ใน beta 2 แล้ว ณ เวลาที่กำลังเขียนบทความนี้ ซึ่งแน่นอนว่าจะมีฟีเจอร์เพิ่มขึ้นเยอะเลย แต่วันนี้เราจะพาไปศึกษาฟีเจอร์ตัวหนึ่งที่น่าสนใจมากนั่นคือ UUIDv7 หรือ UUID ที่มีการบันทึกเวลา (timestamp-based UUID) และมันทำงานได้ดีมากกับ b-tree index เราจะไปศึกษาว่า ทำไม UUIDv7 นั้นเป็นสิ่งที่นักพัฒนาทั่วโลกรอคอย และ มันจะดีอย่างไร ถ้ามาใช้ใน PostgreSQL

PostgreSQL 18 จะมีฟีเจอร์ต่างๆ ดังต่อไปนี้

• Async I/O (with io_uring) — เร็วกว่าเดิม 2-3x seq scans, vacuums
• ข้ามสแกนใน multi-column btree indexes + smarter OR/IN optimizations
• UUIDv7
• คอลัมสร้างแบบเสมือน
• OAuth login + md5 เดือนการใช้งาน
• EXPLAIN ANALYZE ตอนนี้แสดง I/O, CPU, WAL
• Temporal constraints, LIKE on nondeterministic collation, casefolding
• New wire protocol version: 3.2

หากเรามาดูฟีเจอร์ทั้งหมดนั้น แน่นอนฟีเจอร์ที่เด่นที่สุด ก็จะเป็น async I/O แต่อย่างที่บอก วันนี้เราจะไปศึกษาว่า UUID นั้นจะได้รับประโยชน์อย่างไร ในแง่ของนักพัฒนา

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

หากพูดถึงระบบฐานข้อมูลเชิงสัมพันธ์นั้น (Relational Database) เราจะใช้การเพิ่มอัตโนมัติเป็น primary key (SERIAL หรือ identity) เพื่อที่จะสร้างไอดีของตารางขึ้นมา แต่เมื่อใดก็ตามที่เราต้องขยายระบบขึ้นมา เช่นใช้งานในหลาดๆ โหนด ไอดีดังกล่าวก็จะซ้ำกัน นั่นจึงเป็นเหตุผลว่าทำไมเราจึงจะต้องใช้ UUID

• ใช้ในระบบแบบกระจาย หรือ distributed database ถึงแม้ว่าว่าระบบเหล่านั้นจะมีการสร้างอัตโนมัติบ้าง แต่แบบเดิมจะมีข้อจำกัดเยอะ
• เป็นไอดีที่ยากแก่การคาดเดา หรืออาจจะเรียกว่าเดาไม่ได้เลยก็ว่าได้ ยกตัวอย่างเช่นผู้ไม่หวังดี อาจจะใช้ช่องโหว่ เพื่อสแกนหา ไอดี แบบเดิม แต่ถ้า UUID นั้นจะเป็นไปไม่ได้
• การใช้ UUID นั้นสร้างจาก client ได้เช่นกัน โดยเฉพาะในระบบ mobile app และ ระบบ serverless

แต่อย่างไรก็ตามการใช้ UUID นั้นจะมีข้อเสียอยู่บ้านในฐานข้อมูล

• การเรียง เพราะข้อมูลดังกล่าวนั้นเป็นข้อมูลที่เรียงได้ยาก
• การทำ index เพราะว่า แต่ละ UUID ที่สร้างนั้น ถ้ามองดูเราจะรู้ว่า เป็นตัวอักษรที่ไม่ใกล้กันเลย เพราะฉะนั้นการเพิ่มมันลงไปใหม่ในระบบ (insert) การเก็บก็จะต้องเกิดแบบสุ่ม แน่นอนมันจะมีปัญหากับ index และ ประสิทธิภาพการค้นหา
• ขนาดของมัน 128 บิต ในขณะที่ การเก็บข้อมูลของ INT จะอยู่ที่เพียง 32 บิต และ BIGINT ที่ 64บิต แน่นอนว่ากรณีใช้กับตารางเล็ก จะทำให้เกิด overhead อย่างไม่จำเป็น

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

ทำไมต้องเป็น UUIDv7

UUID นั้นถูกกำหนดเป็นมาตรฐานใน RFC 4122 ตั้งแต่ปี 2005 โดยมีรายละเอียดปลีกย่อย 5 ประเภท และ ต่อมามีการเพิ่มเข้าไปอีก 6-8 รายการใน RFC 9562 ที่ถูกตีพิมพ์ใน พ.ค. 2024 และนั่นจึงเป็นที่มาของการใช้ RFC 9562 ซึ่งเป็นรายละเอียดที่พูดถึงการใช้งานในฐานข้อมูล

UUIDv7 นั้นถูกสร้างขึ้นมาเพื่อแก้ปัญหาด้านการจัดเรียง และ การทำอินเด็กซ์ โดยการใช้ Unix Epoch timestamp เข้ามาในช่วง 48bit และที่เหลืออีก 74bit เป็นการสุ่ม บิตที่เหลือ คือ เวอร์ชั่นและรายละเอียด และ นี่เองทำให้ UUID เป็นตัวเลขที่สามารถเรียงกันได้ด้วยเวลา บวกกับความเป็นเอกลักษณ์ และนั่นจึงทำให้มันเหมาะอย่างยิ่งสำหรับการเป็น primary key ในฐานข้อมูล

UUIDv7 ใน PostgreSQL 18

ก่อนหน้า version 18 PostgreSQL มีการใช้งาน UUID ผ่านฟังก์ชัน gen_random_uuid() และเราจะได้รับ UUIDv4 แต่สำหรับ version 18 นี้จะมีฟังก์ชัน uuidv7() ที่ใช้สร้าง UUIDv7 ได้เลย และ PostgreSQL ใช้การสร้าง 12บิต เป็นส่วนของ sub-millisecond timestamp

• Facebook
• Twitter
• Line