Кэширование базы данных

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

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

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

Преимущества

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

дизайна

• Обновляемые таблицы кэша. Многие системы кэширования доступны только для чтения, что ограничивает их использование небольшим сегментом приложений, не работающих в режиме реального времени.
• Двунаправленные обновления. Для обновляемых кэшей обновления, которые происходят в кэше, должны распространяться на целевую базу данных, а любые обновления, которые происходят непосредственно в целевой базе данных, должны поступать в кэш автоматически.
• Синхронное и асинхронное распространение обновлений. Обновления таблицы кэша должны распространяться в целевую базу данных в двух режимах. Синхронный режим гарантирует, что после завершения операции с базой данных обновления будут применены и в целевой базе данных. В случае асинхронного режима обновления целевой базы данных задерживаются. Синхронный режим обеспечивает высокую согласованность кэша и подходит для приложений реального времени. Асинхронный режим обеспечивает высокую пропускную способность и подходит для приложений, близких к реальному времени.
• Множественная степень детализации кэша — уровень базы данных, уровень таблицы и кэширование набора результатов: основные части корпоративных баз данных являются историческими и к ним редко обращаются. Но есть некоторая информация, которая должна быть доступна мгновенно, например данные премиум-клиентов и т. д.
• Восстановление кэшированных таблиц. В случае сбоя системы или сбоя питания во время перезапуска платформы кэширования все зафиксированные транзакции в кэшированных таблицах должны быть восстановлены.
• Инструменты для проверки согласованности кэша. В случае асинхронного режима распространения обновлений кэш на разных узлах кэша и целевой базе данных могут расходиться. Эту проблему необходимо решать вручную, выявляя несоответствия и при необходимости принимая корректирующие меры.
• Горизонтальное масштабирование. Кластерные вычисления могут повысить доступность и обеспечить балансировку нагрузки. Кэширование в кластерной среде охватывает несколько узлов, обеспечивая согласованность кэшированных данных на всех узлах.
• Прозрачный доступ к некешированным таблицам находится в целевой базе данных: Кэш базы данных должен отслеживать запросы и иметь возможность интеллектуального маршрутизации к кэшу базы данных или к исходной базе данных на основе местоположения данных без какой-либо модификации кода приложения .
• Прозрачное аварийное переключение: в случае сбоя платформы кэширования не должно быть никаких перебоев в обслуживании. Клиентские соединения должны быть перенаправлены к целевой базе данных.
• Никаких изменений в приложении или очень мало: поддержка стандартных интерфейсов JDBC, ODBC и т. д., которые обеспечивают бесперебойную работу приложения без каких-либо изменений кода приложения. Он должен направлять все вызовы хранимых процедур в целевую базу данных, чтобы их не нужно было переносить.
• Внедрите специализированный внутренний кеш: ориентированные на производительность базы данных, такие как ScyllaDB, полностью обходят кеш Linux во время чтения и вместо этого используют встроенный внутренний кеш на основе строк.

Подводные камни в реализации

• Обращение кеширования при событиях удаления или аннулирования. Проекты кэширования, в которых используются внешние механизмы кэширования, такие как Redis или Hazelcast, часто вызывают аннулирование, выполняя удаления недействительных объектов. Это может привести к тому, что одна операция записи вызовет тысячи удалений, что повлияет на производительность.
• Отсутствие отслеживания ключей. Опять же, при использовании внешнего механизма кэширования любой запрос часто запускает поиск ключа на уровне кэша. Если это промах, это может вызвать дополнительный RTT, увеличивая общую задержку запросов. Однако такие механизмы, как Redis и Hazelcast, обеспечивают поддержку уведомлений об изменении ключей, позволяя обновлять локальные слои кэша при изменении ключей на удаленном уровне кэша. Отслеживая эти ключи локально, можно избежать удаленных поисков при промахе в кэше, предотвращая штраф за попадание в кэш.
• Аннулирование как мгновенное событие, а не временной диапазон: когда таблица должна быть изменена как часть транзакции, режим SQL может повлиять на то, должен ли запрос по другому соединению увидеть изменения или нет. Таким образом, хотя транзакция еще не была зафиксирована или откатана, любое изменение в таблице во время транзакции должно привести к тому, что таблица будет считаться нестабильной до тех пор, пока транзакция не будет завершена. Часто механизмы кэширования аннулируют результат только до или после выполнения запроса.
• Распределенные кеши с отсутствием связи. Если в конструкции кеша используется базовый уровень хранения, при использовании в качестве распределенного кеша аннулирование выполняется локально в зависимости от того, в какие таблицы записываются в данный момент. К сожалению, другие узлы могут иметь записанные объекты кэша для той же таблицы, и эти объекты не будут признаны недействительными. При использовании для данных локального сеанса с сохранением восходящего клиента это может быть приемлемо, но для общих данных, которые должны поддерживать согласованность между сеансами, это может вызвать проблемы с согласованностью данных.

Внешние ссылки

• Кэширование базы данных среднего уровня для электронного бизнеса