ข้อเสียของการใช้ UUID หรือ GUID เป็นคีย์หลักคืออะไร

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

ข้อเสียของการใช้ UUID หรือ GUID เป็นคีย์หลักสำหรับตารางของฉันคืออะไร

ฉันอาจจะใช้ Derby / JavaDB (บนไคลเอนต์) และ PostgreSQL (บนเซิร์ฟเวอร์) เป็น DBMS

— โจนัส
แหล่งที่มา

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

— Brian Ballsun-Stanton

@Brian: UUID ในระบบแบบกระจายมีประโยชน์เนื่องจากคุณสามารถสร้างคีย์หลักบนไคลเอนต์แล้วอัปโหลดข้อมูลแบบอะซิงโครนัสไปยังเซิร์ฟเวอร์ ฉันส่วนใหญ่คิดเกี่ยวกับข้อเสียของการอ่าน การใช้จำนวนมากเข้าร่วมกับ UUID อาจไม่ดีหรือ ในตัวอย่างลูกค้าเพิ่มรายการ (UUID ชื่อผู้จำหน่ายผู้สร้าง) ไปยังระบบสินค้าคงคลังแล้วฐานข้อมูลท้องถิ่นจะถูกซิงโครไนซ์กับฐานข้อมูลส่วนกลางบนเซิร์ฟเวอร์

— Jonas

ฉันคิดว่าหากไม่มีความเห็นที่ชัดเจนเกี่ยวกับเรื่องนี้มันจะเป็นไปได้มากที่สุดว่า "ขึ้นอยู่กับ" หากปราศจากสิ่งเหล่านี้ฉันจะไปหา VtC

— jcolebrand

มีบทความที่พูดถึง GUID กับ non-GUID ที่ส่งผลกระทบต่อดัชนีคลัสเตอร์ใน SQL Server ที่คุณอาจพบว่าน่าสนใจแม้ว่าจะเกี่ยวข้องกับผลิตภัณฑ์ SQL อื่น: x.co/Twpp

— Jeff

ฉันสังเกตเห็นว่าDerby docไม่ได้แสดงรายการ UUID เป็นชนิดข้อมูล คุณอาจต้องการที่จะต้องพิจารณาทางเลือกเช่นเครื่องยนต์ H2 Database (ฐานข้อมูล Java บริสุทธิ์เหมือนดาร์บี้) ซึ่งจะแสดงรายการชนิดข้อมูล UUID แน่นอน Postgres มีการสนับสนุนที่ยอดเยี่ยมสำหรับการจัดเก็บการทำดัชนีและการสร้างค่า UUID อย่างมีประสิทธิภาพ

— Basil Bourque

คำตอบ:

มันขึ้นอยู่กับฟังก์ชั่นการสร้างและขนาดของตารางสุดท้ายของคุณ

GUID มีวัตถุประสงค์เพื่อเป็นตัวระบุที่ไม่ซ้ำกันทั่วโลก ตามที่กล่าวไว้ในเอกสารของPostgres 8.3ไม่มีวิธีการที่เหมาะสมในระดับสากลในการสร้างตัวระบุเหล่านี้ แต่ postgreSQL จัดส่งพร้อมกับตัวเลือกที่มีประโยชน์มากกว่านี้

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

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

— Brian Ballsun-Stanton
แหล่งที่มา

คุณนอนหลับคุณไปแล้วและให้ Brian ตอบคำถาม ใช่ข้อกำหนดสำหรับ "การปรับปรุงออฟไลน์" เปลี่ยนแนวคิดทั้งหมดที่นั่นอย่างสมบูรณ์

— jcolebrand

Muahahahaah! :: ลูหนวดชั่ว ::

— ไบรอัน Ballsun-สแตนตัน

แม้จะใช้การเขียนแบบออฟไลน์ก็ตามก็สามารถใช้ INT ได้ เช่นใช้สองคอลัมน์{Node_ID, Item_ID}ที่แต่ละโหนดมีNode_IDและItem_IDที่เพิ่มขึ้นโดยอัตโนมัติต่อโหนด

— Jonas

@ Jonas ~ ใช่ว่าเป็นไปได้ อย่างไรก็ตามหนึ่งในเหตุผลที่คนส่วนใหญ่คิดว่า GUID นั้นสำหรับการจำลองแบบเนื้อหาที่แยกจากกันไปทั่วโลกไปยังฐานข้อมูลอื่น ฉันหมายถึงคำว่าตัวเองค่อนข้าง QED ที่นั่น

— jcolebrand

