Резюме пяти стратегий в процессе использования кеша и анализ сочетания преимуществ и недостатков

Сегодня я перевел статью о стратегиях кеширования.Оригинальное название: Стратегии кеширования и как выбрать правильную.Его порекомендовал друг, и я думаю, что краткое содержание хорошее.Поскольку многим моим друзьям лень читать по-английски, Пиппи использует хромой уровень. Попробуйте перевести волну, если вы считаете, что это нормально, вы можете помочь переслать ее, чтобы ее увидело больше людей.

Кэширование — один из самых простых способов повысить производительность системы. Условно говоря, скорость базы данных (или базы данных NoSQL) относительно низкая, а скорость часто является ключом к победе.

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

Система больше пишет и меньше читает? (например, журналы по времени)
Данные записываются один раз и считываются много раз? (например, профиль пользователя)
Всегда ли возвращаемые данные уникальны? (например, поисковый запрос)

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

Первый: кэш

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

Кратко объясните:

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

Стратегия Cache-aside особенно подходит для приложений с большим количеством операций чтения. Системы, использующие Cache-aside, несколько устойчивы к инвалидации кэша. Если кластер кэша выходит из строя, система по-прежнему может работать, обращаясь к базе данных напрямую. (Однако это не сильно помогает, если кеш падает во время пиковых нагрузок. Время отклика может стать очень плохим, и в худшем случае база данных может перестать работать.)

Еще одним преимуществом является то, что модель данных в кеше может отличаться от модели данных в базе данных. Например, ответы на несколько запросов могут храниться по определенному идентификатору запроса.

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

Второй: Кэш Read-Though

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

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

Несмотря на то, что сквозное чтение и кэширование очень похожи, есть по крайней мере два ключевых различия:

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

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

Третий тип: кэш со сквозной записью

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

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

DynamoDB Accelerator (DAX) — хороший пример кэша сквозной записи/чтения. Он встроен в DynamoDB и приложения. Чтение и запись DynamoDB может выполняться с помощью DAX. (Примечание. Если вы планируете использовать DAX, обязательно ознакомьтесь с его моделью согласованности данных и тем, как он взаимодействует с DynamoDB.)

Четвертая запись вокруг

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

Пятая обратная запись

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

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

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

Суммировать

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

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