Kapan Anda benar-benar dipaksa untuk menggunakan UUID sebagai bagian dari desain?


123

Saya tidak begitu mengerti maksud UUID . Saya tahu kemungkinan tabrakan secara efektif nol , tetapi secara efektif nol bahkan tidak mendekati tidak mungkin.

Adakah yang bisa memberi contoh di mana Anda tidak punya pilihan selain menggunakan UUID? Dari semua penggunaan yang pernah saya lihat, saya bisa melihat desain alternatif tanpa UUID. Tentu desainnya mungkin sedikit lebih rumit, tetapi setidaknya tidak memiliki kemungkinan kegagalan yang tidak nol.

UUID berbau seperti variabel global bagi saya. Ada banyak cara variabel global membuat desain yang lebih sederhana, tapi itu hanya desain malas.


23
Semuanya memiliki kemungkinan gagal yang bukan nol. Saya akan berkonsentrasi pada masalah yang jauh lebih mungkin terjadi (yaitu hampir semua yang dapat Anda pikirkan) daripada tabrakan UUID
DanSingerman

16
Sebenarnya, "efektif nihil" hampir tidak mungkin.
mqp

21
Tidak, ini sebenarnya jauh dari tidak mungkin
Pyrolistik

32
@Pyrolistik ketika Anda mulai mengucapkan kata-kata seperti "tak terbatas", Anda telah meninggalkan dunia pengembangan perangkat lunak. Teori ilmu komputer adalah diskusi yang sama sekali berbeda dari menulis perangkat lunak nyata.
Rex M

2
Saya akan menutup sebagian besar karena git's sha1 telah meyakinkan saya tentang kebaikan hash
Pyrolistic

Jawaban:


617

Saya menulis generator / parser UUID untuk Ruby, jadi saya menganggap diri saya cukup mendapat informasi tentang subjek tersebut. Ada empat versi UUID utama:

Versi 4 UUID pada dasarnya hanya 16 byte keacakan yang ditarik dari generator nomor acak yang aman secara kriptografis, dengan beberapa bit-twiddling untuk mengidentifikasi versi dan varian UUID. Ini sangat tidak mungkin untuk bertabrakan, tetapi itu bisa terjadi jika PRNG digunakan atau jika Anda kebetulan memiliki keberuntungan yang sangat, sangat, sangat, sangat, sangat buruk.

UUID Versi 5 dan Versi 3 masing-masing menggunakan fungsi hash SHA1 dan MD5, untuk menggabungkan namespace dengan bagian data yang sudah unik untuk menghasilkan UUID. Ini akan, misalnya, memungkinkan Anda menghasilkan UUID dari URL. Tabrakan di sini hanya mungkin jika fungsi hash yang mendasarinya juga memiliki tabrakan.

UUID versi 1 adalah yang paling umum. Mereka menggunakan alamat MAC kartu jaringan (yang kecuali dipalsukan, harus unik), ditambah stempel waktu, ditambah bit-twiddling biasa untuk menghasilkan UUID. Dalam kasus mesin yang tidak memiliki alamat MAC, 6 node byte dihasilkan dengan generator nomor acak yang aman secara kriptografis. Jika dua UUID dibuat secara berurutan cukup cepat sehingga stempel waktu cocok dengan UUID sebelumnya, stempel waktu akan bertambah 1. Tabrakan seharusnya tidak terjadi kecuali salah satu hal berikut terjadi: Alamat MAC dipalsukan; Satu mesin yang menjalankan dua aplikasi penghasil UUID yang berbeda menghasilkan UUID pada saat yang sama; Dua mesin tanpa kartu jaringan atau tanpa akses tingkat pengguna ke alamat MAC diberi urutan node acak yang sama, dan menghasilkan UUID pada saat yang sama;

Secara realistis, tidak satu pun dari peristiwa ini terjadi secara tidak sengaja dalam satu ruang ID aplikasi. Kecuali Anda menerima ID pada, katakanlah, dalam skala luas Internet, atau dengan lingkungan tidak tepercaya di mana individu jahat mungkin dapat melakukan sesuatu yang buruk jika terjadi benturan ID, itu bukan sesuatu yang perlu Anda khawatirkan. Sangat penting untuk memahami bahwa jika Anda membuat versi 4 UUID yang sama seperti yang saya lakukan, dalam banyak kasus, itu tidak masalah. Saya telah membuat ID di ruang ID yang sama sekali berbeda dari Anda. Aplikasi saya tidak akan pernah tahu tentang tabrakan jadi tabrakan itu tidak masalah. Terus terang, dalam satu ruang aplikasi tanpa aktor jahat, kepunahan semua kehidupan di bumi akan terjadi jauh sebelum Anda bertabrakan, bahkan pada UUID versi 4, bahkan jika Anda '

