• Используемые соглашения
• Документация по TimesTen
• Дополнительные источники
• Техническая поддержка

1. Что такое TimesTen?
   • Почему TimesTen быстрее, чем обычная база данных?
   • Сравнение TimesTen и обычной базы данных
     • Стандартные интерфейсы ODBC/JDBC
     • SQL
     • Управление доступом
     • Распределенные транзакции
     • Возможность соединения баз данных
     • Журнализация
     • Наблюдение за журналом транзакций и материализованными представлениями
     • Контрольные точки
     • Репликация
     • Кэширование данных Oracle
     • Оптимизация запросов
     • Параллелизм
     • Администрирование и утилиты
2. Как используется TimesTen
   • Общее использование TimesTen
   • Типовые приложения TimesTen
     • Сценарий 1: измерение характеристик звонков
     • Сценарий 2: обслуживание котировок в реальном времени
     • Сценарий 3: оперативное туристическое агентство
   • Обсуждение проектов приложений
     • Вариант 1
     • Вариант 2
     • Вариант 3
     • Архитектурные компромиссы
     • Резюме возможностей проектирования
3. Структура системы TimesTen
   • Сборки данных TimesTen
     • Пользователь и системные DSN
   • Менеджер данных TimesTen
     • Процессы TimesTen
   • ODBC и JDBC API в TimesTen
     • Стандарт SQL-92
     • Встроенные процедуры TimesTen
     • API распределенной обработки транзакций
     • API журнала транзакций
   • Где найти дополнительную информацию
4. Как приложения соединяются со сборками данных
   • Непосредственное операторское соединение
   • Эксклюзивные и разделяемые сборки данных
   • Соединение клиент/сервер
   • Менеджер операторского соединения
   • Где найти дополнительную информацию
5. Параллельные действия
   • Блокировки
   • Блокировки уровня сборки данных
     • Блокировки табличного уровня
     • Блокировки уровня строки
     • Защелки
   • Изоляция транзакций
     • Сериализабельность
     • Фиксирование по чтению
   • Оптимизация масштабирования симметричной мультипроцессорной установки
   • Где найти дополнительную информацию
6. Оптимизации запросов
   • Оптимизация по времени и использованию памяти
   • Статистика
   • Подсказки для оптимизатора
   • Методы индексации
     • Хешированные индексы
     • Индексы T-дерева
   • Методы сканирования
   • Методы соединения
     • Вложенный цикл соединения
     • Сортировка соединения
   • План оптимизатора
   • Где найти дополнительную информацию
7. Готовность и целостность данных
   • Журнализация
     • Опции журнализации
     • Автофиксирование
     • Долговременное и недолговременное фиксирование
     • Когда удалять файлы системного журнала?
   • Организация контрольных точек
     • Блокированные и неблокированные ("нечеткие") контрольные точки
     • Восстановление по журнальным файлам и контрольным точкам
   • Репликация
     • Конфигурации репликаций
     • Активная резервная пара
     • Асинхронное и возвратное обслуживание транзакций
     • Отказоустойчивая репликация и восстановление
   • Где найти дополнительную информацию
8. Уведомление о событиях
   API журнала транзакций
   • Как работает XLA
   • Изменение записей журнала
   • Материализованные представления
     • Материализованные представления и XLA
   • SNMP-сообщения
   • Где найти дополнительную информацию
9. Кэш-соединение к Oracle
   • Кэш-группы
   • Загрузка и обновление кэш-групп
     • Обновление (освежение) Oracle-to-TimesTen
     • Обновление (тиражирование)TimesTen-to-Oracle
     • Возможность обхода
   • Системное управление кэш-группами
   • Пользовательское управление кэш-группами
     • Экземпляры кэша
     • Методы загрузки кэша
     • Старение экземпляров кэша
   • Реплицирование кэш-групп
   • Где найти дополнительную информацию
10. Администрирование TimesTen
    • Инсталляция TimesTen
    • Контроль доступа TimesTen
    • Администрирование на уровне командной строки
    • SQL-администрирование
    • Администрирование на уровне браузера
    • Модернизация TimesTen
      • Оперативная модернизация
      • Автономная модернизация
      • Диалоговая модернизация
    • Где найти дополнительную информацию
11. Индекс

[От редакции OM/RE: Этот документ входит в комплект документации по Oracle TimesTen™ In-Memory Database. В виду его большого объема в данной публикации приводится перевод только первой и второй его глав: "Что такое TimesTen?" и "Как используется TimesTen". Для того, чтобы читатели имели представление о структуре, содержании и объеме всего текста, специально полностью переведено оглавление этого обзора архитектуры продукта.
Если наши читатели проявят интерес к данной тематике, мы продолжим перевод и публикацию фрагментов документации.]

