ประเภทคอลัมน์ UUID ที่มีประสิทธิภาพที่สุดคืออะไร

15

สำหรับการจัดเก็บ UUID 128 บิตมีตัวเลือกการจัดเก็บหลายตัว:

คอลัมน์ไบต์ [16]
สองคอลัมน์ใหญ่ / ยาว (64 บิต)
คอลัมน์ CHAR (36) - เลขฐานสิบหก 32 หลัก + 4 ขีด
คอลัมน์เฉพาะฐานข้อมูล UUID หาก db สนับสนุน

จากมุมมองของการจัดทำดัชนีซึ่งมีประสิทธิภาพมากที่สุด? หาก db ไม่รองรับ uuid ชนิดเฉพาะที่ 1, 2, 3 เป็นตัวเลือกที่ดีที่สุด?

— Vlad Mihalcea
แหล่งที่มา

1

นี่เป็นบิตเกินไป "มันขึ้นอยู่กับ" - จำนวนมากของการใช้งานเฉพาะ

— Craig Ringer

2

ฉันจะไม่เลือก 3: ไม่เก็บบางสิ่งใน 36 ไบต์เมื่อทำได้ใน 16 ฉันใช้raw(16)ใน Oracle และuuidใน PostgreSQL

— โคลิน 't ฮาร์ต

1

ง่ายกว่าดีกว่า

— akuzminsky

uuid>> bytea>> textมีCHECKข้อ จำกัด > >>varchar(36) char(36)ดู: dba.stackexchange.com/a/89433/3684และdba.stackexchange.com/a/115316/3684

— Erwin Brandstetter

15

uuidประเภทเฉพาะคือทางออกที่ดีที่สุดของคุณสำหรับ PostgreSQL ยากที่จะพูดกับฐานข้อมูลอื่น ๆ - มันเป็นไปไม่ได้ที่ใครบางคนจะใส่uuidประเภทที่เก็บไว้อย่างมีประสิทธิภาพน้อยกว่าประเภทไบต์ที่เรียบง่าย

อีกครั้งใน PostgreSQL byteaจะเป็นวิธีที่เหมาะสมในการจัดเก็บ UUID ถ้าคุณไม่มีuuidประเภท สำหรับฐานข้อมูลอื่นนั้นขึ้นอยู่กับวิธีที่พวกเขาเก็บข้อมูลไบนารี

หากเป็นไปได้ฉันควรหลีกเลี่ยงการใช้เลขฐานสิบหกด้วยเครื่องหมายขีดกลาง เป็นวิธีที่มีประสิทธิภาพน้อยกว่าในการเปรียบเทียบเรียงลำดับและจัดเก็บ

ดังนั้นจริงๆ "ไม่ (2) หรือ (3)" เคย ใช้ (4) ในกรณีที่รองรับ (1) เป็นอย่างอื่น

— Craig Ringer
แหล่งที่มา

สิ่งหนึ่งที่ควรทราบคือประเภท PostgreSQL UUID ไม่ได้รับการสนับสนุนในอาร์เรย์หรือมีการแก้ไขหรือไม่ postgresql.org/message-id/…

— Christophe Roussy

@ChristopheRoussy นั่นคือจาก 2013 มันเป็นผู้กำกับดูแลเล็กน้อย SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]

— Craig Ringer

3

ตามลำดับที่ต้องการ: 4,1,2,3 อย่าใช้ UUIDs เป็นคีย์การทำคลัสเตอร์หากใช้เซิร์ฟเวอร์ SQL เป็นไม่เพียง แต่จะแยกส่วนไม่ดีเท่านั้นคีย์การทำคลัสเตอร์จะถูกใช้ในดัชนีที่ไม่ใช่คลัสเตอร์ทั้งหมดและคุณจะเพิ่มไบต์เหล่านั้นลงใน แต่ละแถวดัชนี การแตกแฟรกเมนต์สามารถบรรเทาได้โดยใช้ NEWSEQUENTIALID แต่โดยปกติแล้วจะต้องการข้อมูลเฉพาะตัวของ bingint สำหรับ Clustering Key ของคุณเหนือ GUID เพื่อป้องกันการขยายตัวของดัชนีอื่น ๆ

ความแตกต่างระหว่างการเลือก 1 มากกว่า 2 จะขึ้นอยู่กับว่าฐานข้อมูลมีประสิทธิภาพมากขึ้นอย่างไรจัดการกับคอลัมน์พื้นฐานสองชนิดในอาร์เรย์คงที่คอลัมน์เดียว มันควรจะง่ายพอที่จะทดสอบกับข้อมูลจำลอง ดูที่ความเร็วของการสืบค้นรวมถึงขนาดของดัชนีและข้อมูล Small + fast สุดยอดที่สุด!

— GilesDMiddleton
แหล่งที่มา

1

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

— ไมเคิลกรีน
แหล่งที่มา

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

— Vlad Mihalcea

@Vlad ฉันใช้ SQL Server AFAIK ทุกชนิดข้อมูลได้รับการจัดการเหมือนกันเมื่อสร้าง B-tree (หรือดัชนีแฮชสำหรับ 2104 ในหน่วยความจำ) มีเหตุผลที่ดีที่จะทำให้เรื่องนี้แคบที่สุดเท่าที่จะทำได้

— Michael Green