Selain itu, 2 ^ 64 * 16 adalah 256 exabyte. Seperti halnya, Anda perlu menyimpan ID senilai 256 exabyte sebelum Anda memiliki peluang 50% dari benturan ID dalam satu ruang aplikasi.


8
Sejauh ini, inilah penjelasan terbaik. Saya tidak tahu mengapa ini tidak dipilih menjadi yang teratas. Kudos to you Sporkmonger.
Brad Barker

1
@Chamnap Saya menulis UUIDTools. UUID dapat diubah menjadi integer atau bentuk byte mentahnya, dan akan jauh lebih kecil sebagai biner.
Bob Aman

1
@Chamnap uuid.rawakan memberi Anda string byte. The hashMetode ini tidak berguna bagi Anda. Ini digunakan untuk tabel hash dan operasi perbandingan secara internal di dalam Ruby. Semua metode untuk mengonversi ke dan dari berbagai representasi UUID didefinisikan sebagai metode kelas dan harus diawali dengan "parse".
Bob Aman

3
@BobAman pada tahun 1990 Saya mengalami 12 tabrakan UUID pada sistem Aegis, ternyata FPU yang salah, tetapi saya pikir saya akan memberi tahu Anda bahwa itu bisa terjadi (belum pernah terjadi selain itu dalam 30+ tahun terakhir pemrograman) . Penjelasan yang bagus, juga btw, ini sekarang defacto UUID refence post untuk diberikan kepada orang :)
GMasucci

2
@kqr Anda benar sekali bahwa itu masalah ulang tahun, namun untuk kode n-bit, masalah paradoks ulang tahun berkurang menjadi 2 ^ (n / 2), yang dalam hal ini adalah 2 ^ 64, seperti yang dinyatakan dalam jawaban saya .
Bob Aman

69

Hal yang sangat sulit dilakukan UUID untuk Anda lakukan sebaliknya adalah mendapatkan pengenal unik tanpa harus berkonsultasi atau berkoordinasi dengan otoritas pusat . Masalah umum untuk bisa mendapatkan hal seperti itu tanpa semacam infrastruktur yang dikelola adalah masalah yang dipecahkan UUID.

Saya telah membaca bahwa menurut paradoks ulang tahun, kemungkinan tabrakan UUID terjadi adalah 50% setelah 2 ^ 64 UUID dibuat. Sekarang 2 ^ 64 adalah angka yang cukup besar, tetapi peluang tabrakan 50% tampaknya terlalu berisiko (misalnya, berapa banyak UUID yang perlu ada sebelum ada peluang tabrakan 5% - bahkan kemungkinan itu tampak terlalu besar) .

Masalah dengan analisis itu ada dua:

  1. UUID tidak sepenuhnya acak - ada komponen utama UUID yang berbasis waktu dan / atau lokasi. Jadi agar memiliki peluang nyata untuk bertabrakan, UUID yang bertabrakan harus dibuat pada saat yang sama dari generator UUID yang berbeda. Saya akan mengatakan bahwa meskipun ada kemungkinan yang masuk akal bahwa beberapa UUID dapat dibuat pada saat yang sama, ada cukup banyak gunk lain (termasuk info lokasi atau bit acak) untuk membuat kemungkinan tabrakan antara set UUID yang sangat kecil ini hampir mustahil. .

  2. tegasnya, UUID hanya perlu unik di antara serangkaian UUID lain yang dapat dibandingkan. Jika Anda membuat UUID untuk digunakan sebagai kunci database, tidak masalah jika di tempat lain di alam semesta alternatif yang jahat UUID yang sama digunakan untuk mengidentifikasi antarmuka COM. Sama seperti itu tidak akan menimbulkan kebingungan jika ada seseorang (atau sesuatu) lain bernama "Michael Burr" di Alpha-Centauri.