เกี่ยวกับสถาปัตยกรรมหลัก / ทาสหรือไคลเอนต์การเชื่อมต่อแบบกระจาย + สถาปัตยกรรมเซิร์ฟเวอร์หลักอาจเป็นไปได้ที่จะใช้ global_id (SERIAL) กับต้นแบบและ global_id (BIGINT) + local_id (SERIAL) บนทาส ทาสทำงานในพื้นที่ของตนโดยใช้ local_id และกระทำเมื่อพวกเขาสามารถเข้าหานายได้รับข้อมูลและมอบ global_id ซึ่งจะส่งกลับไปยังทาสทาสจะอัพเดทฟิลด์ global_id (เพื่อใช้อ้างอิงในการพูดคุยกับเซิร์ฟเวอร์หรืออื่น ๆ ทาส)

— Mihai Stancu

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

ตอนนี้ถ้าเรามองไปที่การรับรู้ฐานข้อมูลบางอย่าง: 1. ) MySQL - คีย์หลักถูกจัดกลุ่มโดยไม่มีตัวเลือกในการเปลี่ยนพฤติกรรม - การแนะนำใหม่ไม่ได้ใช้ GUID ทั้งหมดเลยที่นี่ 2. ) Postgres, MS-SQL - คุณสามารถทำให้ GUID เป็น คีย์หลักที่ไม่ได้ทำคลัสเตอร์และใช้ฟิลด์อื่นเป็นดัชนีแบบคลัสเตอร์เช่น autoincrement int

— Ross Ivantsiv
แหล่งที่มา

สิ่งที่คุณเสนอสำหรับ Postgres สามารถทำได้ใน MySQL เช่นกันด้วยโครงสร้างที่แตกต่างกันเล็กน้อย - auto_increment PK (คีย์คลัสเตอร์), GUID พร้อมดัชนีที่ไม่ซ้ำกัน (ไม่รวมกลุ่ม)

— ypercubeᵀᴹ

สิ่งนี้ไม่เป็นความจริงเสมอไป ขึ้นอยู่กับปริมาณงานของระบบดิสก์การซิงโครไนซ์การเข้าถึงหน้าสุดท้ายนั้นอาจเป็นคอขวดของคุณ blog.kejser.org/2011/10/05/…

— mwilson

"ต่างจาก Microsoft SQL Server การทำคลัสเตอร์ในดัชนีใน PostgreSQL ไม่รักษาลำดับนั้นคุณต้องนำกระบวนการ CLUSTER ไปใช้ใหม่เพื่อรักษาลำดับ" CLUSTER ON ปรับปรุงประสิทธิภาพดัชนีอย่างไร

— bartolo-otrit

รุ่นข้นมากขึ้นของข้อมูล @ Bartolo-otrit เชื่อมโยงกับ: stackoverflow.com/a/4796685/1394393 คำตอบนี้ดูเหมือนจะไม่เกี่ยวข้องกับฉันจริงๆเนื่องจากคำถามนี้เกี่ยวกับ PG และดูเหมือนว่าจะมีความคล้ายคลึงกับ SQL Server และ MySQL ที่ไม่มีอยู่

— jpmc26

database would need to rearrange all its memory pages to find the right place for insertion=> ฉันไม่คิดว่าเป็นกรณีของ Postgres เนื่องจากการทำคลัสเตอร์เป็นทางเลือกและแถวใหม่จะถูกจัดเก็บแบบไม่เรียงลำดับ

— Flavien

มันขึ้นอยู่กับ.

อย่างจริงจังกับทุกสิ่งที่คุณได้รับจนถึงตอนนี้เป็นเรื่องเกี่ยวกับเท่าที่คุณสามารถไป

ทำไมการใช้ UUID ถึงเป็นประโยชน์ ทำไมคุณไม่ใช้ INTs ทำไมคุณไม่สามารถจัดทำดัชนี UUID ในภายหลังได้ คุณเข้าใจหรือไม่ว่าการมีรายการที่เรียงลำดับด้วยคีย์ของ UUID และแทรก UUID แบบสุ่ม (ไม่เรียงลำดับ) หลังแถวสองสามล้านแถวหรือไม่

แพลตฟอร์มนี้จะทำงานอะไร ดิสก์กี่แผ่น มีผู้ใช้กี่คน? มีกี่ระเบียน

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

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

— Jonas

แอปพลิเคชันจะถูกเขียนใน Java และไคลเอนต์ที่ฉันใช้ Windows, Mac หรือ Linux ไคลเอนต์จะใช้คอมพิวเตอร์เดสก์ท็อปทั่วไปที่มักจะมีดิสก์หนึ่งแผ่น จำนวนผู้ใช้และบันทึกขึ้นอยู่กับจำนวนลูกค้าที่ฉันได้รับ แต่จะประมาณ 5000 ต่อลูกค้าและลูกค้า

— Jonas

ความคิดเห็นออฟไลน์เปลี่ยนแปลงทุกอย่าง ดูรายละเอียดเพิ่มเติมว่าทำอะไร?

— jcolebrand