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

короче
1) если вы держите кэш прямо в приложении, то он вам нахуй не нужен, потому что потом отмасштабироваться не сможете
2) если вы держите кэш как положено сетевым сервисом, то он опять же нахуй не нужен, потому что ограничен оперативкой, и проще пихать всё то же самое в основное хранилище, предоставляя возможность кэшу файловой системы держать страницы с горячими данными в той же памяти, зато не ебаться со всякими вытеснениями. Хранилище даже холодные данные поднимет без проблем, потому что дешевле key-value запросов не может быть ничего

Ну сотня, один фиг

ты просто говоришь цифры, но на деле их не знаешь

Можно подумать 3 джоина это как сходить в кейвелью стор

Плюс сервачек субд на другой машине, когда

Ну про редис я писал. Там не тот скейл, проще будет вертикально отскейлить.

Это разве если будем потом дальше развивать проект

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

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

Интересно в шарпах есть аналог джавийного System.nanoTime() ?

Это уже интересно, но я не убежу на такое второго разраба)

Неструктурированые данные хранить

Читать с оперативы всё равно быстрее чем с физической памяти. Норм в кэш положить данные - результат вычисления. А пихать в бд такие временные данные = потом так же само чистить таблицы. Что на порядок тяжелее чем очищать оперативку

зачем их чистить?

Потому что память ограничена, а данные теряют быстро надобность? Всё от задач конечно зависит. Но по своей практике скажу. Синтетические тесты новых микросервисов всегда показывали максимальную скорость при работе с кэшом (тот же Redis). А в некоторых задачах ещё и такой алгоритм:
1) данные попадают в кэш
2) данные попадают в файловую систему
3) бэкграунд воркеры пихают данные с файловой системы в бд
Как всегда бд самая медленная и нагруженная часть системы

> Потому что память ограничена
Мы про жесткий и максимум удвоение данных

> а данные теряют быстро надобность?
Если они потеряли надобность, может быть, еще и исходные данные пришибить?

> Синтетические тесты новых микросервисов всегда показывали максимальную скорость при работе с кэшом (тот же Redis).
Я даже не буду подробно разбирать абсурдность этой фразы. Максимальную скорость /dev/null показывает.

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

> Как всегда бд самая медленная и нагруженная часть систем

потому что вы не умеете с ней работать и из-за этого обмазываетесь всякой хуетой типа редиса

То есть ты поспоришь с тем, что жесткий диск медленнее RAM?

то есть ты цепляешься за самый финальный аргумент

Нет

до этого ты говорил про редис, а не про жесткий диск и оперативку