Техническая Поддержка

За информацией о получении технической поддержки по продуктам TimesTen следует обратиться по следующему Web-адресу: http://www.oracle.com/support/contact.html
Email: timesten-support_us@oracle.com

Глава 1 "Что такое TimesTen?"

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

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

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

Почему TimesTen быстрее, чем обычная база данных?

В обычной RDBMS клиентские приложения связываются с процессами сервера базы данных при помощи какого-либо протокола, например, IPC, что существенно снижает производительность всех SQL-операций. Приложение может связаться TimesTen непосредственно в своем адресном пространстве, что устраняет накладные расходы IPC и упрощает обработку запроса. Это достигается через direct connection (прямую связь) с TimesTen. Клиент/серверные соединения также доступны приложениям. С точки зрения приложения, API (программный интерфейс приложения) TimesTen одинаков, является ли это прямой связью или клиент/серверным соединением.

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

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

TimesTen же, со своей стороны, разработан в предположении, что данные находятся в оперативной памяти, и поэтому он может выбрать более прямые маршруты к данным, сокращая длину пути кода (code path) и упрощая как его алгоритм, так и структуру.

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

Рисунок 1.1 Сравнение реляционной (RDBMS) базы данных с памятью на дисках и TimesTen

Сравнение TimesTen и обычной базы данных

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

Стандартные ODBC/JDBC интерфейсы

TimesTen поддерживает ODBC версии 2.5 и JDBC версии 1.2. В отличие от многих других систем баз данных, где поддержка программных интерфейсов ODBC и/или JDBC может быть намного медленнее, чем собственный интерфейс, ODBC и JDBC являются исконно присущими интерфейсами TimesTen, которые работают непосредственно с механизмом базы данных. TimesTen поддерживает версии этих API, которые и полностью соответствуют стандартам, и настроены на максимальную производительность в среде TimesTen.

Дополнительная информация о TimesTen ODBC и поддержке JDBC более подробно представлена в разделе “TimesTen ODBC and JDBC APIs” [вне рамок этого перевода – прим.OM/RE]

SQL

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

Дополнительная информация о поддержке SQL и использовании его для административных действий более подробно представлена в разделах “SQL-92 standard” и “SQL Administration” [вне рамок этого перевода – прим.OM/RE]

Управление доступом

TimesTen может быть установлен с дополнительным уровнем управления пользовательским доступом, что позволяет возможность Access Control (Управление Доступом). Управление доступом в TimesTen применяет стандартные SQL-операции, чтобы установить учетную запись пользователя TimesTen с определенными уровнями привилегий.

Дополнительная информация о TimesTen Access Control более подробно представлена в разделе “TimesTen Access Control” [вне рамок этого перевода – прим.OM/RE]

Распределенные транзакции

TimesTen поддерживает распределенные транзакции через интерфейсы JTA и XA. Эти стандартные интерфейсы позволяют TimesTen взаимодействовать с менеджерами транзакций (transaction managers) в средах обработки распределенных транзакций (DTP - distributed transaction processing).

Дополнительная информация представлена в разделе “Distributed Transaction Processing (DTP) APIs” [вне рамок этого перевода – прим.OM/RE]

Возможность соединения баз данных

Подобно большинству других систем баз данных TimesTen поддерживает клиент/серверные соединения. Для обеспечения более высокой производительности TimesTen также поддерживает прямые драйверные соединения, также как и соединения посредством драйвер-менеджера для приложений, которые хотят получить одновременный доступ к базам данных различных типов.

Это разнообразие вариантов соединений позволяет пользователям выбрать лучшее соотношение производительность/функциональность для их приложений. Прямые драйверные соединения наиболее быстрые; клиент/серверные соединения могут обеспечить большую гибкость; а соединения с использованием драйвер-менеджера обеспечивают поддержку ODBC-приложений, не ранее ODBC версии 2.5, а также одновременную поддержку нескольких систем управления базами данных от различных поставщиков.

Дополнительная информация о различных способах соединения приложений с TimesTen более подробно представлена в главе 4 “How Applications Connect to Data Stores ” [вне рамок этого перевода – прим.OM/RE]

Журнализация

TimesTen ведет журнал изменений и опционально может записывать его на диск. Этот журнал используется для:

• восстановления изменений, сделанных транзакциями, если имеет место авария приложения или сборки данных (data store) и необходимо восстановление
• отмены транзакций, для которых требуется откат (rolled back)
• реплицирования изменений в другие сборки данных TimesTen
• реплицирования изменений в базу данных Oracle
• обнаружения приложениями изменений в таблицам (используя XLA API).

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

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

