Hacker News Reader

Comment by jitl | Hacker News Reader

That requires N times more memory, where N is the number of threads. 32x more memory??

Given the Zipf distribution, I wonder if just a small LRU cache per thread might not be a terrible thing?

Juggling caches on databases is a challenging thing, and there has been some back-and-forth on best practices. MySQL for the longest time shipped with a query cache. As of MySQL 5.7.20 it was deprecated, and has now been removed in MySQL 8, largely because it was as likely to hurt you badly as help you, particularly with correctly sized InnoDB buffering.

Zipf is a little idealistic. It is perfect for a quick analysis as the base case that a cache should excel at. Unfortunately LRU doesn't because it can be easily polluted. (examples: https://github.com/ben-manes/caffeine/wiki/Efficiency)

A database will often scan many records which would flush an LRU. Postgres uses small LRU buffer caches in your per-thread model, backed by a larger LRU-like cache. The buffer caches are easily flushed by scans, but protect the shared cache from this noise. That shared cache could probably benefit from a smarter policy and this is an on going topic.

This is assuming that all threads need a global view of the data. When this is not the case, it is sufficient to have many async goroutines ingest on a channel and fill their own local map, lock-free. This is our general strategy for high-performance streaming routines.

Right, fair enough. I only thought of that after I posted. Not used to thinking that memory is limited lol

The author did indicate that they had problems with oom and memory eviction so it probably is a memory limited use case.

Reply on news.ycombinator.com