diff --git a/.obsidian/plugins/home-tab/data.json b/.obsidian/plugins/home-tab/data.json index 9f59f573..5a06f669 100644 --- a/.obsidian/plugins/home-tab/data.json +++ b/.obsidian/plugins/home-tab/data.json @@ -23,6 +23,14 @@ "markdownOnly": false, "unresolvedLinks": false, "recentFilesStore": [ + { + "filepath": "_inbox/Кэширование.md", + "timestamp": 1718688838197 + }, + { + "filepath": "Инвалидация кэша.md", + "timestamp": 1718688811143 + }, { "filepath": "_inbox/Старт с холодным кэшом.md", "timestamp": 1718688297229 @@ -31,17 +39,9 @@ "filepath": "home/Вычеты/Вычет 2024.md", "timestamp": 1718688293724 }, - { - "filepath": "_inbox/Кэширование.md", - "timestamp": 1718688217945 - }, { "filepath": "_inbox/Перестройка кэша.md", "timestamp": 1718688112432 - }, - { - "filepath": "Home.md", - "timestamp": 1718688013137 } ], "bookmarkedFileStore": [], diff --git a/.obsidian/plugins/recent-files-obsidian/data.json b/.obsidian/plugins/recent-files-obsidian/data.json index ce5cd6bb..059af799 100644 --- a/.obsidian/plugins/recent-files-obsidian/data.json +++ b/.obsidian/plugins/recent-files-obsidian/data.json @@ -1,5 +1,13 @@ { "recentFiles": [ + { + "basename": "Кэширование", + "path": "_inbox/Кэширование.md" + }, + { + "basename": "Инвалидация кэша", + "path": "Инвалидация кэша.md" + }, { "basename": "Старт с холодным кэшом", "path": "_inbox/Старт с холодным кэшом.md" @@ -8,10 +16,6 @@ "basename": "Вычет 2024", "path": "home/Вычеты/Вычет 2024.md" }, - { - "basename": "Кэширование", - "path": "_inbox/Кэширование.md" - }, { "basename": "Перестройка кэша", "path": "_inbox/Перестройка кэша.md" @@ -195,10 +199,6 @@ { "basename": "00 PostgreSQL", "path": "wiki/zero/00 PostgreSQL.md" - }, - { - "basename": "PgBouncer", - "path": "_inbox/PgBouncer.md" } ], "omittedPaths": [], diff --git a/Cache miss.md b/Cache miss.md new file mode 100644 index 00000000..95ba96ea --- /dev/null +++ b/Cache miss.md @@ -0,0 +1,13 @@ +## Cache miss +По формуле можно расчитать как часто мы будем промахиваться мимо кэша + +AverageTime = CacheAccessTime + DbAccessTime \* CacheMissRate +- AverageTime - среднее время жизни кэша +- CacheAccessTime - время доступа к кэшу +- DbAccessTime - время доступа к БД +- CacheMissRate - количество промахов мимо кэша + +Пусть +- DbAccessTime = 100ms +- CacheAccessTime = 20ms +- Тогда при CacheMissRate > 0.8 - кэш вреден. \ No newline at end of file diff --git a/_inbox/Кэширование.md b/_inbox/Кэширование.md index f6667f49..f2559297 100644 --- a/_inbox/Кэширование.md +++ b/_inbox/Кэширование.md @@ -50,38 +50,8 @@ $key = md5(serialize($options)) Такой ключ удовлетворяет первому условию% при изменении `$options` будет обязательно изменен `$key`, но и второе условие будет соблюдаться, если мы будем все типы данных в $options использовать «канонически», т.е. не допускать строки `"1"` вместо числа `1`. Функция `md5` используется для «сжатия» данных. -## Инвалидация -Если мы закэшировали какие-то данные от backend’а, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением. - -Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. - -Первый вариант не подходит. Некоторые чуствительные данные нужно инвалидировать их сразу при изменении. Тут может помочь тегирование ключей. - -Инвалидация: -- По истечению срока жизни - TTL -- Принудительный вызов команды инвалидации -- Алгоритмы вытеснения - -Алгоритмы вытеснения: -- Алгоритм Белади. Несуществующий идеальный алгоритм. Храним только нужную информацию, не нужную не храним. -- [Least Recently Used](Least%20Recently%20Used.md) -- [Most Recently Used](Most%20Recently%20Used.md) -- [Last Frequently Used](Last%20Frequently%20Used.md) -- [Adaptive Replacement Cache](Adaptive%20Replacement%20Cache.md) - -- [Перестройка кэша](Перестройка%20кэша.md) -## Cache miss -По формуле можно расчитать как часто мы будем промахиваться мимо кэша - -AverageTime = CacheAccessTime + DbAccessTime \* CacheMissRate -- AverageTime - среднее время жизни кэша -- CacheAccessTime - время доступа к кэшу -- DbAccessTime - время доступа к БД -- CacheMissRate - количество промахов мимо кэша - -Пусть -- DbAccessTime = 100ms -- CacheAccessTime = 20ms -- Тогда при CacheMissRate > 0.8 - кэш вреден. +## Инвалидация кэша +![Инвалидация кэша](Инвалидация%20кэша.md) +[Cache miss](Cache%20miss.md) ## Дополнительные материалы - [Старт с холодным кэшом](Старт%20с%20холодным%20кэшом.md) \ No newline at end of file diff --git a/Инвалидация кэша.md b/Инвалидация кэша.md new file mode 100644 index 00000000..d41de97a --- /dev/null +++ b/Инвалидация кэша.md @@ -0,0 +1,34 @@ +--- +aliases: +tags: + - зрелость/🌱 +date: + - - 2024-06-18 +zero-link: + - "[[00 HighLoad]]" +parents: + - "[[Кэширование]]" +linked: +--- + +Если мы закэшировали какие-то данные от backend’а, например, выборку из БД, рано или поздно исходные данные изменяются, и кэш перестает быть валидным. Причем очень желательно, чтобы кэш сбрасывался сразу же за изменением. + +Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. + +Первый вариант не подходит. Некоторые чуствительные данные нужно инвалидировать их сразу при изменении. Тут может помочь тегирование ключей. + +**Способы инвалидации:** +- По истечению срока жизни - TTL. + - Самый простой способ. + - При малом TTL можно +- Принудительный вызов команды инвалидации. +- Алгоритмы вытеснения + +Алгоритмы вытеснения: +- Алгоритм Белади. Несуществующий идеальный алгоритм. Храним только нужную информацию, не нужную не храним. +- [Least Recently Used](Least%20Recently%20Used.md) +- [Most Recently Used](Most%20Recently%20Used.md) +- [Last Frequently Used](Last%20Frequently%20Used.md) +- [Adaptive Replacement Cache](Adaptive%20Replacement%20Cache.md) + +- [Перестройка кэша](Перестройка%20кэша.md) \ No newline at end of file