Дополнительная информация об опциях журнализации более подробно представлена в разделе 7 глава “Logging”, а об опциях фиксирования - в главе “Durable and non-durable commits” [вне рамок этого перевода – прим.OM/RE]

Наблюдение за журналом транзакций и материализованными представлениями

Подобно некоторым другим системам баз данных TimesTen обладает API (прикладной программный интерфейс), который позволяет приложениям наблюдать за активностью изменений, чтобы породить действия вне базы данных. В TimesTen эта способность обеспечена Transaction Log API (или XLA), который позволяет приложениям наблюдать за изменяемыми записями, коль скоро они записаны в транзакционный журнал, и предпринимать различные действия, основанные на обнаруженных изменениях. Например, XLA-приложение может применить обнаруженные изменения в другой базе данных, которая могла быть как TimesTen, так и дисковой RDBMS. Другой тип XLA-приложения может просто уведомлять подписчиков, что имело место изменение процентной ставки.

TimesTen предусматривает материализованные представления, которые могут использоваться в соединении с API журнализации XLA, чтобы позволять получать уведомление о "событиях" ("events"), определенных SQL-запросами.

Дополнительная информация об API журнализации и материализованных представлениях представлена в главе 8 “Event Notification ” [вне рамок этого перевода – прим.OM/RE]

Контрольные точки

Подобно большинству систем баз данных TimesTen обладает способностью контрольной точки, которая работает в фоновом режиме и оказывает очень небольшое воздействие на приложения базы данных. Это называется "fuzzy" ("нечеткой") контрольной точкой. TimesTen также имеет блокированную (blocking) контрольную точку, которая не требует файлов системного журнала для восстановления.

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

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

Дополнительная информация о механизме контрольных точек представлена в разделе “Checkpointing” главы 7 [вне рамок этого перевода – прим.OM/RE]

Репликация

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

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

Такой диапазон вариантов репликаций позволяет пользователям определять оптимальный баланс в сложных соотношениях оперативной производительности, взаимодействия и отказоустойчивости (failover).

Дополнительная информация о репликации представлена в разделе “Replication” главы 7, а о модернизации в реальном времени – в разделе “Upgrading TimesTen” главы 10 [вне рамок этого перевода – прим.OM/RE]

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

Механизм Cache Connect позволяет использовать TimesTen как кэш базы данных Oracle. Эта особенность облегчает приложениям TimesTen хранение часто используемых или наиболее важных данных в одной или более копиях TimesTen, тогда как остающиеся данные, большая их часть, сохраняется в более медленной дисковой базе данных. Cache Connect может сконфигурирован так, чтобы автоматически передавать транзакции из базы данных Oracle в TimesTen и из TimesTen в базу данных Oracle. Кэшированные данные могут быть автоматически состарены (aged out), когда превышена вместимость кэша TimesTen.

Более детально Cache Connect описывается в главе 9 [вне рамок этого перевода – прим.OM/RE].

Оптимизация запросов

Подобно многим другим системам баз данных TimesTen обладает стоимостным оптимизатором запросов, который выбирает лучший план выполнения запроса, основываясь на таких факторах, как упорядоченность таблиц, и выбирает метод доступа.

Чувствительность стоимостного оптимизатора в TimesTen несколько выше, чем в дисковых системах, поскольку структура затрат системы, находящейся в оперативной памяти, отличается от дисковых систем, в которых доступ к диску является доминирующим фактором затрат. Поскольку доступ к диску для TimesTen - несущественный фактор, модель оптимизации затрат включает факторы, которые не рассматриваются оптимизаторами дисковых систем, например, стоимость оценки предикатов.

TimesTen использует два типа индексов: хешированный (hash) и t-дерево, и поддерживает два типа методов соединения: вложенный цикл (nested-loop) и сортировка слиянием (merge-join). Если необходимо, оптимизатор может создать временные индексы на лету.

Оптимизатор TimesTen также принимает подсказки (hints), которые придают приложениям гибкость, чтобы обеспечить компромисс между такими факторами как использование временной памяти и производительность.

Более детально стоимостной оптимизатор TimesTen и техника индексирования описываются в главе 6 в разделе “Query Optimization ” [вне рамок этого перевода – прим.OM/RE].

Параллелизм

Также как и все системы баз данных TimesTen всесторонне поддерживает совместно используемые (shared – разделяемые) сборки данных. Однако, в отличие от большинства систем, TimesTen обеспечивает большое количество возможностей, что позволяет пользователям в их системах определить оптимальный баланс между временем ответом, производительностью и/или транзакционной семантикой (transaction semantics).

