vault backup: 2024-06-18 08:34:14

This commit is contained in:
Struchkov Mark 2024-06-18 08:34:14 +03:00
parent fc6b020e79
commit f7c3a59695
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C
5 changed files with 66 additions and 49 deletions

View File

@ -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": [],

View File

@ -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": [],

13
Cache miss.md Normal file
View File

@ -0,0 +1,13 @@
## Cache miss
По формуле можно расчитать как часто мы будем промахиваться мимо кэша
AverageTime = CacheAccessTime + DbAccessTime \* CacheMissRate
- AverageTime - среднее время жизни кэша
- CacheAccessTime - время доступа к кэшу
- DbAccessTime - время доступа к БД
- CacheMissRate - количество промахов мимо кэша
Пусть
- DbAccessTime = 100ms
- CacheAccessTime = 20ms
- Тогда при CacheMissRate > 0.8 - кэш вреден.

View File

@ -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)

View File

@ -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)