有無較短, 而踫撞機率又相對較低既random key?

https://www.google.com.hk/search ... oq=uuid+alternative

https://www.google.com.hk/search ... oq=uuid+lightweight

搵左少少資料, 但無結果

128bit UUID的確係踫撞率好低, 但實在太低, 過晒頭

我希望條key可以短D, 足夠用就得, 10個char對我黎講已經好夠用, 甚至再短D, 32bit(8char)都夠晒

目前有咩algorithm既result短得黎, 離散度又夠高?

點解唔就咁random gen 8個[0-9A-Za-z_]char出黎?

TOP

點解唔就咁random gen 8個[0-9A-Za-z_]char出黎?
ykmran 發表於 2016-7-7 17:07



咁點樣可以係唔消耗大量space既情況下, make sure gen出黎既key踫撞率盡量低?

TOP

what is your purpose? use sha, md5 to hash a sequence number already able to generate a low collision key.

TOP

要Random 定 要Key?

via HKEPC Reader for Android

TOP

想要一個random string

關於話一般hash夠晒低
其實我簡單做過下依方面的research
其中一個result
https://www.zhihu.com/question/23940415

雖然唔知佢係咩hash, 但根據依個結果, 估計一般唔會理想

當然, 我會再搵多D資料, 睇下有無測試常見的32bit hash的離散程度如何

TOP

點解要random?,唔要random 嘅話用seq更好

如果真係要random
俾你用到32bit, 一條record慳左96bit,即係12個char...
要自己搞一餐,仲唔知會唔會有bug,你覺得抵唔抵?

另外,32 bit肯定唔夠,你睇返wiki birthday problem個table
如果你有5萬條records,有25%機會會有一個以上嘅Key 撞左...
而你慳左唔夠1MB

TOP

條key唔係用黎做id, 係比user用, 雖然唔係用黎比user記, 但正常一個人見到堆無意思既string, 10個位已經係極限, 再多會另人反感, 影響使用率

而我亦無預條key唔會撞, 本身其實就係預左重用都盡量唔會有問題
只係希望撞與撞之間既時間可以盡量耐D



而我所講既"唔消耗大量space", 唔係指儲data用既space, 而係gen key用既space
講真我可以由000...000 至 zzz...zzz, 將所有組合gen晒出黎, 然後撈亂佢地, 再逐個派, 咁就可以最大程度地保證離散度
但咁就要用space儲起晒依堆key, 又再maintain多一個table, 我想避免

TOP

回復 8 #3ldk

直接派咪算  random = 晒 gas

via HKEPC Reader for Android

TOP

回復 3ldk

直接派咪算  random = 晒 gas

via HKEPC Reader for Android
燕飛 發表於 2016-7-7 18:43



    http://cmc925.blogspot.hk/2013/07/blog-post_8.html
諗起為何造輪

講返正題, 我諗樓主唔想比人撞到個string, 所以唔順序派

TOP