У нас используется кэширование данных внешней системы. Что бы мы не обращались к ней часто и не положили ненароком. От этой внешней системы в кафку летят ивенты на изменения, мы их читаем и актуализируем кеш. Да кстати, кеш в постгресе храним.
Добрый день Влад, желаю приятного отпуска) Ты в конце видео сказал что скинешь материалы, бесплатные ресурсы, где лучше подготовиться по систем дизайну. Спасибо большое)
Для Thundering Herd Problem. Еще можно так. Модуль кеша хранит два ключа - первый инвалидируется как нужно, например 30 sec, второй никогда или редко. Когда несколько процессов идут в кеш, а первого значения там уже нет, то только один начинает обновлять первый ключ, остальные получают второе значение. Когда первый закончит - он положит в кеш актуальное значение. Для примера со страницей Рональндо, какой-то небольшой процент не получит последние фото, но зато не за аффектит скорость работы сервисов.
Благодарю за материал! Это был максимально полезный стрим (хоть и смотрю его в записи)! У меня лишь небольшое замечание по поводу вычисления эффективности кеширования на 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 В этом и правда ничего такого нет, если изначально об этом сказать и дать ссылку например на источник) А так, Владимир поменял местами некоторые блоки из статьи. И у меня это вызвало больше вопросов чем ответов) Ошибки в структурировании привели меня к первоисточнику. Где я получил все ответы на вопросы.
Не глюк, все норм. Ничего страшного в этом нет, что бывает что-то на фоне. Ты когда видос смотришь у тебя сейчас идеальная тишина?)) Когда глотаешь знания ничего не мешает, т.к. Автор видео красавчик!))
Присоединяйтесь к моему каналу в Телеграм: t.me/vladimir_balun_programming
это лучшее видео на ютубе про кэш!!! спасибо!
Спасибо! По работе с кэшированием мало работал. Поэтому было полезно и интересно хотя бы теорию послушать.
Не за что!
Кратко и информативно. Респект)
Спасибо!
У нас используется кэширование данных внешней системы. Что бы мы не обращались к ней часто и не положили ненароком. От этой внешней системы в кафку летят ивенты на изменения, мы их читаем и актуализируем кеш. Да кстати, кеш в постгресе храним.
Добрый день Влад, желаю приятного отпуска)
Ты в конце видео сказал что скинешь материалы, бесплатные ресурсы, где лучше подготовиться по систем дизайну.
Спасибо большое)
Большое спасибо за видео! А будет ли такое же видео, но про брокеры сообщений? Было бы очень полезно
Подумаю на счет этого)
Для Thundering Herd Problem. Еще можно так. Модуль кеша хранит два ключа - первый инвалидируется как нужно, например 30 sec, второй никогда или редко. Когда несколько процессов идут в кеш, а первого значения там уже нет, то только один начинает обновлять первый ключ, остальные получают второе значение. Когда первый закончит - он положит в кеш актуальное значение. Для примера со страницей Рональндо, какой-то небольшой процент не получит последние фото, но зато не за аффектит скорость работы сервисов.
Уууф, чувствую, что будет жарко! Еще не глянул, но уже понимаю, что это час сплошного кайфа. Благодарю! И давай больше систем десигна
Спасибо)
Спасибо огромное за большой урок
Не за что!
всё верно!@@vladimir_balun_programming
Безоговорочно лайк и подписка
Используете ли вы в своих задачах кэширование, если да - то что именно вам приходит кэшировать?
Спасибо! Ты лучший! ❤
Благодарю за материал! Это был максимально полезный стрим (хоть и смотрю его в записи)!
У меня лишь небольшое замечание по поводу вычисления эффективности кеширования на 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 В этом и правда ничего такого нет, если изначально об этом сказать и дать ссылку например на источник)
А так, Владимир поменял местами некоторые блоки из статьи. И у меня это вызвало больше вопросов чем ответов)
Ошибки в структурировании привели меня к первоисточнику. Где я получил все ответы на вопросы.
@@eugenefedoryachenko8793 Понял вас, спасибо за ответ. Тоже теперь прочту!
Spasibo Balun!
Первый раз ставлю скорость на 0.75 в Youtbube
100 кэшхит / 10 кэшмис = 10% попадания по твоим словам
Ага, тоже обратил на это внимание. Правильно должно быть (cache hists) / ((cache hists) + (cache misses)). Тогда в данном случае получим 0.9 или 90%
Думаю у меня глюк или в видео дети кричат на заднем фоне
Не глюк, все норм. Ничего страшного в этом нет, что бывает что-то на фоне. Ты когда видос смотришь у тебя сейчас идеальная тишина?))
Когда глотаешь знания ничего не мешает, т.к. Автор видео красавчик!))
Лять, ну нормально все было бы, если бэ не эти "кэшА", "в кэшЭ". Уши режет. Выключил через 2 минуты
Какой нежный) 🤡
Слишком растянутая информация. Как стрим наверное нормально. Для видео лучше по 15 минут по конкретной теме
Отличное видео как всегда)Кстати у Криштиану Рональду 612 млн подписчиков)
Буду знать)