Например, TimesTen обеспечивает специальный быстродействующий механизм соединения для сборок данных исключительного доступа (exclusively-accessed). При использовании разделяемых сборок данных доступ к такой сборке, к таблице или строке может быть сериализован (serialized), чтобы улучшить производительность.

Для сборок данных с чрезвычайно строгой транзакционной семантикой применяется изолированность [транзакций] на уровне Serializable (сериализуемость) . По умолчанию для неблокирующих операций применяется уровень изолированности Read Committed (фиксация по чтению [другое название этого уровня изолированности транзакций repeatable read – воспроизводимое чтение – прим. А.Бачин]) . Эти уровни изолированности [транзакций] соответствуют стандартам ODBC и применяются для обеспечения оптимальной производительности, поскольку они всякий раз, когда это можно, позволяют избежать копирования данных. Как определено в стандарте ODBC, для сборки данных TimesTen уровень изолированности может быть установлен по умолчанию, что может быть динамически изменено во времени выполнения для каждого соединения.

Наконец, TimesTen хорошо функционирует на машинах с одним или более процессорами. TimesTen может быть сконфигурирован так, чтобы взаимно увязать время ответа с числом доступных процессоров для [повышения] производительности.

Более детальная информация по управлению параллельными операциями в TimesTen приведена в главе 5 в разделе “Concurrent Operations ” [вне рамок этого перевода – прим.OM/RE].

Администрирование и утилиты

TimesTen поддерживает "типичные" утилиты базы данных, как-то: диалог на SQL, резервирование/восстановление, копирование (копируются данные между различными системами баз данных) и миграция (высокоскоростное копирование для перемещения данных между различными версиями TimesTen).

Подобно большинству других систем баз данных, SQL-структуры применяются для многих разных административных действий, типа создания индексов и изменения таблиц.

SQL-структуры также применяются TimesTen, чтобы установить репликацию (replication), кэш-соединение (Cache Connect) и материализованные представления (Materialized Views). Действующий через интернет администратор также в состоянии установить кэш-соединение.

Встроенные в TimesTen процедуры и функции языка C позволяют программное управление действиями и назначениями (settings – установками) TimesTen. Утилиты командной строки TimesTen позволяют пользователям наблюдать за состоянием соединений, блокировками, репликациями и так далее. Состояние [соединения] может быть также получено при использовании SQL-запросов SELECT к системным таблицам в схеме TimesTen. Например, в таблицу MONITOR в TimesTen записывается много статистических данных, которые полезны при анализе или в отладке приложения TimesTen.

Более детальная информация по администрированию TimesTen приведена в главе 10 в разделе “TimesTen Administration ” [вне рамок этого перевода – прим.OM/RE].

Глава 2. "Как применяется TimesTen"

В Главе 1 было показано , что TimesTen предоставляет многие возможности базы данных общего назначения, но с учетом особенностей функционирования в реальном времени. Эта глава описывает, как следует использовать TimesTen, чтобы реализовать приложения, которые требуют доступа к данным в реальном времени.

Данная глава разбита на следующие основные секции:

• Общие случаи применения TimesTen
• Прикладные сценарии TimesTen
• Разбор конструкций приложений

Общие случаи применения TimesTen

Обычно TimesTen может использоваться как:

• первичная база данных (primary database) для приложений в реальном времени. В этом случае все данные, необходимые приложению(ям) находятся в TimesTen.
• менеджер данных реального времени (real-time data manager) для определенных задач в общем потоке работ (workflow) в сотрудничестве с дисковыми RDBMS. Например, приложение составления телефонных счетов может собирать и хранить в TimesTen совсем недавние записи о звонках, в то время как информация о клиентах, их биллинговых адресах, авансовых платежах и так далее сохраняется в дисковой RDBMS. Он может также состарить [данные] и держать архив всех записей о звонках в дисковой базе данных. Таким образом, информация, к которой требуется доступ в реальном времени, находится в TimesTen, в то время как информация, применяемая в долговременном анализе, аудит- и архивные данные хранятся в дисковой RDBMS.
• утилита [обработки] данных (data utility), которая ускоряет критичные по производительности элементы архитектуры. Например, используя TimesTen как репозиторий для сообщений, можно реализовать систему организации очередей сообщений, которая обладает качествами живучести (persistence) и транзакционности.
• элемент интеграции данных (data integration point) для многочисленных источников данных, на основе которого могут быть построены новые приложения. Например, организация может накопить большие объемы информации, которая находится в нескольких источниках данных, но только подмножества этих данных могут понадобиться в ее ежедневным управлении бизнесом. Подходящая структура должна из различных источников данных вытянуть релевантную, нужную в данный момент информацию в одну оперативную сборку данных TimesTen, чтобы обеспечить централизованный репозиторий данных, представляющих непосредственный интерес для приложений.

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

