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

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

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

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

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

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

Потенциальные элементы дизайна

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

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

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

Ссылки

1. Ларсон, Пер-Аке; Голдштейн, Джонатан (2004). "MTCache: Прозрачное кэширование баз данных среднего уровня". CiteSeerX  10.1.1.95.875 . {{cite journal}}: Цитировать журнал требует |journal=( помощь )
2. Altinel, Mehmet; Luo, Qiong; Krishnamurthy, Sailesh; Mohan, C.; Pirahesh, Hamid; Lindsay, Bruce G.; Woo, Honguk; Brown, Larry (2002). "DBCache: кэширование баз данных для серверов веб-приложений" (PDF) . CiteSeerX 10.1.1.104.8991 .  {{cite journal}}: Цитировать журнал требует |journal=( помощь )
3. "Кэширование баз данных среднего уровня для электронного бизнеса". CiteSeerX 10.1.1.140.8455 .  {{cite journal}}: Цитировать журнал требует |journal=( помощь )
4. «Почему базы данных должны обходить кэш страниц Linux». 13 марта 2024 г. Получено 2 апреля 2024 г.

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

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