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

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

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

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

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

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

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

Возможные элементы дизайна

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

Товары

• Диван - https://www.couchbase.com/caching
• NCache
• Redis - Распределенная система баз данных в памяти, которая также поддерживает различные сценарии распределенного кэширования.
• GigaSpaces - InsightEdge SmartCache
• CSQL Кэш - Для кеширования таблиц из MySQL, Postgres и Oracle.
• memcached- Кэшировать набор результатов запросов
• Кэширование Windows Azure- Кэшировать набор результатов запросов в Windows Azure
• TimesTen - Для кеширования таблиц ORACLE
• SafePeak - Автоматическое кэширование наборов результатов запросов и процедур из SQL Server с автоматическим удалением кеша для полной корректности данных
• Apache Ignite
• Системы GridGain
• Тарантоол - БД с открытым исходным кодом, кеш-память в памяти с полным сервером приложений Lua
• Heimdall Data - Коммерческий механизм кэширования SQL для Postgres, SQL Server, MySQL и любых источников данных JDBC с автоматическим удалением кеша и многими другими функциями

Рекомендации

внешняя ссылка

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