Спасибо за супер видос. Вопрос по мру: мне не ясно, как такой кеш не захлебывается. По идее он будет работать так: допустим его ёмкость 100; он заполняется до предела; на 101 элементе он начнет гоняться за своим хвостом - 99 элементов останутся лежать без дела, и только сотый будет обновляться. Видимо я не представляю юзкейс
Благодарю за материал! Это был максимально полезный стрим (хоть и смотрю его в записи)! У меня лишь небольшое замечание по поводу вычисления эффективности кеширования на 11-й минуте. Мне кажется тут берётся формула так, чтобы спустя N запросов к приложению, суммарное время отклика от приложения с кешированием было как можно меньше чем к такому же приложению без кеширования. Правильно ли я понял? Например мы 10 раз ходим в приложение: Приложение без кеширования это 10 * 100 = 1000 милисекунд (всегда идём в бд) Приложение с кешированием (при CacheMissRate = 0,8) это 0,8 * 10 * 100 + 10 * 20 = 1000 милисекунд (800 мс на БД и всегда перед этим идём в кеш - 200 мс) То есть при сравнении получается что при CacheMissRate = 0,8 ничего не меняется а при увеличении этого показателя, он будет не очень эфективен. Правильно ли я улавливаю мысль?
Поток - это сколько человек в группе? И второй вопрос. По уровням стандартный и ВИП. Домашки на ВИПе проверяются преподавателем, а на стандартном получается никто не проверяет?
Не глюк, все норм. Ничего страшного в этом нет, что бывает что-то на фоне. Ты когда видос смотришь у тебя сейчас идеальная тишина?)) Когда глотаешь знания ничего не мешает, т.к. Автор видео красавчик!))
Добрый день Влад, желаю приятного отпуска) Ты в конце видео сказал что скинешь материалы, бесплатные ресурсы, где лучше подготовиться по систем дизайну. Спасибо большое)
Имеется ввиду, что когда к кэшу обращаемся, мы уже потратили 20мс, не попали в кэш, пошли в базенку, ещё 100мс. Итого 120мс. Если таких запросов много, кэш вреден. И это еще не считая денег и времени на поддержку этого кэша
Имеется ввиду, что когда к кэшу обращаемся, мы уже потратили 20мс, не попали в кэш, пошли в базенку, ещё 100мс. Итого 120мс. Если таких запросов много, кэш вреден. И это еще не считая денег и времени на поддержку этого кэша
У нас используется кэширование данных внешней системы. Что бы мы не обращались к ней часто и не положили ненароком. От этой внешней системы в кафку летят ивенты на изменения, мы их читаем и актуализируем кеш. Да кстати, кеш в постгресе храним.
чет бред какой-то. кеш используется для чтения, а к-стримы для записи. Вы по ходу не поняли зачем нужна кафка) а еще хранить кеш в базе - так вообще зашквар. самый анти-патерный антипаттерн.
Описано ли там много алгоритмов вытеснения данных (Second Chance, Clock, ...), Тегирование кэша, Версионирование кэша, Многомерный кэш и многое другое, что есть в видео? Я вижу, что нет
@@stepanmikhailiuk4571 В этом и правда ничего такого нет, если изначально об этом сказать и дать ссылку например на источник) А так, Владимир поменял местами некоторые блоки из статьи. И у меня это вызвало больше вопросов чем ответов) Ошибки в структурировании привели меня к первоисточнику. Где я получил все ответы на вопросы.
Для Thundering Herd Problem. Еще можно так. Модуль кеша хранит два ключа - первый инвалидируется как нужно, например 30 sec, второй никогда или редко. Когда несколько процессов идут в кеш, а первого значения там уже нет, то только один начинает обновлять первый ключ, остальные получают второе значение. Когда первый закончит - он положит в кеш актуальное значение. Для примера со страницей Рональндо, какой-то небольшой процент не получит последние фото, но зато не за аффектит скорость работы сервисов.
Присоединяйтесь к моему каналу в Телеграм: t.me/vladimir_balun_programming
Подумал что про кэширование на процессоре.
Спасибо за супер видос. Вопрос по мру: мне не ясно, как такой кеш не захлебывается. По идее он будет работать так: допустим его ёмкость 100; он заполняется до предела; на 101 элементе он начнет гоняться за своим хвостом - 99 элементов останутся лежать без дела, и только сотый будет обновляться. Видимо я не представляю юзкейс
Большое спасибо за видео! А будет ли такое же видео, но про брокеры сообщений? Было бы очень полезно
Подумаю на счет этого)
Благодарю за материал! Это был максимально полезный стрим (хоть и смотрю его в записи)!
У меня лишь небольшое замечание по поводу вычисления эффективности кеширования на 11-й минуте. Мне кажется тут берётся формула так, чтобы спустя N запросов к приложению, суммарное время отклика от приложения с кешированием было как можно меньше чем к такому же приложению без кеширования. Правильно ли я понял?
Например мы 10 раз ходим в приложение:
Приложение без кеширования это 10 * 100 = 1000 милисекунд (всегда идём в бд)
Приложение с кешированием (при CacheMissRate = 0,8) это 0,8 * 10 * 100 + 10 * 20 = 1000 милисекунд (800 мс на БД и всегда перед этим идём в кеш - 200 мс)
То есть при сравнении получается что при CacheMissRate = 0,8 ничего не меняется а при увеличении этого показателя, он будет не очень эфективен. Правильно ли я улавливаю мысль?
Спасибо! По работе с кэшированием мало работал. Поэтому было полезно и интересно хотя бы теорию послушать.
Не за что!
это лучшее видео на ютубе про кэш!!! спасибо!
Первый раз ставлю скорость на 0.75 в Youtbube
Используете ли вы в своих задачах кэширование, если да - то что именно вам приходит кэшировать?
Кратко и информативно. Респект)
Спасибо!
Поток - это сколько человек в группе? И второй вопрос. По уровням стандартный и ВИП. Домашки на ВИПе проверяются преподавателем, а на стандартном получается никто не проверяет?
Думаю у меня глюк или в видео дети кричат на заднем фоне
Не глюк, все норм. Ничего страшного в этом нет, что бывает что-то на фоне. Ты когда видос смотришь у тебя сейчас идеальная тишина?))
Когда глотаешь знания ничего не мешает, т.к. Автор видео красавчик!))
Добрый день Влад, желаю приятного отпуска)
Ты в конце видео сказал что скинешь материалы, бесплатные ресурсы, где лучше подготовиться по систем дизайну.
Спасибо большое)
Объясните, откуда берется формула об среднем времени доступа к данным через три переменные?
Имеется ввиду, что когда к кэшу обращаемся, мы уже потратили 20мс, не попали в кэш, пошли в базенку, ещё 100мс. Итого 120мс. Если таких запросов много, кэш вреден. И это еще не считая денег и времени на поддержку этого кэша
Имеется ввиду, что когда к кэшу обращаемся, мы уже потратили 20мс, не попали в кэш, пошли в базенку, ещё 100мс. Итого 120мс. Если таких запросов много, кэш вреден. И это еще не считая денег и времени на поддержку этого кэша
У нас используется кэширование данных внешней системы. Что бы мы не обращались к ней часто и не положили ненароком. От этой внешней системы в кафку летят ивенты на изменения, мы их читаем и актуализируем кеш. Да кстати, кеш в постгресе храним.
чет бред какой-то. кеш используется для чтения, а к-стримы для записи. Вы по ходу не поняли зачем нужна кафка) а еще хранить кеш в базе - так вообще зашквар. самый анти-патерный антипаттерн.
Безоговорочно лайк и подписка
Это пересказ статьи "[По полочкам] Кэширование" с хабра?)
Описано ли там много алгоритмов вытеснения данных (Second Chance, Clock, ...), Тегирование кэша, Версионирование кэша, Многомерный кэш и многое другое, что есть в видео? Я вижу, что нет
Если даже это пересказ статьи, то ничего плохого в этом нет. Автору спасибо
@@stepanmikhailiuk4571 В этом и правда ничего такого нет, если изначально об этом сказать и дать ссылку например на источник)
А так, Владимир поменял местами некоторые блоки из статьи. И у меня это вызвало больше вопросов чем ответов)
Ошибки в структурировании привели меня к первоисточнику. Где я получил все ответы на вопросы.
@@eugenefedoryachenko8793 Понял вас, спасибо за ответ. Тоже теперь прочту!
Для Thundering Herd Problem. Еще можно так. Модуль кеша хранит два ключа - первый инвалидируется как нужно, например 30 sec, второй никогда или редко. Когда несколько процессов идут в кеш, а первого значения там уже нет, то только один начинает обновлять первый ключ, остальные получают второе значение. Когда первый закончит - он положит в кеш актуальное значение. Для примера со страницей Рональндо, какой-то небольшой процент не получит последние фото, но зато не за аффектит скорость работы сервисов.
100 кэшхит / 10 кэшмис = 10% попадания по твоим словам
Ага, тоже обратил на это внимание. Правильно должно быть (cache hists) / ((cache hists) + (cache misses)). Тогда в данном случае получим 0.9 или 90%
Спасибо! Ты лучший! ❤
Спасибо огромное за большой урок
Не за что!
всё верно!@@vladimir_balun_programming
Уууф, чувствую, что будет жарко! Еще не глянул, но уже понимаю, что это час сплошного кайфа. Благодарю! И давай больше систем десигна
Спасибо)
Spasibo Balun!
Слишком растянутая информация. Как стрим наверное нормально. Для видео лучше по 15 минут по конкретной теме
Лять, ну нормально все было бы, если бэ не эти "кэшА", "в кэшЭ". Уши режет. Выключил через 2 минуты
Какой нежный) 🤡
Отличное видео как всегда)Кстати у Криштиану Рональду 612 млн подписчиков)
Буду знать)