1
Contoh konkrit? COM / DCE UUIDs - tidak ada otoritas untuk menugaskan mereka, dan tidak ada yang mau mengambil tanggung jawab dan / atau tidak ada yang ingin ada otoritas. Basis data terdistribusi yang tidak memiliki tautan andal dan tanpa master.
Michael Burr

3
Contoh yang lebih konkret - aplikasi perbankan. Itu dipasang beberapa pusat data, satu untuk setiap negara, dengan setiap pusat data memiliki DB. Berbagai instalasi ada untuk mematuhi peraturan yang berbeda. Hanya boleh ada satu catatan pelanggan di seluruh rangkaian untuk setiap pelanggan .....
Vineet Reynolds

(Kelanjutan dari komentar sebelumnya) Anda harus memiliki server pusat untuk menghasilkan ID pelanggan untuk tujuan pelaporan dan pelacakan keseluruhan (di semua instalasi) atau meminta instalasi individu menghasilkan UUID untuk berfungsi sebagai ID pelanggan (jelas UUID tidak dapat digunakan seperti pada dalam laporan).
Vineet Reynolds

Pada saat Anda memiliki peluang duplikasi 50%, Anda sudah tenggelam. Seseorang menunjukkan volume yang dibutuhkan untuk mendapatkan peluang 0,0000001%. Beberapa database auto-increment mulai dari 1 hingga n dan meningkat n setiap kali menyelesaikan masalah yang sama secara efektif.
Gordon

2
Peluang mendapatkan duplikat JAUH, JAUH lebih rendah daripada kemungkinan otoritas pusat gagal dalam beberapa cara kritis-misi
std''OrgnlDave

33

Semuanya memiliki kemungkinan gagal yang bukan nol. Saya akan berkonsentrasi pada masalah yang jauh lebih mungkin terjadi (yaitu hampir semua hal yang dapat Anda pikirkan) daripada benturan UUID


Ditambahkan sebagai jawaban atas permintaan Pyrolistic
DanSingerman

16

Penekanan pada "masuk akal" atau, seperti yang Anda katakan, "efektif": cukup baik adalah bagaimana dunia nyata bekerja. Jumlah pekerjaan komputasi yang terlibat dalam menutupi kesenjangan antara "unik secara praktis" dan "benar-benar unik" sangatlah besar. Keunikan adalah kurva dengan hasil yang semakin berkurang. Di beberapa titik di kurva itu, ada garis antara di mana "cukup unik" masih terjangkau, dan kemudian kami melengkung SANGAT curam. Biaya penambahan lebih banyak keunikan menjadi cukup besar. Keunikan yang tidak terbatas memiliki biaya yang tidak terbatas.

UUID / GUID, secara relatif, adalah cara komputasi yang cepat dan mudah untuk menghasilkan ID yang secara wajar dapat dianggap unik secara universal. Ini sangat penting dalam banyak sistem yang perlu mengintegrasikan data dari sistem yang sebelumnya tidak terhubung. Misalnya: jika Anda memiliki Sistem Manajemen Konten yang berjalan pada dua platform berbeda, tetapi pada titik tertentu perlu mengimpor konten dari satu sistem ke sistem lainnya. Anda tidak ingin ID berubah, jadi referensi Anda antara data dari sistem A tetap utuh, tetapi Anda tidak ingin ada benturan dengan data yang dibuat di sistem B. UUID menyelesaikan ini.


Larutan. Jangan malas dan update referensinya. Lakukan dengan benar.
Pyrolistik

8
Ini tidak ada hubungannya dengan kemalasan - jika kebijakannya adalah bahwa ID untuk item dianggap permanen dan tidak dapat diubah, maka ID tersebut tidak berubah. Jadi, Anda ingin ID menjadi unik sejak awal, dan Anda ingin melakukannya tanpa memerlukan semua sistem untuk dihubungkan dari awal.
Michael Burr

Anda membutuhkan konteks. Jika Anda memiliki dua grup ID unik yang mungkin bentrok, Anda memerlukan konteks tingkat tinggi untuk memisahkannya
Pyrolistik

23
Atau, Anda bisa membangun sistem untuk menggunakan UUID dan mengirimkannya, menjualnya, menghasilkan jutaan dolar dan tidak pernah mendengar satu keluhan pun bahwa dua ID bertabrakan karena itu tidak akan terjadi.
Rex M

