ID Resource, sebaiknya pakai GUID atau Sequential?

Saat membuat ID untuk mengidentifikasi resource tertentu secara unik, setahu saya umumnya ada dua pendekatan utama yang paling sering digunakan. Salah satunya adalah memakai nilai integer berurutan yang dihasilkan dengan memberi Auto Increment pada Primary Key tabel DB, dan yang lainnya adalah membuat lalu menggunakan GUID acak 128-bit (juga disebut UUID) setiap kali diperlukan.

Sebagian besar data dari banyak layanan yang kita lihat di web ditangani oleh RDBMS, dan Auto Increment pada DBMS semacam ini bukan hanya dioptimalkan secara internal, tetapi juga mudah dipahami dan diprediksi dari sudut pandang developer, serta sederhana untuk diurutkan berdasarkan urutan masuknya data. Karena pada dasarnya hanya menambahkan angka 1 setiap kali. Namun, metode ini punya kelemahan seperti dapat mengekspos informasi yang seharusnya tidak terlihat dari sisi keamanan dalam kasus tertentu (misalnya kompetitor bisa dengan mudah menebak metrik utama seperti jumlah pengguna layanan kita), atau dapat menimbulkan masalah dalam arsitektur terdistribusi.

Metode menggunakan GUID memiliki karakteristik yang justru kebalikan dari itu. Karena GUID adalah nilai 128-bit yang praktis unik dengan kemungkinan bentrok mendekati nol dan dapat dibuat kapan saja tanpa dependensi lain, pendekatan ini tidak menimbulkan masalah dalam arsitektur terdistribusi dan juga tidak berisiko membocorkan informasi bermakna lain ke luar. Namun, menulis nilai yang dibuat secara acak ke RDBMS bisa menurunkan performa, dan selain itu secara bawaan juga tidak mungkin mengurutkan data berdasarkan urutan masuknya. Untuk menutupi kelemahan ini, ada juga kasus penggunaan sesuatu seperti Timeflake, yang bukan sepenuhnya acak melainkan memuat informasi waktu sehingga memiliki sifat berurutan yang tidak sempurna. Saya sendiri belum pernah memakainya langsung, tetapi katanya framework seperti Laravel juga menggunakan pendekatan semacam ini.

Secara pribadi, karena di perusahaan tempat saya bekerja sekarang saya mengembangkan produk yang terintegrasi dengan hal-hal seperti Microsoft Office 365 atau Graph API yang aktif menggunakan GUID, saya jadi merasa pendekatan yang aktif menggunakan GUID juga cukup bagus. Namun pada akhirnya, hal seperti ini akan berbeda tergantung konteks penggunaan dan tujuannya, jadi penting untuk memahami dengan jelas kelebihan dan kekurangan masing-masing pendekatan. Karena itu, saya ingin memperkenalkan sebuah utas tweet yang berisi catatan harian seorang developer layanan fiktif terkait topik ini. (Bahasa Korea)

[kunggom]

Baru-baru ini terjadi insiden penyalahgunaan pada Shinhan Card, dan terkait hal ini terungkap adanya risiko bahwa perusahaan kartu tersebut dapat terekspos pada penyalahgunaan dari luar negeri karena nomor kartu kredit diterbitkan secara berurutan.
Hanya sedikit mengubah nomornya lalu bisa "membayar"… kartu kredit yang terekspos pencurian
Layanan Pengawasan Keuangan menyiapkan langkah penanganan terkait penyalahgunaan terbaru pada Shinhan Card, dll.

[kunggom]

Berkat banyak dari kalian yang meninggalkan komentar, saya jadi belajar banyak hal yang sebelumnya tidak saya ketahui.
Berkat itu, saya juga baru pertama kali mengetahui hal-hal seperti Hashids, Nano ID, dan cara yang digunakan Instagram.

[ehlegeth]

