[1] https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo...
[2] https://softwareengineering.stackexchange.com/questions/4955...
My point is more to do with the fact that BigCache does not handle collisions at all, whereas the built in Go `map` almost certainly does.
Essentially, I can imagine that a Jepsen-like test would reveal that BigCache loses some percentage of writes (dependent on the data, of course).
Whether or not that is a problem depends entirely on your use case, of course.
This property makes BigCache what is known as a "Direct-mapped cache"[0]. A direct mapped cache does lead to a worse cache hit rate, but it does make determining whether there is a cache hit or miss a lot faster. I would need to see benchmarks to tell which is better in practice.
[0] https://en.wikipedia.org/wiki/Cache_placement_policies#Direc...
Seems like this would always be undesirable behavior for a cache?
It is definitely being advertised as a map-like structure, key goes in, bytes come out...
Update:
Yes, that appears to be the strategy in shard.go.
if entryKey := readKeyFromEntry(wrappedEntry); key != entryKey {
s.lock.RUnlock()
s.collision()
if s.isVerbose {
s.logger.Printf("Collision detected. Both %q and %q have the same hash %x", key, entryKey, hashedKey)
}
return nil, ErrEntryNotFound
}
> BigCache does not handle collisions. When new item is inserted and it's hash collides with previously stored item, new item overwrites previously stored value.