16

UUID tidak pernah mutlak diperlukan. Namun nyaman untuk memiliki standar di mana pengguna offline masing-masing dapat menghasilkan kunci untuk sesuatu dengan kemungkinan tabrakan yang sangat rendah.

Ini dapat membantu dalam resolusi replikasi database dll ...

Akan mudah bagi pengguna online untuk menghasilkan kunci unik untuk sesuatu tanpa overhead atau kemungkinan tabrakan, tetapi UUID bukan untuk itu.

Bagaimanapun, sebuah kata tentang kemungkinan tabrakan, diambil dari Wikipedia:

Untuk menempatkan angka-angka ini ke dalam perspektif, risiko tahunan seseorang terkena meteorit diperkirakan satu peluang dalam 17 miliar, setara dengan peluang menciptakan beberapa puluh triliun UUID dalam setahun dan memiliki satu duplikat. Dengan kata lain, hanya setelah menghasilkan 1 miliar UUID setiap detik selama 100 tahun ke depan, kemungkinan membuat hanya satu duplikat akan menjadi sekitar 50%.


4
Sederhana, jangan biarkan pengguna offline menghasilkan kunci. Minta kunci sementara ditetapkan sampai sistem online sehingga kunci sebenarnya dapat dibuat.
Pyrolistik

Ini adalah jawaban yang sangat membantu menurut saya ... akan menawarkan semacam analogi dengan probabilitas saya sendiri, karena tampaknya OP tidak cukup memahami artinya, tetapi Anda tampaknya telah melakukannya.
Noldorin

Saya mengerti bahwa probabilitasnya secara efektif nol. Bagi saya penggunaan UUID adalah desain yang malas, dan saya hanya ingin melihat apakah Anda selalu dapat menghindarinya
Pyrolistik

Itu cukup adil, selama Anda melihat bahwa probabilitas rendah bahkan perlu dipertimbangkan dalam keadaan yang paling ekstrim, seperti yang sekarang saya anggap demikian.
Noldorin

13

Contoh klasik adalah saat Anda mereplikasi antara dua database.

DB (A) memasukkan record dengan int ID 10 dan pada saat yang sama DB (B) membuat record dengan ID 10. Ini adalah collision.

Dengan UUID, hal ini tidak akan terjadi karena tidak cocok. (hampir pasti)


1
Ok, selanjutnya buat DB A pakai ID genap dan DB B pakai ID ganjil. Selesai, tidak ada UUID.
Pyrolistik

2
Dengan tiga DB, gunakan 3 kelipatan LOL
Jhonny D. Cano -Leftware-

20
Jika Anda menggunakan kelipatan 2/3 / berapapun, apa yang terjadi saat Anda menambahkan server baru ke dalam campuran nanti? Anda harus mengoordinasikan sakelar sehingga Anda menggunakan kelipatan n + 1 di server baru, dan memindahkan semua server lama ke algoritme baru, dan Anda harus mematikan semuanya saat Anda melakukan ini untuk menghindari tabrakan selama saklar algoritma. Atau ... Anda bisa menggunakan UUID seperti SEMUA ORANG LAIN.
Bob Aman

3
Ini bahkan lebih buruk dari itu, karena bagaimana Anda akan membedakan antara kelipatan 2 dan kelipatan 4? Atau kelipatan 3 vs. kelipatan 6? Faktanya, Anda harus tetap menggunakan kelipatan bilangan prima. Blech! Cukup gunakan UUID, itu berhasil. Microsoft, Apple, dan banyak lainnya mengandalkan mereka dan mempercayai mereka.
sidewinderguy

2
@sidewinderguy, di GUID kami percaya! :)
Ron Klein

13

Ada juga kemungkinan bukan nol bahwa setiap partikel dalam tubuh Anda secara bersamaan akan menembus kursi yang Anda duduki dan Anda akan tiba-tiba mendapati diri Anda duduk di lantai.

Apa kamu khawatir tentang itu?


7
Tentu saja tidak, itu bukan sesuatu yang bisa saya kendalikan, tapi desain yang saya bisa.
Pyrolistik

