Jangan Pake UUID di Database? | PZN Reaction
Vložit
- čas přidán 22. 08. 2024
- Jangan Pake UUID di Database? | PZN Reaction
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
CZcams : / programmerzamannow
Akhirnya ada yg bahas ini juga, kuncinya di:
- Pilih algoritma index yg cocok dengan pola query yg akan dipakai (umumnya B-tree vs Hash vs Full text)
- Kalau ga butuh urutan + B-tree, UUID v4 seharusnya ga masalah tapi mending by default selalu UUID v7 aja
- Opsi lainnya di self-defined smart ID, jadinya ID nggak bener2 meaningless dan bisa nyimpan beberapa informasi tanpa perlu lookup ke DB
memang uuid lebih boros tp jg solusi praktis kalo id harus digenerate di sisi client, misal untuk offline-first web app atau distributed system yg tidak mengharuskan full online
UUID secara underlying itu integer panjangnya 128 bit, yang ditampilkan itu 32 hex char nya.
Jadi udah sangat optimize UUID di database, syaratnya jangan simpan sebagai varchar tapi bener-bener tipe khusus UUID
jika di mysql versi 5 itu gimana tidak ada tipe data uuid? apa harus pakai auto increment?
@@putridefa2819 saya di production jarang pakai MySQL, tapi menurut docs resmi mysql disarankan pakai BINARY(16), select pakai BIN_TO_UUID(), insert pakai UUID_TO_BIN()
Saya tetap menggunakan ID int sbg primary key, sedangkan UUID itu hanya sbg attribute. Jadi ga kena indexing yang membuat performance turun.
UUID saya gunakan hanya mengkamuflase URL contoh /data/uuid-abc-eqwewqe
Jadi id aslinya terlindungi dari user yang ingin coba2.
Positipnya saat develop, querynya lebih cepat menggunakan ID daripada UUID
kenapa ga main encrypt decrypt aja a?
Saya baru mau adaptasi menggunakan cara mu juga @MrKeliv, minus nya yang kerasa apa ya bro selain memakan extra disk space karena ada 2 kolom?
kamuflase url ya mending pake kolom url_token generate string bisa 36 space 0-Z
@@uyosuryo629 akan jadi masalah kalo ada keperluan share link ke user lain
bener primary key memang seharusnya jangan pernah diekspose demi keamanan data, jadi keberadaan primary key ini lebih untuk keperluan relasi antar table
Waktu pertama belajar laravel , saya make kolom id dengan tipe data int sebagai primary key , namun data yang disebar ke luar itu menggunakan semacam slug,
Misalnya saya punya tabel animals
Kolomnya
1. Id int sebagai primary key
2. Slug text
3. Name varchar(255)
Nah misal saya punya halaman yang menampilkan informasi animals tertentu di halaman /animals/id akan diganti menjadi /animals/slug.
IMHO, slug tuh bagus buat SEO, untuk data-data seperti contoh artikel yang membutuhkan indexing di search engine. Tapi, kalau untuk case ini table animals atau table master lain seperti user, dll. ini kurang cocok untuk pakai slug. Efeknya juga karena ini random, seperti yang mas eko jelasin, storage juga lebih boros karena penggunaannya kurang cocok.
CMIIW
@@lobataros kayanya beda konteks deh, kalo di artikel casenya kolom sebagai primary key untuk index data di database. kalo slug biasanya cuma unique key. concern nya untuk store data pake UUIDv4 dibanding auto increment integer performance lebih lambat, dan kapasitas storage makan lebih banyak. perkara pake slug untuk url nya tetep bisa pakai query
Kalau di laravel ada key bawaan alternatif dari uuid yaitu ulid, dan ulid mirip uuidv7 dapat di urutkan
Baru tahu ada ulid, kukira uuid saja di laravel. Itu include semenjak laravel berapa?
Edited: setelah saya cek ada di laravel 9. Didalamnya inlcude package symfony/uid.
Bknnya ulid itu sebutan klo ada org yg suka asal komenin kehidupan org lain ya?
Itu sih julid, bisa aja lu bg wk@@masipul99
@@masipul99 julid itu bang hehehe
@@masipul99asik lu banh,,,
Asik sndiri
10:44 saya tunggu videonya pak eko
untuk laravel ^9.0 alternatif nya bisa dipakai ULID karena algoritma generate nya hampir sama dengan UUIDv7, dan bisa juga untuk di transform dari ULID (laravel) ke UUIDv7 (database)
Artikel nya hanya membicarakan kerugian UUID, gk bahas keuntungan UUID.
Point 2 sebenernya bukan kerugian, tapi trade-off.
Integer hanya support insert 2 triliun baris data, lebih dari itu bakal error.
UUID itu base16 (0-9, A-F), slotnya lebih banyak 60% daripada integer base10 (0-9) di size yang sama, kalo kamu somehow pengen 32-bit UUID.
Yang kedua, auto increment itu rawan mining data.
Item apa setelah id=10? Ya, id=11, dan selanjutnya pasti id=12.
Kalo pake UUID, satu data ketebak id-nya belum tentu data selanjutnya kena.
Problem dari tidak menerapkan UUID ini banyak aplikasi yg saya temui tidak secure, contoh nya rentan dari serangan IDOR, ditambah tidak ada validasi saat pengguna mengakses data tsb
Bener bang, kalo alasannya memberatkan database toh kolom kolom lain seperti username, email juga ga berurutan dan harus sering dilakukan balancing. Jadi kalo alasanya bikin berat database karena boros gak relevant. Saya pake UUID untuk menyembunyikan primary key bukan sebagai index. Karena idealnya primary key tidak untuk diekspose.
Untuk aplikasi offline, UUID sangat membantu ketika harus menggabungkan beberapa data dari device offline yang berbeda tanpa harus khawatir akan terjadi konflik dan saling klaim ID.
Saya udh berhenti pakai UUID v4 pak. Skrng sudah ada UUID v7 dimana id nya urut. Kalau di sort juga sesuai data keluar masuk. Udh tidak se random v4. Khusus postgres setau saya udh di optimal karena sortable
Malesnya pake auto increment raw adalah inconsistency length id pak. Kadang kita perlu convert id ke string. Kadang frondend lbih nyaman lempar uuid ktimbang id
@@bambanggunawanid163 bener bgt
@@bambanggunawanid163 kadang FE lebih nyaman lempar uuid ketimbang int id. Maksudnya gimana pak?
@@avgjoe3869 biasanya frontend ada validasi id json. Banyak yg pake zod type gitu. Klo pake id bisa di pasang uuid pasti 48 karakter misal. Dan string gitu. Instead auto inc pke number
Aku pake uuid cuma untuk field yang strukturnya array of objects, jadi cuma dipake untuk accessor key, juga dipake untuk generate id di sisi client jika ada form yg dynamic
pernah baca soal problem UUID ini. kalo backend dipegang sama beberapa pihak misalnya, memungkinkan UUID akan ada kesamaan dengan yang di local-server yang ada di kita. solusi simplenya, jangan store mentah" UUID yang kita kirim ke db (perlu adanya validasi). solusi selebihnya bisa pake cara kita sendiri yang lain
kalo uuid versi 4 harusnya dijamin unique walaupun di generate sama beda2 komputer dan waktu yang sama
Kuncinya adalah apakah sistem yang akan dibangun itu distributed atau nggak? kalo nggak distributed, regardles database nya pake apa, jangan pake UUID. Opsi lain bisa pake ULID.
13:38 Mantap pak eko. baru sadar selama ini pake BTree karena bawaan ketika save dan baru tau ada Hash. hehehe
baru aja kemarin baca itu eh udah di bahas disini, mantap panutan
loh cons nya ga disebut kah? kayak auto-increment lebih predicted sedangkan uuid lebih secure
kalau kebutuhannya aman dan performa bagus, bukannya bisa dengan pakai auto increment terus bikin logic backend-nya yg secure aja gitu ya?
Emang beresiko banget kah kalau kita pakai auto increment? Soalnya kalau aku liat Stackoverflow itu mereka pakai ID usernya juga angka dan kayaknya auto-increment juga.
aku biasa backend nya di hash / encript dengan key sendiri
@@masadamsahid nah bener tinggal pasang logic di BE nya
@@adawam4891 ya tapi kan yg kegenerate tetap random dan ga ngurut kan? kalo iya, berarti masih masuk cons yg disebut
Gua kurang setuju si, kalo mau aman mah tinggal maenin logic,seperti Komen diatas,biasa pas lakuin pentest Gini kita nyiapin 2 akun juga,meskipun make uuid yang ga keprediksi ya tetep itungannya vulnerability
Untuk urusan ID saya pakai TSID, kalau yg pakai java pasti udah familiar. Kalau yg pakai PHP bisa cobain odan TSID 👍
terimakasih pak eko, mantap pembahasan nya
pakai sequential uuid, store di db sebagai tipe uuid, jgn char / text
Pantesan waktu saya buat aplkasi pakai MERN itu nilai balikan cepet banget keluar. Saya pakai logic yg sama dengan Laravel dan MySQL UUIDv4 itu agak jauh time response nya.
saya pake uuid buat primkey di tabel sensitif kayak user, item dan transaction misalnya. selain itu masih okelah pake auto increament.
Kalaus saya pakai UUID untuk data yang sensitif banget seperti data user apalagi kalau primary keynya sering muncul di URL parameter, sisanya untuk data-data yang gak terlalu critical apalagi cuma jadi dependency doang pakenya auto increment.
kalo pake URL param bagusnya di encrypt juga pas ngirim IDnya biar ga kena Indirect Object Reference.
contoh encrptnya pake algo apa ya mas contohnya? dan bukannya nantinya dari sisi be harus decrypt yg akan mempengaruhi performance juga? dan kalo udh uuid seharusnya kan juga sudah susah ditebak karena characternya sangat random?
@@muhammadrizalrizkynaufal4559 UUID itu meskipun random tapi bisa kena langsung ke data reference.
Kalo mau di encrypt, table refresh_token tambah field 'url key' berupa symmetric encryption yang nanti dikasih ke client ketika mereka minta token, jadinya tiap JWT session key nya beda2.
Kalo mau lebih ribet lagi, pake double asymmetric key encryption.
1 set key untuk arah request (client -> server), 1 set key untuk arah responses (server -> client)
judul artikel click bait. conclusion-nya tidak selaras dengan judul 😁 thanks for sharing pak eko.
Pak eko, bahas2 tentang ml engineering dong pak dalam pengembangan software yg udh di production
kl pake integer, bisa ditebak2 dunk ID nya, tinggal diganti2 aja angka ny di url
gimana dgn penggunaan CUID bang?
seminggu kemarin baru baca article ini wkwkw
pernah case untuk bikin cron sync data ternyata primarynya pake UUID nah perlu disorting dulu, ternyata bisa di sorting, entah itu uuidv4 atau v7.
nanti saya coba pakai uuidv7 kalau ada case pake uuid lagi
kalo si sorting, pasti bisa, tapi maksudnya datanya unpredictable kalo uuidv4, bisa lebih besar, terus lebih kecil, jadi gak berurut kalo generate2 data
@@ProgrammerZamanNow oohh i see.. makasih kang
sudah waktunya id pake decimal/float
Gak juga, masih ada opsi uuid yang berurut
kalau uuid dibuat berurutan mjd sequence, apa bedanya sama tipe data int atau big int?
@@misakamikoto8312 uuid masih gak terprediksi karena generate string random..
Tetap susah ditebak sih klo mau ngakal"in, ga kek delete/1@@misakamikoto8312
@@misakamikoto8312 jadi point yang di bahas kan masalah peforma. Semakin banyak data di db, lalu saat ada proses insertion, itu jadi degradasi peforma karena algoritma yang digunakan b+ tree, karna ya emang dasarnya algoritma tersebut ga di desain untuk randomness kayak UUID v4. Kalo UUID v7 kan udh udh ngurut, walaupun dia generate key unique (random), tetapi ngurut (contoh sederhana: aa, ab, ac) begindang brodi
Sekarang diproject saya pakai nanoid, bahas juga nanoid pak .
menarik
Tapi kalo pake auto-increment performancenya lebih lambat gak ya dari sisi RDBMS? Karena DBMSnya harus make sure supaya ngga race condition gak sih? (mutex di variable sequencenya in case ada banyak connection ke DB yang melakukan operasi insert) Just wondering :/
kalo masih single master harusnya sama aja, tapi yang distributed db, kayaknya mereka gak punya fitur auto increment
aku sering pakainya cuid, secara jumlah karakter lebih singkat.
Pak eko, tolong bahas pake ULID Laravel dong
Buat algo indexing emang bisa milih ya?
Numpang nanya dong, terus kalau semisal kita nih sudah ngedevelop sebuah aplikasi dengan menggunakan UUID pada databasenya, dan semisal app nya sudah terlanjur ramai dan butuh scaling lagi, bisakah data data yang ada pada database tersebut kita migrasi ke database yang support auto increment, atau tidak bisa?
bisa
pak eko kapan update materi kelas android
doakan biar cepet selesai materinya
@@ProgrammerZamanNow aamiin pak😍
Salah memang karena menjadikan uuid sebagai key
Pake time unix nano aja
saya sering pake UUID tpi gk di jadikan primary key, cuma kalo pengen nyari data ke uuid
selama nyari pake operator equals, gak masalah harusnya
@@ProgrammerZamanNowklo ga dijadikan primary key atau tdk di index, bukannya akan scanning ke db nya perlu waktu khususnya yg sdh besar database nya?
nah iya, jadi si database bakal nyari line by line
jadi solusi nya gimana ya?
justru kalo ga jadi primarykey malah lebih lama querynya. Fungsi primarykey kan buat searching.
Programen india sering gunakan UUID
Setuju, ngapain uuid pakai btree kan ada hash
kalo kaya pembahasan ini, inituh namanya pembelajaran apasih? aku pgn cari tau di google best practice lainya pake metode2 selain btree dan cara jalan metode2 tersebut
itu struktur data
klo UUID ganti jadi hash aja deh
bagaimana dengan ULID?
kalau kasusnya di data lake kayak S3 (parquet, dll) pake UUID masih aman berarti ya, soalnya ga ada kendala insert performance.
harusnya itu cuma append aja kalo ke S3
a' kalo pake ulid gimana ?
uuid v7 solusinya hehe
Gue pke id biasa sama uuid di route key fine2 aja
Soal nya pas pake uuid hanya di route key aja
Kalo relasi ttp pake id auto increment
kalo di route pake auto increment id gak aman ya? harus di acak id nya agar aman kalo pake di route soalnya keliatan di url. begitu kah?
@@thaitea5399 iya supaya ga ketebak aja sih
gw banget
hampir salah bacang kang
jangan pake database
Kereen donk.. wkwk
Selain menggunakan UUID, ada cara lain untuk mengamankan biar tidak diketahui oleh org lain?
encrypt id
gmn kalo pake Snowflake ID pak eko? soalnya snowflake id ini bentuknya integer
bisa banget
Bagaimana kalau CUID bang?
Kalo ga pake id tapi gabungan beberapa kolom yang dijadiin primary key? Boleh gak pak?
tetep id kan, cuma composite id jadinya
pake bigint masih cukup :p, klo utk unique unpredictability pake slug
uuid 45
kalo untuk replikasi berarti perlu di akalin ya mas? pernah kejadian pake autoincrement di replikasi master to master dan akhirnya kena race condition, apa strategi replikasinya yang salah ya mas?
biasanya sih replica cuma nerima data dari master, agak aneh kalo replica nya malah bikin auto increment sendiri
@@ProgrammerZamanNow iya mas, jadi ada data yang di input dari beberapa region (karena ada policy yang mengharuskan servernya di region tertentu), karena autoincrementnya sering bentrok jadi diubah ke uuid tambah serverid biar masing2 ada indicator lokasi insert datanya
Artikelnya kurang nyampein alternatifnya, jadi bingung maksud authornya apa wkwk
mungkin emang pengen mencari keributan aja #eh
itu dia.
uuidv7: what
kalau cuid?
UUID bukanlah sebuah database, tetapi sebuah jenis pengidentifikasi unik yang sering digunakan di dalam database dan sistem lainnya. Mari kita perjelas perannya dalam konteks database dan data secara umum.
siapa yg bilang uuid sebuah database?
wkwk mak gw pun tau kalo uuid bukan database lol
@@yofiyonadio laahh mak lo kenapa jadi ngurusin uuid ?
Saya pake uuid supaya id data berikutnya ga mudah ditebak sama user.
emang kalo bisa ditebak kenapa? yang penting gak bisa diakses kan
@@ProgrammerZamanNow jadi meski pake autoincrement yang sequence yang mudah di tebak, yang penting harus di protect ya pak, jadi aman dan performa index oke
@@ProgrammerZamanNow iya sih. Hehe
kalo untuk aplikasi yang public itu emang harus concern ke penyajian dan security data yang dapat diakses tanpa auth. Gw pernah ngedump situs jual beli konten digital gitu, dimana file hosting yg mereka buat is just plain public endpoint with incremental id wkwk
@@ProgrammerZamanNowbetter safe than sorry, apalagi untuk sektor keuangan
Kalo ga pk uuid jait datanya bakal sulit
maksudnya jait apa ka? join table maksudnya ka?
@@vnoygotriz4877merger
:v
nonton doang like kagak
gak subscribe juga? parah
@@ProgrammerZamanNow wkwkwk
udah gw like itu.