Timeline for Avoid Storing Keys in Key-Value Store by Replacing the Key with 128-bit Murmur3 Hash
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 18, 2021 at 4:40 | comment | added | rici | It's a simple consequence of how hashing has to work if it is going to do a good job. It's not saying anything different from your point 6; similar keys have different hashes. | |
| Jun 18, 2021 at 2:29 | comment | added | ultimate cause | @rici "because strings in the same hash set typically differ in the first few bytes." ... This is some thing I was not aware of. Can you please point me to any reference on this? | |
| Jun 18, 2021 at 2:27 | comment | added | ultimate cause | @rici Thanks for the alert. +1 | |
| Jun 16, 2021 at 18:47 | answer | added | D.W.♦ | timeline score: 1 | |
| Jun 16, 2021 at 16:18 | comment | added | rici | I don't think this is an appropriate place to ask this question. It strikes me as more appropriate for Software Engineering, although I don't hang out there so I don't really know what their criteria are. From a theoretical point of view, hash collisions are always possible, and if the consequences are sufficiently severe then saying "it's very unlikely" may not be a sufficient safeguard. From a more practical POV, memcmp will practically never take more time than a single-word comparison precisely because strings in the same hash set typically differ in the first few bytes. | |
| Jun 16, 2021 at 15:35 | history | edited | ultimate cause |
edited tags
|
|
| Jun 16, 2021 at 11:30 | history | asked | ultimate cause | CC BY-SA 4.0 |