4
@Pyrolistik Benarkah itu , maksud saya BENAR-BENAR alasan Anda tidak khawatir tentang itu? Maka Anda cukup aneh. Dan terlebih lagi, Anda tidak benar. Anda bisa mengontrolnya. Jika berat badan Anda bertambah beberapa kilogram, Anda secara signifikan mengurangi kemungkinan terjadinya peristiwa semacam itu. Apakah Anda menganggap Anda harus menambah berat badan? :-)
Veky

8

Saya memiliki skema untuk menghindari UUID. Siapkan server di suatu tempat dan miliki sehingga setiap kali beberapa perangkat lunak menginginkan pengenal unik universal, mereka menghubungi server itu dan memberikannya. Sederhana!

Kecuali bahwa ada beberapa masalah praktis yang nyata dengan ini, bahkan jika kita mengabaikan niat jahat. Secara khusus, server tersebut dapat gagal atau menjadi tidak dapat dijangkau dari bagian internet. Berurusan dengan kegagalan server membutuhkan replikasi, dan itu sangat sulit untuk dilakukan dengan benar (lihat literatur tentang algoritma Paxos tentang mengapa membangun konsensus itu canggung) dan juga sangat lambat. Selain itu, jika semua server tidak dapat dijangkau dari bagian tertentu dari 'net, tidak ada klien yang terhubung ke subnet tersebut yang dapat melakukan apa pun karena mereka semua akan menunggu ID baru.

Jadi ... gunakan algoritme probabilistik sederhana untuk menghasilkannya yang tidak mungkin gagal selama masa Bumi, atau (mendanai dan) membangun infrastruktur utama yang akan menjadi penerapan PITA dan sering mengalami kegagalan. Saya tahu yang mana yang akan saya pilih.


2
Sebenarnya, inti dari penemuan UUID adalah untuk menghindari pendekatan Anda. Jika Anda meneliti sejarah UUID, Anda akan melihatnya berasal dari eksperimen paling awal dalam membuat jaringan komputer yang canggih dan bermakna. Mereka tahu bahwa jaringan secara inheren tidak dapat diandalkan dan rumit. UUID adalah jawaban atas pertanyaan tentang bagaimana mengkoordinasikan data antar komputer ketika Anda tahu mereka tidak dapat terus berkomunikasi.
Basil Bourque

7
@BasilBourque Saya menggunakan sarkasme di paragraf pertama, kalau-kalau tidak jelas.
Donal Fellows

5

saya tidak mendapatkan semua pembicaraan tentang kemungkinan tabrakan. Saya tidak peduli tentang tabrakan. Saya peduli dengan kinerja.

https://dba.stackexchange.com/a/119129/33649

UUID adalah bencana kinerja untuk tabel yang sangat besar. (200 ribu baris tidak "sangat besar".)

# 3 Anda benar-benar buruk ketika CHARCTER SET adalah utf8 - CHAR (36) menempati 108 byte!

UUID (GUID) sangat "acak". Menggunakannya sebagai kunci UNIK atau UTAMA pada tabel besar sangat tidak efisien. Ini karena harus melompat-lompat di sekitar tabel / indeks setiap kali Anda MEMASUKKAN UUID baru atau PILIH oleh UUID. Ketika tabel / indeks terlalu besar untuk dimasukkan ke dalam cache (lihat innodb_buffer_pool_size, yang harus lebih kecil dari RAM, biasanya 70%), UUID 'berikutnya' mungkin tidak di-cache, oleh karena itu hit disk lambat. Ketika tabel / indeks 20 kali lebih besar dari cache, hanya 1/20 (5%) dari klik yang di-cache - Anda terikat I / O.

Jadi, jangan gunakan UUID kecuali salah satunya

Anda memiliki tabel "kecil", atau Anda benar-benar membutuhkannya karena menghasilkan id unik dari tempat yang berbeda (dan belum menemukan cara lain untuk melakukannya). Lebih lanjut tentang UUID: http://mysql.rjweb.org/doc.php/uuid (Ini mencakup fungsi untuk mengubah antara UUID 36-karakter standar dan BINARY (16).)

Memiliki AUTO_INCREMENT UNIK dan UUID UNIK dalam tabel yang sama adalah pemborosan.