Прикладные сценарии TimesTen

Эта секция приводит несколько прикладных сценариев, в которых показано, как встраивается TimesTen в полное решение управления данными.

Ниже рассматриваются следующие прикладные сценарии:

Сценарий 1: приложение, собирающее сведения о телефонных вызовах” - использование TimesTen для хранения данных о показателях звонков по сотовым телефонам. Данные собираются в нескольких узлах TimesTen, которые равномерно распределены по зоне обслуживания, данные архивируются в центральной дисковой базе данных для использования централизованным биллинглвым приложением. Сценарий 2: приложение, обслуживающее котировки в реальном времени” - и спользование TimesTen для хранения сведений о котировках ценных бумаг, предназначенное для доступа к загруженным данным из программ торговых приложений.

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

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

В следующим тексте термин “сборка данных” (data store) определяет структуру памяти, в который содержится "база данных" TimesTen. Сборки данных рассматриваются в главе “TimesTen Data Stores” [вне рамок этого перевода – прим.OM/RE]

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

Сценарий 1: Приложение, собирающее сведения о телефонных вызовах

Компания NoWires Communications, оператор мобильной связи, применяет приложение "Учет использования" (usage metering), собирающее сведения о телефонных вызовах, которое отслеживает продолжительность каждого вызова с сотового телефона и потребляемые услуги. Например, если абонент делает обычный вызов, применяется базовый тариф по продолжительности звонка. Если абонент использует специальные возможности, например, роуминг, доступ к Интернет или трех сторонний вызов (3-way calling), накладываются дополнительные издержки.

Это приложение должно эффективно контролировать до 100 000 параллельных вызовов, собирать сведения об использовании по каждому звонку и сохранять данные в центральной базе для их обработки другими приложениями, которые выписывают счета (биллинг), продуцируют отчеты, сигналы и так далее.

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

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

Как показано на р исунке 2.1 , на каждом узле развернута комбинация приложения "Учет использования" и TimesTen, чтобы реализовать в реальном времени обработку вызовов от начала до завершения в разных, задаваемых междугородным кодом географических местах. По каждому вызову местный узел хранит отдельную запись от начала и до завершения вызова. Так сделано потому, что начало звонка с сотового телефона могло быть обнаружено одним узлом, а его завершением другим.

Рисунок 2.1 Распределенный сбор данных об использовании (Service Areas – области обслуживания)

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

Деятельность транзакциям (inserts/updates - вставка/обновление строк) в TimesTen должна быть надежной, поэтому используется журнализация на диск. Чтобы гарантировать готовность данных, каждый узел TimesTen реплицируется на горячий резервный узел (hot standby node).

Компания использует специальный компонент заднего плана, называемый Transfer Agent (Агент Перемещения), который запускается на каждом узле TimesTen. Как показано на рисунке 2.2 , Transfer Agent локально соединяется с TimesTen посредством драйвера ODBC, а также с удаленной базой данных посредством протокола IPC [вероятно, в оригинале ошибка, поскольку IPC применяется обычно во внутренних взаимодействиях процессов, но это в данном контексте не принципиально. – прим.А.Бачина]. Цель этого агента Transfer Agent состоит в том, чтобы периодически архивировать записи TimesTen в центральную базу данных, а также руководить отказоустойчивой репликацией и восстановлением, управлять контрольными точками и обновлять статистическую информацию. В случае отказа главного узла Transfer Agent передает абонентов резервному (redundant – избыточный) приложению "Учет использования" на резервном (standby) узле TimesTen.

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

Агент Transfer Agent периодически выбирает первые 5000 строк в таблице Calls и использует быстрые пакетные операции, чтобы заархивировать их в центральном RDBMS. (Ограничение набора SQL-выборки 'первыми N' значимыми строками обеспечивает малое воздействие на обработку вызовов в реальном времени и соблюдает приемлемый объем архивируемых данных.) После того, как Transfer Agent получает подтверждение об успешном архивировании записей вызовов в центральной базе данных, он удаляет их из TimesTen. Интервал, с которым работает Transfer Agent для архивирования вызовов, изменяется динамически на основании звонковой нагрузки и текущем размере сборки данных.

Рисунок 2.2 Transfer Agent архивирует записи о вызовах

Сценарий 2: приложение, обслуживающее котировки в реальном времени

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

Сервис котировок в реальном времени включает процесс NewsReader, который читает поступающие данные из канала сообщений в реальном времени, типа TIBCO SmartSockets ® или Rendezvous ™, который постоянно подпитывается данными новостного телеграфа. Каждый NewsReader соединяется с резервным NewsReader, который независимо читает данные из канала, и вставляют их в отдельную сборку данных TimesTen. Для создания избыточности канал сообщений используется как вилка входящих данных к двум сборкам данных TimesTen. В этом сценарии разветвление данные из канала сообщений более эффективно, чем использование репликации TimesTen.

