Как думаете, что будет менее затратным? Вот есть структура type Items

map[int64]*Item (в питоне это словарь с ключом int и каким нибудь экземпляром класса в value).
Так вот. Допустим этот словарь стал пиздец каким большим.
Есть задача устаревшие удалять.

Как делать?
1. Воркер который будет периодически гонять цикл и проверяя даты в полях, удалять Item.
2. С созданием Item запускать горутину с таймером, по окончанию которой идти в эту "базу" и тупо удалять по ключу значиение.
один цикл который будет перодически в лоб перемалывать
или миллион записей в словаре(мапе), условно миллион ожидающий горутин(хоть и легковесных).

3. Использовать redis

только память!

а есть смысл во втором варианте если "Допустим этот словарь стал пиздец каким большим"

Миллион - это не очень много, это раз Два - нужен не миллион горутин, а миллион таймеров Три - миллион горутин может быть дорогим по памяти Четыре - а как звучит исходная задача?

поступают некие задачи на ручку. запущен воркер пул на 5 воркеров, там эти задачи разбираются, делается магия некая. Результаты складируются в память, устаревшие нужно подчищаться. Что получается, нужно определить на каком максимальном числе горутин может работать программа(ну и сколько вместит записей в память)? Или просто оставить перебор обычным циклом по скажем каждый 3-5 мин.

Оба способа не очень, для ttl нужна такая структура данных, как куча

А как это будет масштабироваться? Один запрос пришёл в одну реплику, а следующий - в другую, и там этих результатов не будет

кажется что лучше проверять срок жизни при попытке считывания и при протухании удалять, ну и сайд воркер который будет подчищать старые записи которые никто давно не читал (как и где их хранить пока не знаю)

я бы складывал ttl в слайс, и раз в те же 3-5 минут проходился бы по нему, убирал все устаревшие и мапу не надо лочить на полный обход, и тяжелые структуры данных создавать, и много мусора генерить

Мне кажется, это задача для редиса. Там ттл искаробки, шардинг, устойчивость к перезагрузкам и т.д.

блэээ, а я наоборот все в мапу перетащил только что😂. прицеливался ко второму варианту.☝️

слайс тут хорош тем, что, если ttl у вас одинаковый для всех записей, можно быстро из него извлечь все устаревшие ключи

Слайс дорого всё равно. После каждого похода нужно выкидывать ранние элементы, а аппенд будет периодически создать новый массив

ttl разный, для каждый задачи свой задается🧐

ну тогда ничего лучше приоритетной очереди (timer wheel в данном случае) нет

циклическая очередь в помощь

Ну да, выглядит удобно. И горутина, которая дергает за голову, удаляя старые записи. Вставка только неудобная, если с произвольным ттл

и что? почему вы думаете, что это дорого? почему вы думаете, что есть структура данных дешевле? hint: слайс на миллион 16-байтовых структур (ключ + наносекунды) влезет в процессорный кеш

(целиком влезет не на всех процессорах, но нужная его часть - влезет точно)

ну с произвольным ттл сильно сложнее, да, если брать что-то простое, то только в голову за быстро приходит приоритетная очередь, но если пойти рыться, то с большой вероятностью можно найти что-то более веселое (например, раньше редис вытеснял ключи с помощью пробинга, но тут это не поможет, так как нужна более широкая апишка мапы, чем предоставляет стандартная гошная мапа)

Вот кстати нашел реализацию с использованием кучи (там правда готовая хипа, но все же) https://github.com/jellydator/ttlcache