Motivasinya mungkin mirip dengan ulid, tetapi karena ada Internet Draft yang sedang diusulkan, saya pernah memakai spesifikasi ini di proyek sebelumnya.
https://github.com/uuid6/uuid6-ietf-draft

Skema ID yang dibuat dengan cara seperti ini cukup sering terlihat, dan sepertinya sekarang sudah saatnya setidaknya yang mirip UUID disatukan ke dalam satu standar.

[kunggom]

Tapi, upaya untuk membuat standar baru demi menyatukan standar-standar yang menjamur menjadi satu biasanya cuma menghasilkan satu kandidat pesaing baru di pasar. wkwkwk
https://xkcd.com/927/

[ehlegeth]

Betul, hehe, jadi sepertinya semua orang mengajukan usulan id baru.

[nallwhy]

Beberapa waktu lalu Gyuwon membagikan ini, tapi sebenarnya bukankah ini masalah yang sederhana?
https://byterot.blogspot.com/2013/02/…

[roxie]

Saya juga ingin penjelasan tambahan tentang maksud dari "masalah yang sederhana" itu.

[ehlegeth]

Dalam aspek apa Anda mengatakan ini adalah masalah yang sederhana?

Tulisan ini memang mengatakan, 'With storage nowadays very cheap, this normally is not a problem from the storage point of view.', tetapi ada situasi di mana ID ini harus beredar di jaringan, atau harus berperan sebagai key di memori, atau menjadi key yang dipakai di banyak tempat untuk data berukuran besar; dalam kasus seperti itu, mengurangi beberapa byte saja bisa menjadi penting, sehingga tampaknya ada juga situasi di mana UUID perlu ditolak tergantung konteksnya.

[nallwhy]

Masalah yang dibahas dalam tulisan ini adalah penurunan performa yang terjadi saat menggunakan nilai yang dibuat secara acak sebagai primary key
(jika ada masalah lain yang disebutkan tetapi saya tidak menangkapnya, mohon beri tahu)
Untuk masalah itu, jawabannya sebenarnya sudah ada. Ini masalah yang sama seperti saat melakukan cursor based pagination berdasarkan urutan waktu, jadi sepertinya semua orang sudah pernah menyelesaikannya.

[nallwhy]

Saya juga penasaran dari sisi apa ini dianggap sebagai masalah yang rumit.
Karena Anda mengatakan situasi yang disebutkan itu adalah situasi yang harus ditolak, rasanya ini seperti masalah yang sederhana...
Bukankah masalah yang rumit justru ketika kita tidak bisa mengambil keputusan ke mana pun?

[ehlegeth]

Saya bertanya karena makna dari 'masalah yang sederhana' bisa ditafsirkan dengan banyak cara, jadi saya penasaran Anda menggunakannya dalam arti yang mana. Apakah maksudnya masalahnya sendiri bukan masalah yang sulit, atau karena ada jawaban yang jelas (?) yang diajukan dalam tulisan sehingga ruang untuk mempertimbangkannya kecil, dan sebagainya.
Seperti yang saya katakan di atas untuk yang pertama, tergantung situasinya ada kasus di mana id juga harus berlaku di luar database, sehingga elemen yang perlu dipertimbangkan menjadi banyak dan saya rasa ini bukan masalah yang sederhana.

[yolatengo]

Di python/django ada juga yang seperti ini https://pypi.org/project/django-hashid-field/1.0.0/

[kunggom]

Oh, ternyata ada juga metode bernama Hashids.
Kalau salt bocor, memang bisa timbul masalah tereksposnya informasi ke pihak luar selain yang disebutkan di artikel utama di atas, tapi menurut saya ini tetap merupakan metode yang bagus.

[majorika]

Ada juga ulid. 128bit, bisa diurutkan berdasarkan waktu.
https://github.com/ulid/spec

[kunggom]

Kalau melihat begitu banyak hal yang bentuknya mirip-mirip, mungkin cara berpikir manusia pada dasarnya memang kurang lebih sama semua…?