Из каждой пары один NewsReader делает доступными торговому приложению данные по ценным бумагам, а другой служит горячим надежным резервом, который используется приложением в случае отказа. Текущая нагрузка требует четырех пар NewsReader, но еще больше пар NewsReader придется добавить в будущем, чтобы масштабировать сервис, чтобы поставить в реальном времени котировки другим типам Web-клиентов, по пейджеру, по сотовому телефону и так далее.

Рисунок 2.3 Сбор данных, поступающих по каналу сообщений

Как показано на рисунке 2.4, NewsReader обновляет данные курса акций в таблице Quotes в сборке данных TimesTen. Менее динамичные данные о доходах обновляются в таблице Earnings. Столбцы Stock в таблицах Quotes и Earningsа связаны через отношение внешнего ключа.

Питающий канал сообщений

Цель этого торгового приложения состоит в том, чтобы отслеживать только те акции, у которых отношение PE (price-earnings - отношение цены акции к доходу) ниже 50, затем использовать немного внутренней логики, чтобы проанализировать текущий курс акций и объем торговли и решить, совершать ли покупку, используя другие торговые механизмы. Для достижения максимальной производительности это торговое приложение применяет механизм событий, который использует механизм “ Transaction Log API (XLA)” в TimesTen для мониторинга журнала транзакций при обновлении данных по интересующим акциям.

Чтобы обеспечить самый быстрый доступ к таким обновлениям, компания создает материализованное представление, названное PE_Alerts, в котором фраза WHERE вычисляет отношение PE от столбца Price в таблице Quotes и столбца Earns в таблице Earnings. Используя механизм событий XLA для мониторинга журнала транзакций ценовых обновлений в материализованном представлении, торговое приложение получает алерт-сигналы только по тем акциям, для которых выполняется его торговый критерий.

Рисунок 2.4. Использование материализованных представлений и XLA

Сценарий 3: Приложение, обслуживающее оперативное туристическое агентство

CustomTravel.com - оперативное туристическое агентство - обеспечивает оперативные Web-бюро путешествий. Компания поддерживает подробные профили для каждого клиента, чтобы отследить характерные сведения, например, историю поездок и личные предпочтения в выборе авиалиний, мест назначения, арендной платы за автомобили, гостиницы и так далее. Эти профили используются reservation application (приложение резервирования), чтобы предоставить каждому клиенту персонифицированный оперативный план путешествия.

Как показано в нижней части рисунка 2.5 , система, компания содержит центральный сервер, на котором находится фоновое приложение и база данных Oracle, которая хранит профили клиентов и данные резервирования. Эти данные резервирования включают графики полетов, места в наличии, арендную плату за гостиницу и автомобиль и подобную информацию от вендоров индустрии туризма. Эти данные резервирования постоянно обновляются в базе данных Oracle приложением vendor services application (услуги вендоров), которое управляет связью между компанией и ее туристическими вендорами.

Чтобы эффективно управлять ожидаемым количеством до 1000 параллельных клиентских сессий, компания распределила несколько серверов приложений по региону своего обслуживания, как это показано в верхней части рисунка 2.5 . Каждый сервер приложений включает отдельное приложение резервирования и кэши данных клиентских сессий в локальной сборке данных TimesTen. Чтобы гарантировать постоянную готовность, каждая сборка данных TimesTen реплицируется в горячую резервную сборку данных.

Рисунок 2.5 Использование Cache Connect к кэшу данных Oracle

В каждой сборке данных TimesTen сессионные данные включают копию данных резервирования и отобранные клиентские профили, сохраненные в центральной базе данных Oracle. Эти данные Oracle кэшируются в cache groups (кэш-группах) TimesTen и передаются между TimesTen и Oracle, используя механизм TimesTen “Cache Connect to Oracle” .

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

Когда клиент заканчивает сессию, заключительная выборка данных о рейсе, гостинице и так далее сбрасывается из TimesTen в Oracle. “Cache Connect to Oracle” старит экземпляры кэша неактивных клиентских профилей, поскольку необходимо место.

