Поле памяти

* ЦП i и оперативная! память

,.Г ЦП* 5 1и оперативная! память.

и оперативная!

Ламять *

Запросы блокировки -

и оперативная пГМять

Рис. 14.8. Простая конфигурация с архитектурой NUMA

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

А вот в проектировании систем оперативной обработки транзакций радикальные изменения могут и не потребоваться. Действительно, СМП-ар-хитектура (вероятно, с 256 процессорами, а не с четырьмя, как показано на рис. 14.8) лучше, чем современные аппаратные средства, способна справиться с традиционным подходом одно соединение на пользователя , который господствует сегодня в приложениях Oracle и предполагается многими (если не большинством) высокопроизводительными средствами разработки приложений.

Главная проблема - найти способ распределения работы нескольких процессов между достаточным количеством процессоров, чтобы полностью задействовать все наличные вычислительные ресурсы. Такие алгоритмы сами По себе не обязательно должны быть эффективными. Если в традиционной стратегии реализации отчета или пакетного обновления используется лишь один из пусть даже четырех процессоров, то система, в которой имеется на 100% больше ЦП, но могут быть одновременно задействованы четыре процессора, должна позволять выполнить задачу в два раза быстрее, Возможно, это не очень понятно, но это так.

OPS: выводы

Oracle Parallel Server - увлекательная технология, но она подходит не для всех случаев. Если структура приложения не позволяет держать под контролем эффекты пингинга (как правило, путем распределения нагрузки, связанной с обновлением, по узлам кластера), OPS использовать не рекомендуется. В архитектурах с массовым параллелизмом Oracle Parallel Server необходим для разделения данных, и эффективное распределение рабочей нагрузки здесь вряд ли возможно. Следовательно, неизбежна высокая интенсивность пингинга. В такой системе должен присутствовать как менеджер распределенных блокировок, так и механизм межпроцессорной пересылки блоков, достаточно быстрые для того, чтобы справиться с этим трафиком. Если наличие этих средств не предусмотрено, то это решение использовать не следует.

Проектирование модулей кода

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

В главе 15, Введение в проектирование кода , рассматриваются основные понятия, связанные с проеьсгированием мozyлeй кода.

В главе 16, Где разместить логику обработки? , описаны способы размещения логики приложения.

В главе 17, Метрики, макеты и спецификации , освещается формальная сторона проектирования кода. В частности, рассматривается вопрос о том, как обеспечить соответствие проектируемых модулей поставленным требованиям.

Глава 18, Блокировка , содержит информацию, которая поможет свести к минимуму конкуренцию в проектируемых приложениях.

В главе 19, Выбор инструментальных средств , сравниваются достоинства различных категорий интерфейсных продуктов, которые могут поддерживать СУБД Oracle.

В главе 20, Экранные формы, отчеты и пакетные программы , освещаются специальные вопросы проектирования экранных форм, отчетов, пакетных программ, средств обработки ощибок, навигации и справочных систем.