Oracle Analytics Cloud поддерживает локальный кэш наборов результатов запросов в кэше запросов.
Темы:
Кэш запросов позволяет Oracle Analytics Cloud обрабатывать множество последующих запросов без обращения к источникам внутренних данных, что повышает эффективность обработки запросов. Однако записи кэша запросов могут устаревать по мере обновления внутренних источников данных.
Самый быстрый способ обработки запроса — пропустить часть обработки и использовать предварительно вычисленный ответ.
Благодаря кэшированию запросов Oracle Analytics Cloud сохраняет предварительно рассчитанные результаты запросов в локальном кэше. Если другой запрос может использовать эти результаты, все операции в базе данных, выполняемые для этого запроса, исключаются. Это может привести значительно уменьшить среднее время отклика на запросы.
Помимо повышения производительности, возможность получения ответа на запрос из локального кэша экономит сетевые ресурсы и снижает время обработки на сервере базы данных. Ресурсы сети сохраняются, поскольку промежуточные результаты не возвращаются в Oracle Analytics Cloud. Если запрос не обрабатывается в базе данных, сервер базы данных освобождается для выполнения другой работы. Если база данных использует систему возврата оплаты, то выполнение меньшего количества запросов также может сократить бюджетные расходы.
Еще одно преимущество использования кэша для получения ответа на запрос — экономия времени обработки в Oracle Analytics Cloud, особенно если результаты запроса извлекаются из нескольких баз данных. В зависимости от запроса, сервер может быть существенно загружен обработкой операций объединения и сортировки. Если запрос уже рассчитан, то такая обработка исключается, освобождая ресурсы сервера для других задач.
Таким образом, кэширование запросов может значительно повысить эффективность выполнения запросов и сократить сетевой трафик, обработку баз данных и накладные расходы на обработку.
У кэширования запросов множество очевидных преимуществ, но также есть и определенные затраты.
Возможность устаревания кэшированных результатов
Административные расходы на управление кэшем
Благодаря управлению кэшем преимущества, как правило, значительно превосходят затраты.
Некоторые административные задачи связаны с кэшированием. Необходимо правильно задать время сохраняемости кэша для каждой физической таблицы, зная, как часто обновляются данные в этой таблице.
При изменении частоты обновления необходимо отслеживать время внесения изменений и при необходимости очищать кэш вручную.
Если записи кэша не удаляются при изменении данных в основных базах данных, в ответ на запросы потенциально могут возвращаться устаревшие результаты.
Необходимо оценить, приемлемо ли это. Возможно, следует разрешить содержание устаревших данных в кэше. Необходимо определить, какой уровень устаревших данных приемлем, а затем настроить набор правил (и следовать им) для отражения таких уровней.
Например, предположим, что приложение анализирует корпоративные данные из большого конгломерата, а вы составляете ежегодные сводки по различным подразделениям компании. Новые данные не оказывают существенного влияния на запросы, поскольку новые данные влияют только на сводки следующего года. В этом случае компромиссом при принятии решения о необходимости очистки кэша может быть оставление записей в кэше.
Предположим, что базы данных обновляются три раза в день, а вы выполняете запросы по операциям текущего дня. В этом случае кэш необходимо очищать гораздо чаще, или, возможно, не использовать его вообще.
Еще один сценарий: набор данных периодически (например, один раз в неделю) перестраивается с самого начала. В этом примере в процессе перестроения набора данных можно очистить весь кэш, чтобы не использовать устаревшие данные в кэше.
Какова бы ни была ситуация, необходимо оценить, что приемлемо для неактуальной информации, возвращаемой пользователям.
Если для определенного пула подключений включен общий вход, то кэш может совместно использоваться всеми пользователями и не требуется его заполнять для каждого пользователя.
Если общий вход не включен и используется вход в базу данных на основе имени пользователя, для каждого пользователя создается собственная запись кэша.
В Oracle Analytics Cloud кэш запросов включен по умолчанию. Кэширование запросов можно включить или отключить на странице Расширенные системные настройки.
Для управления изменениями в базовых базах данных и мониторинга записей кэша необходимо разработать стратегию управления кэшем.
Вам нужен процесс для аннулирования записей кэша при изменении данных в базовых таблицах, составляющих запись кэша, а также процесс для отслеживания, идентификации и удаления любых нежелательных записей кэша.
В этом разделе рассматриваются следующие вопросы:
Выбор стратегии управления кэшем зависит от изменчивости данных в базовых базах данных и предсказуемости изменений, которые вызывают эту изменчивость.
Это также зависит от количества и типов запросов, составляющих кэш, и от использования полученных запросов. В этом разделе представлен обзор различных подходов к управлению кэшем.
Кэширование можно отключить для всей системы, чтобы остановить внесение всех новых записей в кэш и остановить использование существующего кэша новыми запросами. Отключенное кэширование можно включить позже, не теряя записей, хранящихся в кэше.
Временное отключение кэширования — это полезная стратегия, если есть подозрения в наличии устаревших записей в кэше и требуется проверить, действительно ли они устарели, прежде чем удалять эти записи или весь кэш. Если данные, хранящиеся в кэше, остаются актуальными или после безопасного удаления проблемных записей, можно безопасно включить кэш. Перед повторным включением кэша при необходимости очистите весь кэш или его часть, связанную с определенной бизнес-моделью.
Для каждой физической таблицы можно задать кэшируемый атрибут, позволяющий указать, добавлены ли запросы для этой таблицы в кэш, чтобы отвечать на будущие запросы.
Если включено кэширование для таблицы, в кэш добавляется любой запрос, связанный с этой таблицей. По умолчанию все таблицы доступны для кэширования, но некоторые таблицы могут не являться хорошими кандидатами на настроил рабочий кэш, если не заданы настройки времени сохраняемости кэша. Например, предположим, что есть таблица с биржевыми сводками, которые обновляются каждую минуту. Можно включить удаление записей из этой таблицы каждые 59 секунд.
Можно также использовать настройки времени сохраняемости кэша, чтобы задать время хранения записей для этой таблицы хранятся в кэше запросов. Это полезно для часто обновляемых источников данных.
В инструменте администрирования моделей, на физическом уровне дважды щелкните по физической таблице.
Если вы используете средство семантического моделирования, см Что такое общие свойства физической таблицы?.
В диалоговом окне свойств "Физическая таблица" на вкладке "Общие" выберите один из следующих вариантов:
чтобы включить кэширование, установите флажок Кэшируемая;
чтобы предотвратить кэширование таблицы, снимите флажок Кэшируемая.
Чтобы задать время истечения срока действия кэша, укажите время сохраняемости кэша и единицу измерения (дни, часы, минуты или секунды). Если требуется, чтобы срок действия записей в кэше не истекал автоматически, выберите Кэш действует бессрочно.
Нажмите ОК.
Изменение семантических моделей с помощью средства семантического моделирования моделей или инструмента администрирования моделей может иметь повлиять на записи, которые хранятся в кэше. Например, при изменении определения физического объекта или динамической переменной семантической модели записи кэша, ссылающиеся на этот объект или переменную, могут оказаться недействительными. Такие изменения могут привести к необходимости очистки кэша. Есть два сценария: изменение существующей семантической модели и создание (или загрузка) новой семантической модели.
Изменение семантической модели
При изменении семантической модели или загрузке другого файла .rpd любые изменения, влияющие на записи кэша, автоматически приводят к очистке всех записей кэша, ссылающихся на измененные объекты. Очистка выполняется при загрузке таких изменений. Например, если из семантической модели удалить физическую таблицу, все записи кэша, которые ссылаются на эту таблицу, будут удалены при регистрации. Любые изменения семантической модели, внесенные на логическом уровне, приводят к удалению всех записей кэша для этой семантической модели.
Изменения глобальных переменных семантических моделей
Значения глобальных переменных семантической модели обновляются с учетом данных, возвращаемых в ответ на запросы. При определении глобальной переменной семантической модели создается блок инициализации или используется существующий блок с SQL-запросом. Также можно настроить расписание для выполнения запроса и периодического обновления значения такой переменной.
Если значение глобальной переменной семантической модели изменяется, любая запись кэша, которая использует эту переменную в столбце, становится устаревшей, и создается новая запись кэша, когда снова нужны данные в этой записи. Старая запись кэша удаляется не сразу, а остается до тех пор, пока не будет очищена с помощью обычного механизма кэширования.
Одно из основных преимуществ кэширования запросов — повышение воспринимаемой эффективности обработки запросов.
Кэширование запросов может оказаться полезным для заполнения кэша в нерабочее время при обработке запросов и кэшировании результатов. Хорошая стратегия первоначального заполнения требует знания времени попаданий в кэш.
Если требуется использовать кэш для всех пользователей, можно заполнить кэш следующим запросом:
SELECT User, SRs
После заполнения кэша с помощью команды SELECT User, SR следующие запросы служат попаданиями в кэш:
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1) SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2) SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)
В этом разделе рассматриваются следующие вопросы:
Когда кэширование включено, каждый запрос оценивается, чтобы определить, подходит ли он для попадания в кэш.
Попадание в кэш означает, что платформе Oracle Analytics Cloud удалось использовать кэш для получения ответа на запрос и вообще не пришлось обращаться к базе данных. Oracle Analytics Cloud может использовать кэш запросов для получения ответа на запросы на том же или более высоком уровне агрегирования.
Наличие кэша зависит от многих факторов. Эти факторы описаны в таблице ниже.
| Фактор или правило | Описание |
|---|---|
|
Подмножество столбцов в списке |
Все столбцы в списке Это правило описывает минимальное требование для попадания в кэш, но соблюдение этого правила не гарантирует попадания в кэш. Также применяются другие правила, перечисленные в этой таблице. |
|
Столбцы в списке |
Oracle Analytics Cloud может вычислять выражения на основе кэшированных результатов для получения ответа на новый запрос, но все столбцы должны быть в кэшированном результате. Например, запрос SELECT product, month, averageprice FROM sales WHERE year = 2000 попадает в кэш для запроса SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000 так как |
|
Фраза |
Чтобы запрос соответствовал требованиям попадания в кэш, ограничения фразы Фраза
Кроме того, столбцы, используемые во фразе SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')
Не приводит к попаданию в кэш заполняющего запроса из предыдущего списка, так как REGION не находится в проекционном списке. |
|
Запросы только для измерений должны быть полным совпадением |
Если запрос относится только к измерениям, то есть в запрос не входит факт или показатель, то только при полном совпадении проекционных столбцов кэшированного запроса имеет место попадание в кэш. Такое поведение предотвращает ложное срабатывание при наличии нескольких логических источников для таблицы измерений. |
|
Запросы со специальными функциями должны быть полным совпадением |
Другие запросы, которые содержат специальные функции, такие как функции временных рядов ( |
|
Набор логических таблиц должен совпадать |
Чтобы соответствовать требованиям попадания в кэш, все входящие запросы должны иметь тот же набор логических таблиц, что и запись в кэше. Это правило позволяет избежать ложных попаданий в кэш. Например, |
|
Значения переменных сеанса должны совпадать, включая переменные сеанса безопасности |
Если логическая или физическая инструкция SQL ссылается на любую переменную сеанса, значения переменных сеанса должны совпадать. В противном случае нет попадания в кэш. Кроме того, значение переменных сеанса, зависимых от режима безопасности, должно совпадать со значениями переменных сеанса безопасности, определенным в семантической модели, даже если сама логическая инструкция SQL не ссылается на переменные сеанса. См. раздел Обеспечение корректности результатов в кэше при использовании защиты базы данных на уровне строк. |
|
Эквивалентные условия соединения |
Результирующая объединенная логическая таблица новой заявки запроса должна совпадать с кэшированными результатами (или их подмножеством), чтобы соответствовать критериям попадания в кэш. |
|
Атрибут |
Если кэшированный запрос удаляет дубликаты записей с обработкой инструкции |
|
Запросы должны содержать совместимые уровни агрегирования |
Запросы, запрашивающие агрегированный уровень информации, могут использовать кэшированные результаты с более низким уровнем агрегирования. Например, следующий запрос запрашивает количество товаров, проданных на уровне поставщика, региона и города: SELECT supplier, region, city, qtysold FROM suppliercity Следующий запрос запрашивает количество товаров, проданных на уровне города: SELECT city, qtysold FROM suppliercity Второй запрос приводит к попаданию в кэш для первого запроса. |
|
Ограниченное дополнительное агрегирование |
Например, если запрос со столбцом |
|
Фраза |
Запросы, упорядоченные по столбцам, которых нет в списке выбора, приводят к кэш-промахам. |
|
Диагностика поведения попаданий в кэш |
Чтобы лучше оценить поведение попаданий в кэш, задайте переменной сеанса ENABLE_CACHE_DIAGNOSTICS значение 4, как показано в следующем примере: ENABLE_CACHE_DIAGNOSTICS=4 |
При использовании стратегии защиты базы данных на уровне строк, например виртуальной частной базы данных (VPD), результаты возвращенных данных зависят от учетных данных для авторизации пользователя.
Поэтому платформе Oracle Analytics Cloud должно быть известно, используется ли в источнике данных защита баз данных на уровне строк и какие переменные имеют отношение к безопасности.
Чтобы попадания в кэш происходили только в записях кэша, которые содержат и соответствуют всем чувствительным к безопасности переменным, необходимо правильно настроить объекты баз данных и переменных сеансов в инструменте администрирования моделей.
Объект базы данных. На физическом уровне на вкладке "Общие" диалогового окна "База данных" выберите Виртуальная частная база данных, чтобы указать, что в источнике данных используется защита баз данных на уровне строк.
Если используется защита базы данных на уровне строк с общим кэшированием, необходимо выбрать этот параметр, чтобы запретить общий доступ к записям кэша, чьи чувствительные к безопасности переменные не совпадают.
Объект переменной сеанса. Для переменных, связанных с безопасностью, в диалоговом окне "Переменная сеанса" выберите Зависит от режима безопасности, чтобы определить их как зависимые от режима безопасности при использовании стратегии защиты базы данных на уровне строк. При этом варианте записи кэша помечаются как чувствительные к безопасности переменные, что позволяет сопоставлять переменные, чувствительные к безопасности, для всех входящих запросов.
Одна из стратегий максимального увеличения количества потенциальных попаданий в кэш заключается в выполнении набора запросов для заполнения кэша.
Ниже приведены некоторые рекомендации по типам запросов, которые следует использовать при создании набора запросов для заполнения кэша.
Распространенные предварительно созданные запросы. Часто выполняемые запросы, особенно те, обработка которых затратна, превосходно подходят для заполнения кэша. Запросы, результаты которых встроены в инфопанели, служат хорошими примерами распространенных запросов.
Списки SELECT без выражений. Исключение выражений в столбцах со списками SELECT расширяет возможность попаданий в кэш. Кэшированный столбец с выражением может дать ответ только на новый запрос с таким же выражением; кэшированный столбец без выражений может дать ответ на запрос этого столбца с любым выражением. Например, кэшированный запрос, такой как:
SELECT QUANTITY, REVENUE...
может дать ответ на новый запрос, такой как:
SELECT QUANTITY/REVENUE...
но не наоборот.
Без фразы WHERE. Если в кэшированном результате отсутствует фраза WHERE, его можно использовать в ответах на запросы, которые соответствуют правилам попаданий в кэш для списка выбора с любой фразой WHERE, включающей столбцы в проекционном списке.
В общем, наилучшие запросы для заполнения кэша — это запросы, при выполнении которых сильно потребляются ресурсы базы данных и которые, вероятно, будут использоваться многократно. Будьте внимательны, чтобы не заполнять кэш простыми запросами, возвращающими много строк. Для таких запросов (например, SELECT * FROM PRODUCTS, где PRODUCTS сопоставляется непосредственно одной таблице базы данных) требуется очень небольшая обработка в базе данных. В их случае расходуются сетевые и дисковые ресурсы, что кэширование не устраняет.
Когда Oracle Analytics Cloud обновляет переменные семантической модели, проверяются бизнес-модели, чтобы определить, ссылаются ли они на эти переменные семантической модели. В этом случае Oracle Analytics Cloud очищает весь кэш для таких бизнес-моделей. См. раздел Влияние изменений семантической модели на кэш запросов.
Агенты можно настроить для заполнения кэша запросов Oracle Analytics Cloud.
Заполнение кэша может сократить время отклика для пользователей при выполнении анализов или просмотре анализов, встроенных в их инфопанели. Для этого можно запланировать выполнение агентами запросов на обновление этих данных.
Единственное различие между агентами заполнения кэша и другими агентами заключается в том, что, когда они автоматически очищают предыдущий кэш, на инфопанели не отображаются оповещения.
Примечание.:
Агенты заполнения кэша очищают только запросы с полным совпадением, поэтому устаревшие данные могут по-прежнему существовать. Убедитесь, что стратегия кэширования всегда включает очистку кэша, поскольку запросы агентов не охватывают специальные запросы или детализацию.При очистке кэша из кэша запросов удаляются записи и контент остается актуальным. Записи кэша для определенных таблиц можно очищать автоматически, настроив поле Время сохраняемости кэша в инструменте администрирования моделей для каждой таблицы.
Примечание.:
Если вы используете средство семантического моделирования, см. раздел "Что такое общие свойства физической таблицы?"
Это полезно для часто обновляемых источников данных. Например, если есть таблица, в которой хранятся биржевые сводки, обновляемые каждую минуту, настройку Время сохраняемости кэша можно использовать, чтобы очищать записи кэша для этой таблицы каждые 59 секунд. См. раздел "Время кэширования и сохраняемости кэша для указанных физических таблиц".