Комментарии 25
Даже не знаю что хуже — то что вы считаете что кэш не нужен никому, руководствуясь только своим опытом создания конструктора сайтиков, или то что вы дождались проблем, что бы проверить скорость запросов в проде.
Наивно рекоммендовать всем отказаться от кэширования только из-за того, что если в одной конкретной архитектуре одного конкретного приложения с одним конкретным стеком технологий кэширование оказалось неэффективным.
Ожидал от статей от Wix большего… 3 статьи и все вода.
Кеш прячет проблемы производительности, а не решает их. Все те бутылочные горлышка которые есть в приложении продолжают быть ими без изменений, что приводит к еще более печальной ситуации когда кеш перестанет справляться с нагрузкой тоже.
Но как бывает со всем другим. лучшие практики не всегда применимы ко всем, множество приложений не дорастает до нагрузки когда кеш не справляется или когда логика инвалидации становится слишком сложной для поддержки. Поэтому кеширование так и популярно как быстрое решение проблем с узким местом в приложении. А понимание проблем которые это влечет приходит наааамного позже.
Но как бывает со всем другим. лучшие практики не всегда применимы ко всем, множество приложений не дорастает до нагрузки когда кеш не справляется или когда логика инвалидации становится слишком сложной для поддержки. Поэтому кеширование так и популярно как быстрое решение проблем с узким местом в приложении. А понимание проблем которые это влечет приходит наааамного позже.
Неправда. Кэш — это возможность не производить вычисления, если результат заранее известен. Вы не знакомитесь с коллегами на работе каждый день, потому что уже знаете как их зовут и кем они здесь работают, и вы закешировали у себя в голове эту информацию.
Это не совсем так голова отличный кеш-но он слишком умный. реальный кеш это лист бумаги на который ты записываешь имя человека и сбоку рисуешь его портрет для распознавания. И дальше когда добавляется новый коллега ты его добавляешь туда, а если удаляется пытается соотнести изображение с тем что у тебя нарисовано и вычеркнуть. А еще веселее если 2 брата близнеца работают в разных отделах. И кеш у тебя не просил листик а еще отображает иерархию отделов (вед охота знать что вот это Админ идет). И тогда ситуация перевода человека из одного отдела в другой это вообще ужас-ужас.
НЛО прилетело и опубликовало эту надпись здесь
Оборачивание всего подряд в кэш обычно бывает у начинающих, которых пугают тем, что база данных самое узкое место в их системе при 1000 посещениях в месяц и без кэша им никак не обойтись.
Но чаще всего бывает так, что запрос напрямую к базе будет и проще и безболезненнее, особенно когда оперативной памяти достаточно и БД сама все достанет из кэша.
Естественно, не говорю о случаях реального highload
Но чаще всего бывает так, что запрос напрямую к базе будет и проще и безболезненнее, особенно когда оперативной памяти достаточно и БД сама все достанет из кэша.
Естественно, не говорю о случаях реального highload
То, что вы денормализовали данные (раз всё, что вам нужно — это только обращение просто по ключу), не означает, что вы побороли все проблемы, потому что теперь вы усложнили обновление данных в БД, т.к. денормализация данных ведет к их дублированию, а значит обновлять их придется в разных таблицах в рамках одной транзакции, так что вы просто сменили проблему чтения на проблему записи.
Раз уж вы использовали мощные кластерные кэши на Java, то могли бы использовать read-through — механизм, который позволяет кэшу самому сходить в базу, если при запросе оказалось, что в кэше нет нужных данных. Не знаю насчет EhCache, но в Infinispan и в Apache Ignite, которые бесплатные и open source, такая функциональность есть, не говоря уже о коммерческих решениях, таких как Oracle Coherence и т.д. А если еще использовать и write-through/write-behind, которые позволяют пробрасывать в базу всё, что пишется в кэш (write-through — синхронная запись, write-behind — асинхронная), то вы можете вообще забыть о такой проблеме, как инвалидация кэша, потому что если всю работу с данными проводить через кэш, то это будет и быстро, и консистентно, и масштабируемо, а сама БД будет выполнять только роль persistent storage, который нужен чтобы прогреть кэш при холодном старте.
Частью этой архитектуры был Ehcache
Раз уж вы использовали мощные кластерные кэши на Java, то могли бы использовать read-through — механизм, который позволяет кэшу самому сходить в базу, если при запросе оказалось, что в кэше нет нужных данных. Не знаю насчет EhCache, но в Infinispan и в Apache Ignite, которые бесплатные и open source, такая функциональность есть, не говоря уже о коммерческих решениях, таких как Oracle Coherence и т.д. А если еще использовать и write-through/write-behind, которые позволяют пробрасывать в базу всё, что пишется в кэш (write-through — синхронная запись, write-behind — асинхронная), то вы можете вообще забыть о такой проблеме, как инвалидация кэша, потому что если всю работу с данными проводить через кэш, то это будет и быстро, и консистентно, и масштабируемо, а сама БД будет выполнять только роль persistent storage, который нужен чтобы прогреть кэш при холодном старте.
С кэшем связана одна существенная проблема — усложнение архитектуры. Появляется дополнительный сильно связанный слой.
В конечном итоге оптимальным выбором является действительно использовать кэш минимально. Но в этом случае, встает задача эффективного выбора основного хранилища. В заметке, например, сказано что MySQL был выбран исключительно по субъективным причинам. В тоже время, возможно, если бы к выбору хранилища данных подошли бы более ответственно, то необходимость в кэшировании могла бы вообще не возникнуть.
Мы в последнее время вообще отказались и от MySQL и от кэша. В итоге производительность только улучшилась отпало множество проблем связанных с обслуживанием кэша, архитектура стала куда прозрачнее.
В конечном итоге оптимальным выбором является действительно использовать кэш минимально. Но в этом случае, встает задача эффективного выбора основного хранилища. В заметке, например, сказано что MySQL был выбран исключительно по субъективным причинам. В тоже время, возможно, если бы к выбору хранилища данных подошли бы более ответственно, то необходимость в кэшировании могла бы вообще не возникнуть.
Мы в последнее время вообще отказались и от MySQL и от кэша. В итоге производительность только улучшилась отпало множество проблем связанных с обслуживанием кэша, архитектура стала куда прозрачнее.
Об этом как раз следующий пост.
Архитектура усложняется если кэширование производить на стороне приложения, а не хранилища, прозрачно для приложения.
зачастую бывает, что выбор БД — это лишь историческое наследие прошлых лет, однако как гласит основное правило: используются те инструменты, которое лучше знает архитектор системы.
НЛО прилетело и опубликовало эту надпись здесь
Что совсем без кэша? Без трёх уровней кэша в процессоре, без кэша в диске, без дискового (как минимум) кэша в ОС, без кэша в том же MySQL?
Ваш случай — хороший пример безответственного подхода к кэшированию: "сначала кэш сделаем, а думать как его инвалидировать и греть будем потом". А ведь думать над этим надо начинать при первой же мысли "что-то тормозит, может кэш намутить".
И, да, если вы для чтения только по ключам без джойнов денормализовали свою базу, то вы просто сделали кэш в самой базе.
Ваш случай — хороший пример безответственного подхода к кэшированию: "сначала кэш сделаем, а думать как его инвалидировать и греть будем потом". А ведь думать над этим надо начинать при первой же мысли "что-то тормозит, может кэш намутить".
И, да, если вы для чтения только по ключам без джойнов денормализовали свою базу, то вы просто сделали кэш в самой базе.
А что плохого в использовании MySQL как key-value хранилища (вообще без Join-ов)?
(без относительно случая автора статьи)
У нас на похожем стеке (Java/jdbc + tomcat) кэш в первую очередь
помогал от переполнения пула соединений к базе (как бы быстро не выполнялись запросы — пул был узким местом почему-то).
(без относительно случая автора статьи)
У нас на похожем стеке (Java/jdbc + tomcat) кэш в первую очередь
помогал от переполнения пула соединений к базе (как бы быстро не выполнялись запросы — пул был узким местом почему-то).
Да ничего плохо, если value нормализованы. Но на практике эти value часто являются кэшем для джойнов и(или) группировок, и для джойнов вовсе не 1:1 или 1:0, и для группировк не по первичному ключу. То есть джойны и группировки просто делаются на стороне приложения при записи (вариант — материализованные вью на стороне БД), чтобы чтение было максимально быстрым. Такой подход имеет право на жизнь, но он является разновидностью кэширования.
Краткое содержание: «мы слепили сайт из чего-то, что нашли, еще чего-то, и еще из Явы и Флеша, потом набрали юзеров, потом выяснили, что наш кеш не умеет инвалидироваться, потом его отключили — а сайт стал работать быстро. Вывод: кеши в мире никому не нужны.»
Перевод: вместо того, что построить по-настоящему эффективную архитектуру, люди взяли что-то, чем сами не умели управлять, и из собственного незнания сделали вывод, что никому в мире кеш не нужен.
Я бы сказал, что делать сайт на чистом флеше, расползающийся в почти любом браузере, сайт, для индексирования которого массе людей пришлось предпринимать героические усилия — это само по себе плевать против ветра. Если же взять для кеша систему, инвалидировать записи в которой сама же система управления сайтом не умеет… Скажите, вам за такое героическое преодоление самими же вами созданных граблей хоть премию выписали? :)
P.S. Честно говоря, по опыту поддержки сайтов с миллионами посетителей могу сказать ровно обратное. Только сайты эти а) используют более эффективный стек, б) крутятся на в сотни раз менее мощных серверах, и в) не упоминаются в героических рассказах о том, как решили грабли, откровенно созданные своими руками.
На самом деле при запуске проекта, когда юзеров немного, а запуск надо сделать поскорее, каких только костылей не вставляют. Но потом-то их надо выпалывать, и планово, уже с заделом на будущее. Тем более что 99% страниц сайтов ваших клиентов не требуют постоянного изменения, так что отдать их из кеша — самое то, и это выгоднее, чем требовать от sql невозможного.
Перевод: вместо того, что построить по-настоящему эффективную архитектуру, люди взяли что-то, чем сами не умели управлять, и из собственного незнания сделали вывод, что никому в мире кеш не нужен.
Я бы сказал, что делать сайт на чистом флеше, расползающийся в почти любом браузере, сайт, для индексирования которого массе людей пришлось предпринимать героические усилия — это само по себе плевать против ветра. Если же взять для кеша систему, инвалидировать записи в которой сама же система управления сайтом не умеет… Скажите, вам за такое героическое преодоление самими же вами созданных граблей хоть премию выписали? :)
P.S. Честно говоря, по опыту поддержки сайтов с миллионами посетителей могу сказать ровно обратное. Только сайты эти а) используют более эффективный стек, б) крутятся на в сотни раз менее мощных серверах, и в) не упоминаются в героических рассказах о том, как решили грабли, откровенно созданные своими руками.
На самом деле при запуске проекта, когда юзеров немного, а запуск надо сделать поскорее, каких только костылей не вставляют. Но потом-то их надо выпалывать, и планово, уже с заделом на будущее. Тем более что 99% страниц сайтов ваших клиентов не требуют постоянного изменения, так что отдать их из кеша — самое то, и это выгоднее, чем требовать от sql невозможного.
Все правильно, кеш не нужен.
И это хороший повод переписать все на Tarantool.
И это хороший повод переписать все на Tarantool.
Решение правильное, а вывод — нет. Правильно настроить кеш не тривиальная задача и во многих случаях правильнее отдать память операционной системе — пусть она управляет кеш-ом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Масштабирование до 100 миллионов пользователей. Кэшировать или не кэшировать?