Ментор не знаком с Elixir/Erlang-ом? Обычно когда дело заходит о cache - в других языках говорят, возьми redis и всё. В мире beam, чтобы взять Redis - нужна либо действительно обоснованная причина (обычно одна из трёх перечисленных выше), так как крутые инструменты для cache-а уже встроенны в виде ETS (и библиотек поверх ETS, напирмер cachex).

Ещё конечно можно взять Redis, просто чтобы научится использовать Redis, в данном случае, как четвёртая возможная причина 😊

Скажем так - меня взяли из-за огромного любопытства в сторону Elixir.
Так что думаю, возможно в этом причина😅😄

Спасибо всем огромное☀️☀️☀️

😄👍

Человеческая регулярка

https://verbalregex.com/

https://github.com/VerbalExpressions/ElixirVerbalExpressions

хотите попробовать redis. redis-cli хватит с головай, тащить сюда elixir это лишнее

Там не только это нужно :)
Это лишь часть функционала, насчёт которого хотелось узнать все варианты.
В любом случае, спасибо за отзывчивость ☀️

Небольшой апдейт.
Согласно данной таблице, необходимы LRU Cache и PubSub.

https://github.com/whitfin/cachex - LRU есть в cachex.

В cachex есть LRU: https://github.com/whitfin/cachex/blob/master/docs/features/cache-limits.md#configuration PubSub не из коробки, но можно достаточно легко реализовать на основе hook-ов: https://github.com/whitfin/cachex/blob/master/docs/features/execution-hooks.md

1) использование кеша — это как антибиотики. Нельзя просто так начинать с них в профилактических целях, надо иметь серьезные причины что бы пихать кеш в проект.  У кеша есть проблема инвалидации кеша, а это проблема.

2) поход к редису — 1000 мкс, поход к ets — 1 мкс.
Оно тебе точно нужно по сети?

Точно нужно: LRU, который есть в Cachex; PubSub, который таки можно реализовать, как выразились выше, с помощью hook'ов.
Так что, пока останавливаюсь над разбором с Cachex

для начала подойдет, потом сможешь добраться до технологии асинхронного обновления с stale cache response

Признаюсь, для меня сейчас это звучит почти как заклинание. 🤓
Спасибо☀️

что бы тебе нужен был кеш, надо что бы у тебя время на вычисление оригинального ответа было, скажем, 1 или 10 секунд

если ты возьмешь примитивный LRU, то ты легко можешь получить такую ситуацию, что:
1) часто востребованный запрос очень надолго задержится в кеше, скажем зависнет на неделю и будет отдаваться что-то, очень старое и уже совсем не релевантное
2) очень большие и чрезвычайно запросы будут прилетать, блокировать всё-всё на своё вычисление и потом так же выбрасываться. При особо удачном сценарии, у тебя на _каждый_ запрос к очень трудновычислимому ресурсу, будет происходить заново пересчет, т.е. ты смотришь в кеш, там всё закешированно, а проку никакого, cache miss зашкаливает за 70%

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

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

следующая дилема — это организация вычислений.

Если ты пользуешься простым редисом, то вот тебе сценарий:  стоит 80 телевизоров, которые показывают одно и то же почти синхронно, им приходит команда:  запросите эти данные и покажите.  Они приходят все почти одновременно за одним и тем же запросом.

Если у тебя нет правильного лока, то запрос вычисляется 80 раз и кладется в кеш 80 раз.


Это фантастическое расточительство, нужно делать вменяемый лок на ресурс и сигнализировать, что сейчас есть какой-то процесс, который вычисляет ответ.

Если ты сделаешь это всё через сигнлтонный процесс, который будет блокирующим образом вычислять ответы для кеша, то получишь дурную ситуацию, когда у тебя вся система свелась к одному ядру, что неправильно.

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