Все финальное резервирование и спланированные данные сохранены в базе данных Oracle. База данных Oracle намного больше, чем любая сборка данных TimesTen, и лучше всего сообщается с приложениями, которым не надо работать в реальном времени, а действительно требуется доступ к большим объемам данных. В такие приложения включается и приложение vendor services application рассматриваемой компании, которое обновляют данные резервирования, предоставленные туристическими вендорами, и подтверждает финальное резервирование, выработанное TimesTen с вендорами, а также billing application (биллинг-приложение составления счетов), которое делает начисление клиенту на потребленные услуги и выставляет счет. Другое Oracle-приложение нашей компании - data mining application (приложение добывания данных), которое анализирует исторические данные, чтобы определить модели резервирования в том, что касается времени года, недели, продолжительности путешествия и числа членов семейства, путешествующих вместе. Результаты этого приложения используются для повышения дохода компании, предлагая, например, скидки на путешествия в течение “мертвых” сезонов.

Обсуждение проектов приложений

TimesTen разработан, чтобы предложить максимальную гибкость и обеспечить широкий диапазон прикладных приложений. Рассмотрим, например, следующие альтернативы описанному в “Сценарии 3: приложению, обслуживающему оперативное туристическое агентство”.

Альтернатива 1

Для обеспечения возможности более эффективного управления большим числом параллельных клиентских сессий агентство CustomTravel.com заменило централизованную архитектуру своего приложения, обслуживающего оперативное туристическое агентство, на то, что показано на рисунке 2.6. В этой альтернативной архитектуре компания реализует приложения, отдельно предоставляющие сервисы авиалиний, гостиничного обслуживания и аренды автомобилей. Каждое приложение функционирует на отдельном сервере, занимая центральное положение, и кэширует данные, имеющие отношение только к данному приложению. Такая архитектура имеет те же самые выгоды, что и описанная в оригинальном сценарии, но использует более децентрализованный [прим.А.Бачина: в тексте сказано centralized – централизованный; но “увидев на клетке со слоном надпись “буйвол”, верь глазам своим!” - по К.Пруткову] подход к управлению данных.

Рисунок 2.6. Децентрализованные кэши TimesTen на нескольких совместных серверах

Альтернатива 2

Эти три приложения, названные в сценарии 3, могут функционировать и на одном и том же сервере, как показано на рисунке 2.7 , если сервер имеет достаточную производительность, чтобы выдержать все три приложения.

Рисунок 2.7 Централизация кэшей TimesTen на одном сервере

Альтернатива 3

Если все три приложения из сценария 3 должны были работать на одном и том же сервере, они могут получить доступ к одной и той же сборке данных TimesTen, как показано на р исунке 2.8 . Единственная сборка данных может содержать объединение данных, необходимых всем трем приложениям.

Рисунок 2.8. Централизованный разделяемый кэш TimesTen на одном сервере

Архитектурные компромиссы

Первоначальный проект сценария 3 и описанные выше альтернативные проекты иллюстрируют следующие архитектурные компромиссы:

• Географически распределенные серверы, как описано в первоначальной версии сценария 3, могут обеспечить лучшее время ответа для местных приложений и конечных пользователей. Они могут также обеспечить лучшую устойчивость к ошибкам, потому что несколько серверов при централизованном расположении все могут пострадать в результате одной аварии, типа отключения электричества или пожара.
• Размещение нескольких серверов в одном и том же месте, как показано в альтернативе 1 , может обеспечить большую устойчивость к ошибкам, чем использование одного большого централизованного сервера, но такое решение потребуют больших административных издержек и большей координации.
• Несколько специализированных приложений могут обеспечить большую устойчивость к ошибкам и отказам программного обеспечения, чем единственное большое приложение всеобщего назначения. Например, в альтернативе 1 , ошибка в приложении “Услуги авиалиний” не будет затрагивать приложение “Услуги аренды автомобилей”, тогда как в первоначальном сценарии все услуги резервирования объединены в одно приложение, и ошибка в одном из приложений может затронуть все услуги в этом узле.
• Несколько специализированных приложения с различными, но потенциально перекрывающимися сборками данных ( альтернатива 2 ), могут обеспечить лучшую производительность, чем несколько приложения, разделяющих одну сборку данных ( альтернатива 3 ), поскольку каждое приложение может применять разные методы доступа и может использовать различное индексирование данных.
• единственная разделяемая сборка данных, описанная в альтернативе 3, имеет некоторые преимуществ, но и причиняет некоторые неудобства. Ей в плюс, что она упрощает управление данными, поскольку все политики, все механизмы когда/как переместить данные TimesTen в/из Oracle управляются в одной точке. Это также может дать экономию в расходовании главной памяти, так как несколько кэшей могут содержать избыточные данные. Однако производительность и масштабируемость могут быть лучше в случае скольких сборок данных. Кроме того, отказ единой разделяемой сборки данных может затронуть все приложения. Но с другой стороны, резервная сборка данных может обеспечить, быстрое аварийное восстановление, что и должно быть в случае отказа.

Резюме по вариантам проекта

Присоединение к TimesTen

