Apa jenis kolom UUID yang paling efisien

15

Untuk menyimpan UUID 128 bit, ada beberapa opsi penyimpanan:

kolom byte [16]
dua kolom bigint / long (64 bit)
a CHAR (36) kolom - 32 digit hex + 4 strip.
kolom khusus basis data UUID, jika db mendukungnya

Dari sudut pandang pengindeksan mana yang paling efisien? Jika db tidak mendukung tipe uuid khusus, manakah dari 1, 2, 3 yang merupakan kandidat terbaik?

— Vlad Mihalcea
sumber

1

Ini agak terlalu "tergantung" - banyak implementasi spesifik.

— Craig Ringer

2

Saya tidak akan pernah memilih 3: tidak pernah menyimpan sesuatu dalam 36 byte ketika itu bisa dilakukan di 16. Saya menggunakan raw(16)di Oracle dan uuiddi PostgreSQL.

— Colin 't Hart

1

semakin sederhana semakin baik.

— akuzminsky

uuid>> bytea>> textdengan CHECKkendala> varchar(36)>> char(36). Lihat: dba.stackexchange.com/a/89433/3684 dan dba.stackexchange.com/a/115316/3684 .

— Erwin Brandstetter

15

uuidJenis khusus adalah taruhan terbaik Anda untuk PostgreSQL. Sulit dikatakan dengan DB lain - bukan tidak mungkin bagi seseorang untuk memaksakan uuidjenis yang disimpan kurang efisien daripada jenis byte sederhana.

Sekali lagi di PostgreSQL, byteaakan menjadi cara yang masuk akal untuk menyimpan UUID jika Anda tidak memiliki uuidtipenya. Untuk DB lain tergantung pada bagaimana mereka menyimpan data biner.

Jika memungkinkan saya akan sangat menghindari menggunakan hex-with-strip. Cara ini kurang efisien untuk membandingkan, mengurutkan, dan menyimpan.

Jadi sungguh, "tidak (2) atau (3)". Pernah. Gunakan (4) jika didukung, (1) sebaliknya.

— Craig Ringer
sumber

Satu hal yang perlu diperhatikan adalah bahwa jenis UUID PostgreSQL tidak didukung secara asli dalam array atau sudahkah ini diperbaiki? postgresql.org/message-id/…

— Christophe Roussy

@ChristopheRoussy Itu dari 2013. Itu adalah pengawasan kecil. SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]

— Craig Ringer

3

Dalam urutan preferensi: 4,1,2,3 Jangan gunakan UUID sebagai kunci pengelompokan jika menggunakan SQL server, tidak hanya akan terpecah-pecah, kunci pengelompokan digunakan di semua indeks yang tidak dikelompokkan dan Anda akan menambahkan byte tersebut ke setiap baris indeks. Fragmentasi dapat dikurangi dengan menggunakan NEWSEQUENTIALID tetapi biasanya lebih memilih identitas bingint untuk Kunci Clustering Anda daripada GUID untuk mencegah mengasapi indeks lainnya.

Perbedaan antara memilih 1 dari 2 akan bergantung pada seberapa efisien database menangani dua kolom tipe dasar dari satu array tetap kolom. Seharusnya cukup mudah untuk menguji dengan data dummy. Lihatlah kecepatan kueri Anda serta ukuran indeks dan data. Kecil + cepat adalah yang terbaik!

— GilesDMiddleton
sumber

1

Orang harus mengira bahwa setiap tipe data yang didukung secara native akan lebih optimal dalam produk daripada apa pun yang dapat disatukan sebagai klien dari produk itu. Setelah itu, apa pun yang memiliki jumlah byte terkecil sehingga Anda mendapatkan baris maksimum per halaman.

— Michael Green
sumber

Benar, tetapi apakah hanya ukuran byte yang penting? Tidakkah tipe itu memengaruhi algoritma pengindeksan?

— Vlad Mihalcea

@ Vlad saya menggunakan SQL Server. AFAIK semua tipe data ditangani sama ketika membangun B-tree (atau indeks hash untuk 2104 di memori). Ada alasan bagus untuk menjaga ini sesempit mungkin.

— Michael Green