Зачем использовать кеш на уровне приложения, если база данных уже обеспечивает кеширование?

Даже если ядро ​​базы данных кэширует данные, индексы или наборы результатов запросов, оно все равно может совершить обратную поездку в базу данных, чтобы ваше приложение могло воспользоваться этим кэшем.

Платформа ORM работает в том же пространстве, что и ваше приложение. Так что туда и обратно нет. Это просто доступ к памяти, который обычно намного быстрее.

Фреймворк также может принять решение хранить данные в кеше, пока это необходимо. База данных может принять решение об истечении срока хранения кэшированных данных в непредсказуемые моменты времени, когда другие одновременные клиенты делают запросы, которые используют кэш.

Ваша платформа ORM на стороне приложения также может кэшировать данные в форме, которую база данных не может вернуть. Например. в виде коллекции объектов Java вместо потока необработанных данных. Если вы полагаетесь на кэширование базы данных, ваш ORM должен повторить это преобразование в объекты, что увеличивает накладные расходы и уменьшает выгоду от кэша.

Кроме того, кэш базы данных может быть не таким практичным, как кажется. Я скопировал это из http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together - это специфично для MySQL, хотя.

Учитывая, что MySQL имеет кэш, зачем вообще нужен memcached?

Кэш MySQL связан только с одним экземпляром. Это ограничивает кэш-память максимальным адресом одного сервера. Если ваша система больше, чем память для одного сервера, то использование кэша MySQL не будет работать. И если тот же объект читается из другого экземпляра, он не кэшируется.

Кэш запросов становится недействительным при записи. Вы создаете весь этот кеш, и он исчезает, когда кто-то пишет в него. Ваш кеш может вообще не быть частью кеша в зависимости от моделей использования.

Кэш запросов основан на строках. Memcached может кэшировать любой тип данных, который вы хотите, и он не ограничивается кэшированием строк базы данных. Memcached может кэшировать сложные сложные объекты, которые можно напрямую использовать без объединения.

Нет сомнений в том, что современные базы данных предоставляют возможность кэширования, но когда у вас больше трафика на вашем сайте, и в это время вам необходимо выполнить много транзакций базы данных, вы не получите высокой производительности. Так что в этом случае повышение производительности приведет к кешированию в спящем режиме. помочь вам, оптимизируя приложения базы данных. Кэш на самом деле хранит данные, уже загруженные из базы данных, так что трафик между нашим приложением и базой данных будет уменьшен, когда приложение снова захочет получить доступ к этим данным. Время доступа и трафик будут уменьшены между приложением и базой данных.

Вот несколько причин, по которым вам это может понадобиться:

• Приложение кэширует только то, что ему нужно, поэтому вы должны получить более высокий коэффициент попадания в кеш.
• Доступ к локальному кешу, вероятно, будет быть на пару порядков быстрее, чем доступ к базе данных из-за задержки в сети - даже с быстрой сетью

Вопросы производительности, связанные с сетевым обменом, были правильно указаны.

К этому следует добавить, что кэширование данных где-либо еще, кроме dbms (НЕ «база данных»), создает проблему потенциально устаревших данных, которые все еще представляются как «обновленные».

Подавление соблазну повышения производительности происходит за счет потери гарантии (водонепроницаемости или, по крайней мере, близкой к ней) абсолютно надежных и гарантированно правильных и последовательных данных.

Учитывайте это каждый раз, когда точность и последовательность имеют решающее значение.

Здесь много хороших ответов. Я добавлю еще один момент: я знаю свой шаблон доступа, а база данных - нет.

В зависимости от того, что я делаю, я знаю, что если данные окажутся устаревшими, это не проблема. БД этого не делает, и ей придется перезагрузить кеш с новыми данными.

Я знаю, что в ближайшее время я еще несколько раз вернусь к фрагменту данных, поэтому важно не забывать об этом. БД должна угадывать, что хранить в кеше, у нее нет той информации, которая есть у меня. Поэтому, если я получаю его из БД снова и снова, он может не находиться в кеше, если сервер занят. Я мог получить промах кеша. С моим кешем я могу быть уверен, что получу удар. Это особенно верно для данных, которые нетривиально получить (например, несколько объединений, некоторые групповые функции), а не только одну строку. Получить строку с первичным ключом 7 легко для БД, но если ей нужно проделать некоторую реальную работу, стоимость промаха кеша будет намного выше.