🍲 Трёшка! Мы её теряем!

Согласно данным РБК, для одобрения ипотеки на приобретение скромной трёшки в российских городах-миллионниках потребуется зарплата в среднем 257'800 руб.

Если говорить о Москве, то планка необходимого дохода поднимется до 715'500. Питер и Казань занимают почётное второе и третье место соответственно.

Не знаю, как вам, а меня цифры впечатляют. Особенно что касается столицы.

Но, чтобы не останавливаться на эмоциональной составляющей, предлагаю дополнить картину сведениями Хабр Карьеры об уровне заработных плат системных аналитиков. Понимаю, что могут быть вопросы к репрезентативности Хабра, но всё же.

Так вот, при средней 225'000 руб. с разбросом ± 90'000 руб. выглядит так, что трёшка системному аналитику, скорее всего, не светит чисто математически. Для того, чтобы получить на неё ипотеку квалифицированному специалисту может потребоваться рост доходов в 2.5-3 раза от текущих уровней.

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

#жиза #экономика #ипотека #недвижимость #зарплаты

❌ Не так страшен кэш, как его малюют

Если ранее я писал о многообразии термина "кэш", то сегодня хочу сосредоточиться на более прикладных вопросах. Мы поговорим про алгоритмы работы с ним.
👇

〰️ Стратегии кэширования (Caching Strategies) 〰️

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

🟢 Стратегии для чтения
Направлены на минимизацию задержек при доступе к данным и повышение производительности системы.
🟢🟢 Cache aside — при обращении к данным проверяется наличие их копии в кэше. Если копия отсутствует, запрашиваются данные из основного хранилища, далее они сохраняются в кэше и возвращаются клиенту.
🟢🟢 Read through — клиентские запросы направляются непосредственно в кэш. Если данные отсутствуют, кэш самостоятельно извлекает их из основного хранилища, сохраняет и далее возвращает клиенту.

🟢 Стратегии для записи
Направлены на минимизацию задержек при сохранении изменений и обеспечение согласованности данных.
🟢🟢 Write around — запись выполняется в обход кэша прямо в основное хранилище. Если эти данные впоследствии понадобятся для чтения, они попадут в кэш по одной из стратегий для чтения. Такой подход снижает риск потери данных при сбоях кэша, но увеличивает задержки.
🟢🟢 Write back, или Write behind — записываемые данные сначала сохраняются в кэше, а позже асинхронно записываются в основное хранилище. Такой подход повышает производительность, но требует механизмов отслеживания состояния кэша.
🟢🟢 Write through — данные одновременно записываются и в кэш, и в основное хранилище. Такой подход гарантирует мгновенную доступность данных, но замедляет операции записи.


〰️ Политики очистки кэша (Cache Clearing) 〰️

Определяют правила управления памятью кэша и в зависимости от цели эти политики можно разделить на две категории:

🔵 Политики вытеснения (Cache Replacement, или Cache Eviction)
Вытеснение — это автоматическое удаление старых записей кэша, чтобы освободить место для новых. Цель — эффективно использовать ограниченное пространство кэша.
🔵🔵 FIFO (First In First Out) — удаляются данные, дольше всего находящиеся в кэше независимо от частоты использования.
🔵🔵 LIFO (Last In First Out) — первыми удаляются недавно добавленные данные, сохраняя наиболее старые.
🔵🔵 RR (Random Replacement) — данные для удаления выбираются случайным образом.
🔵🔵 LRU (Least Recently Used) — удаляются данные, которые дольше всего не использовались; критерий — время последнего обращения.
🔵🔵 LFU (Least Frequently Used) — удаляются наименее часто используемые данные; критерий — частота обращений.

🔵 Политики инвалидации (Cache Invalidation)
Инвалидация — процесс удаления устаревших или нерелевантных данных из кэша для того, чтобы он содержал только актуальную информацию. Цель — обеспечить соответствие данных, хранящихся в кэше, данным из источника.
🔵🔵 Инвалидация при изменении — происходит сразу после обновления данных в источнике, гарантируя свежесть данных в кэше.
🔵🔵 Инвалидация при чтении — проверяется актуальность данных при каждом запросе, что может привести к снижению производительности.
🔵🔵 Инвалидация по истечении времени (Time To Live, TTL) — устанавливается ограничение срока жизни данных, после которого они автоматически удаляются из кэша.

❗Приведённые стратегии являются лишь частью множества существующих подходов. Для конкретных приложений и систем оптимальные решения могут различаться.

#проектирование #данные #термины