Ketika INSERT terjadi, semua kunci unik / primer harus diperiksa untuk duplikat. Salah satu kunci unik cukup untuk persyaratan InnoDB untuk memiliki KUNCI UTAMA. BINARY (16) (16 bytes) agak besar (argumen untuk tidak menjadikannya PK), tapi tidak terlalu buruk. Bulkiness penting jika Anda memiliki kunci sekunder. InnoDB diam-diam memasang PK ke ujung setiap kunci sekunder. Pelajaran utama di sini adalah meminimalkan jumlah kunci sekunder, terutama untuk tabel yang sangat besar. Sebagai perbandingan: INT UNSIGNED berukuran 4 byte dengan range 0..4 milyar. BIGINT berukuran 8 byte.


4

Jika Anda hanya melihat alternatifnya, misalnya untuk aplikasi database sederhana, harus menanyakan database setiap kali sebelum Anda membuat objek baru, Anda akan segera menemukan bahwa menggunakan UUID secara efektif dapat mengurangi kompleksitas sistem Anda. Diberikan - jika Anda menggunakan kunci int are 32bit, yang akan disimpan dalam seperempat dari 128bit UUID. Diberikan - Algoritme pembuatan UUID membutuhkan lebih banyak daya komputasi daripada sekadar menaikkan angka. Tapi siapa peduli? Overhead mengelola "otoritas" untuk menetapkan nomor unik dengan mudah melebihi urutan besarnya, tergantung pada ruang ID keunikan yang Anda inginkan.


3

Pada UUID == desain malas

Saya tidak setuju ini tentang memilih perkelahian Anda. Jika UUID duplikat secara statistik tidak mungkin dan matematika terbukti, lalu mengapa khawatir? Menghabiskan waktu merancang sistem penghasil N UUID kecil Anda tidak praktis, selalu ada lusinan cara lain untuk meningkatkan sistem Anda.


1

Pada pekerjaan terakhir saya, kami mendapatkan objek dari pihak ketiga yang secara unik diidentifikasi dengan UUID. Saya memasukkan UUID-> tabel pencarian integer panjang dan menggunakan integer panjang sebagai kunci utama saya karena cara itu lebih cepat.


Ya tentu, pihak ketiga yang memaksa Anda menggunakan UUID adalah masalah lain yang tidak ingin saya bahas. Dengan asumsi Anda memiliki kendali untuk menggunakan UUID atau tidak.
Pyrolistik

Nah, "bilangan bulat panjang" (128 bit) sebenarnya adalah UUID. Itu hanya ditampilkan sebagai string untuk konsumsi manusia. Kadang-kadang dapat dikirim dengan cara itu, tetapi untuk penyimpanan dan pengindeksan pasti akan lebih cepat dalam bentuk integer seperti yang Anda temukan.
Nicole

1

Menggunakan algoritma versi 1 tampaknya tabrakan tidak mungkin terjadi di bawah batasan bahwa kurang dari 10 UUID per milidetik dihasilkan dari alamat MAC yang sama

Secara konseptual, skema generasi asli (versi 1) untuk UUID adalah untuk menggabungkan versi UUID dengan alamat MAC komputer yang menghasilkan UUID, dan dengan jumlah interval 100-nanodetik sejak adopsi kalender Gregorian di Barat. . Dalam prakteknya, algoritma sebenarnya lebih rumit. Skema ini telah dikritik karena tidak cukup 'buram'; ia mengungkapkan identitas komputer yang menghasilkan UUID dan waktu saat ia melakukannya.

Seseorang mengoreksi saya jika saya salah menafsirkan cara kerjanya


Ada banyak versi, dan banyak sistem perangkat lunak (Java misalnya) tidak dapat menggunakan versi 1 karena tidak memiliki cara Java murni untuk mengakses alamat mac.
Pyrolistik

Mengenai ketidakmampuan Java untuk mendapatkan alamat MAC: Tidak sepenuhnya benar. Ada solusi untuk ini. Anda dapat mengatur alamat MAC yang digunakan oleh generator secara manual melalui file konfigurasi. Anda juga dapat memanggil ifconfig dan mengurai hasilnya. Generator UUID Ruby yang saya tulis menggunakan kedua pendekatan tersebut.
Bob Aman

