Таблица 11.1. Таблица финансовых месяцев FISCAL MONTHS

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

Ясно, что для этой совершенно ненужной пересылки данных мы задействуем ресурсы сети и центрального процессора сервера. Очевидное решение - извлечь эти данные при первом обращении к ним пользовательского интерфейса, а затем хранить их на клиенте для обслуживания последующих запросов. Если объем этих данных невелик, то клиентское ПО может направлять запрос на их получение при запуске приложения на клиенте. Таким образом, программа пользовательского интерфейса всегда может рассчитывать на их наличие. Реализация этого механизма зависит от клиентского ПО. Например, в приложении на Visual С++ можно выделять память динамически и хранить эти данные в связанных списках. В Oracle Forms 4.5 для хранения кэшированных значений можно пользоваться группами записей.

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

Давайте в качестве примера рассмотрим таблицу, содержащую описание деталей. Может оказаться, что из перечисленных в ней 100000 деталей один клиент часто выбирает лишь 100. Если описания деталей в процессе обработки системой клиент/сервер никогда не изменяются (или допускается использование устаревшего описания), то можно реализовать на клиенте механизм движущегося кэша {rolling cache), или исключения давно использовавшихся данных (least recently used).

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

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

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

Самая серьезная проблема при любом виде кэша - простом или сложном - заключается в том, что если отсутствует промежуточное ПО, скрывающее кэш, то программа пользовательского интерфейса должна знать о существовании кэша и уметь запрашивать из него данные. Таким образом, независимо от того, используется промежуточное ПО или нет, выборка данных, которые могут быть локально кэшированы, не должна осуществляться через SQL, за исключением случая, когда на клиенте работает экземпляр базы данных - однако при этом мы уже имеем дело не только с архитектурой клиент-сервер, а еще и с распределенной базой данных. (Эта тема изложена здесь с точки зрения вычислений клиент/сервер. Более подробно распределение данных рассматривается в главе 12.)

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

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

Кэш на стороне клиента - анализ проблемы

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

Клиент/сервер и распределенные базы данных

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

Если данные извлечь из базы данных и поместить во внешние файлы, могут возникнуть очень сложные проблемы. Конечно, мы можем обновлять эти файлы каждый вечер, чтобы обеспечить актуальность данных, однако преимущество хранения их в базе данных состоит в том, что РСУБД сама гарантирует их целостность. Как только мы начинаем полагаться на данные, хранящиеся вне базы данных, мы открываем путь нарушению целостности. Например, кто-нибудь может отредактировать - случайно или намеренно - локальный файл. Если вечером часть сети выйдет из строя и мы не выполним обновление, может оказаться, что наш файл не будет соответствовать файлам других пользователей. Конечно, можно написать скрипты, которые будут ползать по сети и проверять актуальность каждой копии, но ведь цель всех наших усилий - уменьшить сетевой трафик.

К тому же, очень немногие ориентированные на базы данных клиентские средства сильны в файловом вводе-выводе. Необходимо подумать и том, как достичь приемлемой производительности при обработке запросов. Допустим, что при необходимости хранить важные данные локально, мы будем хранить их в базе данных (либо Oracle, либо не-0гас1е). Кроме того, предположим, что локальная база данных представляет собой версию Oracle,