Для обеспечения лучшей производительности следует применять прямое соединение менеджером TimesTen данных, как будет описано в главе 4 “ How Applications Connect to Data Stores” в разделе “Direct Driver Connection” [вне рамок этого перевода – прим.OM/RE]. Применение прямых связей позволяет избежать высокой стоимости переключения контекста и применения IPC, что ассоциируется с режимом клиент/сервер.

Операции с дисковой реляционной СУБД

TimesTen предназначен для управления относительно небольшими объемами данных (в диапазоне от единиц до нескольких десятков гигабайтов), в то время как дисковая RDBMS предназначена для управления значительно большими объемами данных (в терабайтном диапазоне).

TimesTen может работать в партнерстве с дисковой RDBMS, в котором TimesTen управляет оперативными данными, которые требуют высокой производительности, в то время как дисковая RDBMS управляет исторически накопленными данными. Это показано в сценарии 1, в котором приводится приложение “Учет активности абонентов” и в сценарии 3, описывающим приложение для оперативного туристического агентства . Когда TimesTen используется с дисковой RDBMS, основными являются несколько вариантов:

• Перемещение данных от/к TimesTen и дисковой RDBMS может или быть осуществлено или приложением (как показано в сценарии 1), или механизмом TimesTen “Кэш-соединение с Oracle” ( “Cache Connect to Oracle”), как показано в сценарии 3.
• TimesTen может использоваться для сбора быстро прибывающих новых данные, которые позже в пакетном режиме передаются в хранящую исторические данные дисковую RDBMS (как показано в сценарии 1).
• TimesTen может использоваться для управления часто обрабатываемым подмножествам данных из намного большей базы данных (как показано в сценарии 3).
• оперативные данные может обрабатываться как в нескольких, так и в единой сборке данных TimesTen. В случае применения нескольких сборок данных, они могут, как накладываться друг на друга, так и быть полностью непересекающимися. Использование нескольких сборок данных обеспечивают масштабируемость, устойчивость к ошибкам и потенциально лучшую настройку для определенных потребностей приложений, о чем говорилось в альтернативах к сценарию 3.

Секционирование данных

Секционирование данных может использоваться для масштабирования приложений и достижения более высокой производительности. Это показано в сценарии 1, в котором приводится приложение “Учет активности абонентов” , когда абонентские данные собираются на различных узлах. Это разделение позволяет неограниченно масштабировать приложение, поскольку можно добавить еще больше узлов, когда исчерпывается производительность существующих узлов. Такое разделение также обеспечивает гибкость по местам размещения, где разные узлы могут быть использованы для сбора абонентских данных в случаях изменения абонентом местоположения между началом и концом вызова.

Готовность данных

Во всех трех сценариях, описанных выше в разделе “Прикладные Сценарии TimesTen” , очень существенна непрерывная готовность данных, управляемых TimesTen. Это достигается за счет постоянно поддерживаемой резервной (standby) копии данных в другой сборке данных TimesTen.

В сценарии 1 “Приложение, измеряющее характеристики звонков ” и в сценарии 3 “ Оперативное туристическое агентство ” резервная копия поддерживается механизмом репликаций TimesTen, в то время как в сценарии 2 “ Обслуживание котировок в реальном времени ” резервная копия сборки данных поддерживается самим приложением посредством избыточного обмена (messaging) и обработки сообщений, как мастер-, так и на резервной системах.

Репликация в TimesTen представляется в асинхронном варианте и в виде return service (сервис возврата), который более похож на синхронный вариант. В случае отказа мастер- сборки данных репликация TimesTen обеспечивает быстрый аварийный переход к резервной сборке данных. В сценариях 1 и 3 приложения взаимодействуют с мастер-сборкой данных. TimesTen автоматически копирует все изменения [в данных], происходящие в мастер- сборке данных, на резервную сборку данных. Если мастер- сборка данных сбоит, кластер-менеджер, например, Service Guard от HP, может обнаружить отказ и автоматически переключить все действия на приложениям, функционирующим на резервной сборке данных.

В тех средах, где изменения поставляются приложению через программное обеспечение среднего уровня обмена сообщениями (messaging middleware), как, например, TIBCO SmartSockets, TIBCO Rendezvous или IBM MQSeries, приложение может осуществлять высокую готовность посредством избыточного обмена сообщениями (messaging). В этом случае это messaging middleware снабжает сообщениями и первичную, и резервную системы. Приложения, как на первичной, так и на резервной системе, заносят изменения в соответствующие сборки данных. Запросы на чтение могут быть обработаны или только на первичной, или и первичной, и резервной системах. Опять же в случае отказа кластер-менеджер может обнаружить аварию и может автоматически переключить запросы к выжившей сборке данных.