Juga, seperti yang disebutkan dalam jawaban saya, jika Anda tidak dapat memperoleh alamat MAC untuk UUID versi 1, Anda menggunakan 6 byte acak sebagai gantinya, sesuai bagian 4.5 dari RFC 4122. Jadi, meskipun Anda tidak ingin menggunakan salah satu dari dua solusi untuk Java, Anda masih dapat membuat UUID versi 1 yang valid.
Bob Aman

MS GUID hanyalah angka acak. Mereka tidak memiliki bagian MAC lagi, karena itu memungkinkan untuk merekayasa balik alamat MAC server (yang ternyata sangat berbahaya).
Stefan Steiger

1

Bagi mereka yang mengatakan bahwa UUID adalah desain yang buruk karena mereka dapat (dengan probabilitas yang sangat kecil) bertabrakan, sementara kunci yang dihasilkan DB Anda tidak akan ... Anda tahu kemungkinan kesalahan manusia yang menyebabkan tabrakan pada kunci yang dihasilkan DB Anda karena beberapa un -forseen kebutuhan JAUH JAUH lebih tinggi dari kemungkinan tabrakan UUID4. Kita tahu bahwa jika db dibuat ulang, itu akan memulai id pada 1 lagi, dan berapa banyak dari kita yang harus membuat ulang tabel ketika kita yakin kita tidak akan pernah membutuhkannya? Saya akan menaruh uang saya pada keamanan UUID ketika hal-hal mulai salah dengan yang tidak diketahui-tidak diketahui kapan saja.


0

Selain kasus di mana Anda harus menggunakan API orang lain yang menuntut UUID, tentunya selalu ada solusi lain. Tetapi apakah alternatif-alternatif itu akan menyelesaikan semua masalah yang dilakukan UUID? Apakah Anda akan menambahkan lebih banyak lapisan peretasan, masing-masing untuk memecahkan masalah yang berbeda, padahal Anda bisa menyelesaikan semuanya sekaligus?

Ya, secara teori UUID bisa bertabrakan. Seperti yang telah dicatat orang lain, itu sangat tidak mungkin sampai-sampai itu tidak layak dipertimbangkan. Itu tidak pernah terjadi sampai saat ini dan kemungkinan besar tidak akan pernah. Lupakan saja.

Cara yang paling "jelas" untuk menghindari benturan adalah dengan membiarkan satu server menghasilkan ID unik pada setiap penyisipan, yang jelas menciptakan masalah kinerja yang serius dan sama sekali tidak menyelesaikan masalah pembuatan offline. Ups.

Solusi "jelas" lainnya adalah otoritas pusat yang membagikan blok nomor unik terlebih dahulu, yang pada dasarnya adalah apa yang UUID V1 lakukan dengan menggunakan alamat MAC dari mesin pembangkit (melalui IEEE OUI). Tapi alamat MAC duplikat bisa terjadi karena setiap otoritas pusat pada akhirnya gagal, jadi dalam praktiknya ini jauh lebih mungkin daripada tabrakan UUID V4. Ups.

Argumen terbaik yang menentang penggunaan UUID adalah bahwa mereka "terlalu besar", tetapi skema yang (secara signifikan) lebih kecil pasti akan gagal untuk menyelesaikan masalah yang paling menarik; Ukuran UUID adalah efek samping yang melekat dari kegunaannya dalam menyelesaikan masalah tersebut.

Mungkin saja masalah Anda tidak cukup besar untuk membutuhkan apa yang ditawarkan UUID, dan dalam hal ini, silakan gunakan sesuatu yang lain. Tetapi jika masalah Anda tumbuh secara tidak terduga (dan sebagian besar terjadi), Anda akan beralih nanti - dan menyalahkan diri sendiri karena tidak menggunakannya sejak awal. Mengapa mendesain untuk kegagalan padahal semudah mendesain untuk sukses?


-10

UUID mewujudkan semua praktik pengkodean buruk yang terkait dengan variabel global, hanya lebih buruk lagi, karena mereka adalah variabel superglobal yang dapat didistribusikan ke berbagai bagian kit.

Baru-baru ini mengalami masalah seperti penggantian printer dengan model penggantian yang tepat, dan menemukan bahwa tidak ada perangkat lunak klien yang akan berfungsi.


2
Senang kita hidup dalam masyarakat yang masih berfokus pada fakta dan bukan opini acak, jika tidak, kita semua yang berada di tumpukan overflow akan kehilangan pekerjaan. :)
Makarand
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.