Обзор статей журнала DBMS, vol.10, N 3, March 1997

www.dbmsmag.com

CORBA: Masterminds Object Management

Warren Keuffel, software engineer and technology journalist
E-mail: 76702.525@compuserve.com

В 1989 г. группа компаний-производителей и пользователей, которые считали перспективным применение объектно-ориентированного подхода для разработки программного обеспечения, образовали коалицию с целью навести порядок в хаотичном мире объектов. Коалиция получила название Object Management Group (OMG). CORBA является наиболее важным продуктом OMG. CORBA (Common Object Request Broker Architecture - Общая архитектура брокера объектных заявок) представляет собой спецификацию объектно-ориентированного "универсального программного обеспечения промежуточного уровня" ("universal middleware"), позволяющего программистам без потребности знания того, как и где реализованы объекты, написать код новых объектов, взаимодействующих с существующими. OMG специфицирует два базовых средства, предназначенных для проектировщиков и разработчиков объектных систем, - IDL и ORB. IDL (Inrerface Definition Language) в объектном мире играет роль, аналогичную роли английского языка в международном сообществе программистов, т.е. дает возможность объектам понимать друг друга. Однако IDL только частично решает проблему обеспечения возможности взаимодействия объектов. Требуется программное обеспечение, которое доставляет заявки на вызов методов объектов. В терминах OMG такое программное обеспечение называется ORB (Object Request Broker). Как видно, акроним CORBA получается из ORB путем добавления "C" ("Common") в начало и "A" ("Architecture") в конец. Тем самым, CORBA является архитектурой (или спецификацией), определяющей общие свойства, которыми должны обладать все реализации брокеров объектных заявок, соответствующие спецификации. На самом деле, OMG не создавала спецификацию CORBA и тем более программные продукты. OMG запрашивает у представителей сообщества разработчиков программного обеспечения предложения по поводу технологических спецификаций. Собранные предложения анализируются и оцениваются членами OMG, и общая спецификация принимается на основе общего согласия. Результирующая спецификация носит настолько же политический как и технологический характер, во многом отражая маркетинговую стратегию компаний, доминирующих в OMG (например, IBM). Процесс принятия спецификаций в OMG носит демократический характер; учитываются (хотя и не всегда принимаются во внимание) многие точки зрения. По этой причине спецификация OMG более надежна, но медленнее проникает на рынок, чем конкурирующая архитектура компании Microsoft DCOM (Distributed Component Object Model). Microsoft пользуется собственной технологической моделью, не обращая внимание на наличие других точек зрения.

С точки зрения программиста, связанного с базами данных, наиболее интересной частью CORBA является спецификация OTS (Object Transaction Service), в которой определяется, каким образом атомарные транзакции могут быть распределены над множеством объектов и брокеров объектных заявок. Спецификация OTS была разработана под большим влиянием компании Transarc Corp., одной из двух компаний, играющих основную роль в бизнесе мониторов транзакций. Технология монитора транзакций Encina, в частности, была внедрена в общий технологический пакет DCE (Distributed Computing Environment). Другой наиболее важный монитор транзакций Tixedo (BEA/Novell) был использован в спецификации мониторов распределенной обработки транзакций X/Open. Спецификация OTS была разработана таким образом, чтобы обеспечить интероперабельность с мониторами транзакций, соответствующим спецификации X/Open. Комитеты OMG, занимавшиеся OTS, понимали, что они должны обеспечить безопасный и надежный переход к новым технологиям для тех компаний, которые вложили большие средства в необъектную технологию управления транзакциями. Поэтому OTS обеспечивает возможности одновременного взаимодействия механизмов управления транзакциями, основанных как на ORB, так и на традиционных мониторных транзакционных службах. Кроме того, OTS предполагает возможность поддержки восстанавливаемых вложенных транзакций (если угодно, в неоднородной среде) с полным следованиям принципам ACID (Atomicy, Consistency, Isolation, Durability) и двухфазным протоколам фиксации.

Эффективность обработки транзакций частично связана с наличием хорошего управления параллельным выполнением транзакций. Для этих целей CORBA содержит отдельную спецификацию, называемую CCS (Concurrency Control Service). Определен набор возможных блокировок, от традиционных блокировок по чтению и записи и заканчивая условными блокировками (intention locks). Изменяемые блокировки (upgrade locks) позволяют программистам избегать синхронизационных тупиков (такие блокировки могут быть как транзакционными, так и нетранзакционными).

Работа OTS делится между клиентами и серверами. Клиенты запрашивают транзакционные услуги, которые выполняются серверами транзакций. В OTS определены четыре важных интерфейса: Current, Coordinator, Resource и SubtransactionAwareResource. Интерфейс Current позволяет программисту установить контекст транзакции; по мере создания и уничтожения объектов в пределах жизни транзакции контекст связывается с каждым из объектов, что позволяет брокеру объектных заявок передавать заявки от сервисов клиента серверам, управляющим ресурсами. Когда ORB получает ответ от объекта-сервера, он поддерживает контекст заявки и может вернуть данные исходному клиенту. Интерфейс Resource относится к объектам, поддерживающим протокол двухфазной фиксации. В транзакции может участвовать несколько объектов с интерфейсом Resource, но каждый Resource голосует по поводу своей возможности выполнить полученную им заявку. Если хотя бы один объект Resource голосует против, транзакция откатывается или затормаживается в зависимости от кода, указанного в сообщении клиента. Для повышения эффективности в средах с одним объектом Resource в интерфейсе Current имеется возможность использовать сообщение commit_one_phase, посылка которого позволяет отказаться от расходов, связанных с двухфазной фиксацией.

До появления версии спецификации CORBA 2.0 после установки ORB от некоторого производителя программисты оказывались полностью привязанными к этой реализации. Было невозможно запустить два брокера объектных заявок от разных производителей с гарантией, что один из них поймет сообщения, посылаемые другим. В декабре 1994 г. была выпущена спецификация CORBA 2.0. В ней предполагается, что транспортный механизм межброкерных взаимодействий должен основываться на стеке протоколов TCP/IP. Возможность межброкерных взаимодействий на основе TCP/IP исключительно важна для всех неоднородных сред, в частности, среды World Wide Web. 4Поэтому компания 0Netscape Communications Corp. стала одним из наиболее активных сторонников CORBA. В среде Netscape ONE (Open Network Environment) предполагается использование межброкерного обмена сообщениями IIOP (Internet Inter-ORB Protocol) вместо ориентированного на передачу файлов протокола HTTP, применяемого в настоящее время. Этот переход принесет существенную пользу, поскольку накладные расходы IIOP намного меньше тех, которые требуются HTTP.

Несколько компаний-производителей предлагают сервисы OTS для своих ORB-продуктов. Одна из наиболее известных компаний, Iona, объявила о партнерстве с компанией Transarc с целью включения сервисов Encina OTS в ORB Orbix. Поскольку Transarc также поставляет монитор обработки транзакций для встраивания в DCE, новое партнерство приведет к тому, что технология Encina будет использоваться в обеих средах. Кроме того, за счет наличия протокола IIOP можно использовать DCE в среде CORBA, поскольку в CORBA 2.0 определен протокол GIOP (General Inter-ORB Protocol); обеспечивается отображение сообщений GIOP в сообщения протокола DCE CIOP (Common InterORB Protocol). Другой компанией, предлагающей брокер объектных заявок, совместимый с CORBA 2.0, является Visigenic Software Inc. Продукт этой компании VisiBroker for C++ (раньше назывался ORBeline) является полной реализацией ORB в соответствии со спецификацией CORBA 2.0 с поддержкой IIOP. Возможно взаимодействие VisiBroker с другим продуктом компании, VisiBroker for Java (раньше назывался Black Widow). Последний из упомянутых продуктов целиком написан на языке Java и предназначен для построения распределенных Java-приложений. Продукт, который может заинтересовать программистов, желающих интегрировать CORBA с существующими реляционными базами данных, разработан компанией Persistence Software Inc. Центральной концепцией компании Persistence является объектный кэш, поддерживающей возможности долговременного хранения объектов. Компания имеет партнерские связи с компанией Iona, результатом чего явилась возможность отображения реляционных баз данных в объекты на основе использования языка IDL.

Координаты компаний:

BEA Systems Inc.: www.beasys.com
Black & White Software Inc.: www.blackwhite.com
Gemstone Systems Inc.: www.gemstone.com
Iona Technologies Inc.: www.iona.com
Object Management Group Inc.: www.omg.org
Persistence Software Inc.: www.persistence.com
Transarc Corp.: www.transarc.com
Visigenic Software Inc.: www.visigenic.com

---

March of the Data Marts

Peter L. Brooks, management consultant with the Advanced Technology Group of Coopers & Lybrand Consulting
E-mail: plbooks@compuserve.com

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

По мере расширения области применения рынков данных возрастает уровень требований. Для организации рынка данных недостаточно использовать небольшие базы данных с облегченным для конечных пользователей доступом. Современные рынки данных должны быть в состоянии хранить сотни гигабайт данных и обеспечивать сложные разновидности аналитической обработки, например, из области добычи данных (data mining). Должен быть обеспечен удаленный доступ к рынку данных для сотен пользователей - возможность, которую дешево обеспечивает технология Internet и Intranet. Наконец, организация должна быть в состоянии централизовано администрировать и управлять многими рынками данных, которые могут содержать несогласованные и конфликтующие данные.

Хотя теперь трудно различать рынки и склады данных, исходя только из их размеров, некоторые различия остаются важными:

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

Компании-производители разрабатывают концепцию виртуального рынка данных, удовлетворяющего потребности в доступе к нескольким рынкам данных без необходимости репликации данных между рынками. Новая технология рынков данных все еще находится в стадии развития, хотя и не такого интенсивного как несколько лет тому назад, когда OLAP-системы, основанные на реляционных базах данных, были новинкой и на рынок складов данных вышло бесчисленное количество производителей. В прошлом году компании Information Builders Inc. (IBI) и SAS Institute Inc. объявили свои новые продукты, предназначенные для поддержки рынков данных,- Focus Fusion и SAS MDDB соответственно.

Рост размеров рынков данных порождает несколько проблем при обеспечении доступа пользователей к корпоративной информации:

• По мере роста рынка данных ухудшается эффективность доступа. Пользователи ожидают более короткого времени ответа при обращении к рынку данных, чем в случае склада данных.
• Пользователям требуется доступ к нескольким рынкам данных, не обязательно принадлежащим их отделу и управляемых разными серверами баз данных. Данные могут быть реплицированы между рынками данных, но виртуальный рынок данных представляет собой лучшее решение.
• Нелегко администрировать несколько рынков данных, обеспечивая согласованность и целостность метаданных для всех рынков данных, а также безопасность данных. Требуются специализированные средства поддержки администрирования рынка данных.
• Если склад данных строится в течение нескольких лет, то для рынка данных должен существовать короткий цикл разработки с умеренными расходами. Для упрощения и сокращения срока (не более 90 дней)разработки рынка данных разрабатываются средства типа "рынок данных в одной упаковке", включающие все необходимые компоненты.

Решения рынков данных требуют применения двух- или трехуровневой архитектуры. На первом уровне может находиться склад данных (если рынок данных извлекается из более крупного склада данных). На втором уровне располагается сам рынок данных. Третий уровень составляют рабочие станции конечных пользователей. Для организации виртуальных рынков данных компания Information Advantage Inc. поддерживает разнородные серверы рынков данных с хранением метаданных в отдельном узле независимо от базы данных любого рынка данных.

Для достижения эффективности рынка данных необходимо сбалансировать два критических компонента - время ответа для конечного пользователя и эффективность загрузки данных. В продукте Red Brick Warehouse 5.0 компании Red Brick Systems Inc. достигнуто существенное увеличение производительности за счет усовершенствования возможностей используемого сервера баз данных. Средство, называемое Continually Adaptive Indexing (TARGETindex), обеспечивает наличие индексов, которые автоматически и постоянно адаптируются к текущим особенностям обработки данных. Новый гибридный, основанный на хэшировании алгоритм соединения более эффективно срабатывает в ситуациях соединения очень больших таблиц, а также таблиц существенно разного размера. SQL-запросы могут встраиваться в раздел FROM другого запроса. Начальные строки результата передаются для анализа конечным пользователем до формирования полного результата.

Системы управления многомерными базами данных (MDDB), такие как Essbase компании Arbor Siftware Corp., поддерживают инкрементальное обновление базы данных, при котором не изменяется общая структура MDDB, а изменяются только соответствующие ячейки данных. Это новое достижение, поскольку в отличие от реляционных баз данных, в которых модифицируются отдельные строки, в традиционных кубах MDDB требовалось изменение всего куба, что представляет собой долговременный процесс.

Несколько компаний предлагает пути к повышению эффективности рынков данных за счет уменьшения их размеров. Например, в продукте Pilot Decision Support Suite компании Pilot Software Inc. поддерживаются динамические измерения и иерархии, что позволяет существенно сократить размеры хранимых баз данных. Агрегатные значения могут вычисляться по мере необходимости, а не заранее. Имеется пример сокращения размера MDDB от 4 Гб до 200 Мб за счет использования этого подхода.

Решение компании CrossZ Software под названием QueryObject, которое может равно относиться к области MDDB или области реляционных баз данных, за счет использования фрактальных алгоритмов позволяет произвести компрессию данных в отношении 10000 к одному с сохранением 100% точности.

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

Без централизованного управления данные разных отделов корпорации становятся рассогласованными, пользователи не могут пользоваться информацией из разных рынков данных, и рынки данных слишком разнородны, чтобы можно было интегрировать их в единый склад данных. Продукт DSS Administrator компании MicroStrategy Inc. разработан с целью обеспечить возможности управления несколькими проектами из области поддержки принятия решений, несколькими группами пользователей и несколькими типами отчетов. Одна из мощных возможностей состоит в управлении виртуальными рынками данных, которые позволяют пользователям получать информацию из разных физических рынков данных. Пользователи могут объединяться в группы в соответствие с соображениями безопасности. Администратор может проводить анализ всей системы, а также отслеживать время генерации отчетов и уровень использования ресурсов в любой момент времени. Поскольку метрические данные системы хранятся в каталогах базы данных, могут генерироваться кастомизированные отчеты о работе каждого пользователя.

Отдельным аспектом администрирования рынка данных является возможность оптимальной настройки. Продукт компании IBM Site Analyser позволяет администратору анализировать статистики, исходящие от пользователя или ресурса, что позволяет установить оптимальную среду запросов. В частности, возможно принятие или непринятие конкретного запроса в зависимости от оценок администратора.

Многие производители осознают потребность в более облегченном создании рынков данных по сравнению с подходом складов данных. Разработка концепции "рынка данных в одной упаковке" ("data mart in a box") призвана для минимизации уровня этих проблем, включая вопросы аппаратной организации, программного обеспечения и профессионального обслуживания

Продукт компании IBM SmartMart дает возможность использования программного обеспечения промежуточного уровня (middleware) для извлечения данных из более чем 60 реляционных или файл-ориентированных источников в рынки данных, основанные на использовании Fusion MDDB компании IBM или одной из основных реляционных баз данных. Имеется также продукт WebFocus, обеспечивающий возможность работы конечных пользователей в среде Internet. В "упаковку" входят средства администрирования и хранения метаданных.

Продукт Visual Warehouse компании IBM работает в средах OS/2 или Windows NT. Версия NT включает сервер Visual Warehouse, драйверы ODBC, связующее средство DDCS, средство поддержания репозитория метаданных DataGuide и средство Lotus Approach для проведения анализа конечными пользователями. Возможно использование всех версий DB2, а также распространенных реляционных и нереляционных источников данных.

Пакет PowerMart 3.5 компании Informatica Corp. содержит следующие средства: Informica PowerMart Designer, Repository, Server Manager, PowerMart Server и компоненты семейства Change/Capture. Поддерживаются все популярные реляционные базы данных. В средстве Star Schema Design Wizard (ой, как хочется сказать, "кудесник проектирования звезднообразных схем") используется визуальный интерфейс для поддержки проектирования базы данных.

Программа RightStar компании NCR Corp. разработана для того, чтобы обеспечить разработку рынка данных в течение 90 дней при том, что рынок данных сможет разрастаться до размеров склада данных. Продукт включает сервер WorldMark 5100S, операционную систему NCR Unix MP-RAS, средства управления базами данных (Teradata, Oracle или Informix), средства доступа к данным или их преобразования и профессиональные службы. Анонсировано партнерство с компанией Microsoft с целью повышения уровня интеропрерабельности между серверами баз данных Teradata и MS SQL Server.

Internet/Intranet технологии обещают предоставить дешевый доступ к складам и рынкам данных на основе Web-браузеров. Компании MicroStrategy и Information Advantage обещают средства семейства ROLAP (Relational On-Line Analisis Processing) на основе Web-продуктов (то же самое относится к компаниям Arbor Software и Pilot Software). Основанный на Windows NT продукт Essbase Web Gateway поддерживает функциональные свойства OLAP для пользователей Essbase. Пакет Pilot Internet Publisher обеспечивает пользователей Pilot Decision Support доступом к данным через стандартные Web-браузеры. Основанный на Windows NT продукт DSS Web 4.1 компании Microstrategy включает базированный на языке Java пакет AutoPrompt, который позволяет внедрять встроенные запросы, поддерживать разнообразные языки, использовать диагностику уровня администратора. Программа работает на платформах Windows 3.1, Windows 95, Windows NT, OS/2, Macintosh, Unix.

Основными задачами, которые предстоит решить производителям, остаются следующие:

• Короткое время ответа на запросы к масштабным рынкам данных.
• Администрирование рынков данных.
• Возможности быстрой реализации.

Координаты компаний:

Arbor Software Corp.: www.arborsoft.com
Blue Isle Software Corp.: www.blueisle.com
CrossZ Software: www.crossz.com
IBM: www.ibm.com
Informatica Corp.: www.informatica.com
Information Advantage Inc.: www.infoadvan.com
Information Builders Inc.: www.ibi.com
MicroStrategy Inc.: www.strategy.com
NCR Corp.: www.ncr.com
Pilot Software Inc.: www.pilotsw.com
Red Brick Systems Inc.: www.redbrick.com
Sagent Technology Inc.: www.sagenttech.com
SAS Institute Inc.: www.sas.com

---

Taming Data Giants

Stephen Brobst, a founder and managing partner at Strategic Technologies & Systems
E-mail: sabrobst@jj.lsc.mit.edu

Owen Roberston, a senior DBA at Tanning Technoology Corp.
E-mail: atoroberts@tanning.com

В статье приводится обзор критических проблем, связанных с администрированием сверхбольших баз данных (VLDB - Vary Large DataBases), таких как управление производительностью и достижение высокого уровня доступности. Кроме того, обсуждаются роль стратегии индексации, оптимизаторы запросов, параллельная обработка, масштабируемость, трехуровневые архитектуры. В заключение описывается, как некоторые лидирующие РСУБД поддерживают работу со сверхбольшими базами данных.

Единственным способом эффективного управления таблицами, содержащими миллионы строк, является использование какой-либо формы разделения данных. Для разделения используются три основных метода: разделение на основе хэширования, разделение в соответствии с диапазонами значений ключа и циклическое разделение (round-robin). При использовании разделения на основе хэширования DBA (DataBase Administrator) должен выбрать один или несколько столбцов из каждой таблицы для использования в качестве исходных данных для хэш-функции, результирующее значение которой определяет, в каком разделе базы данных будет храниться данная строка таблицы. Хорошая хэш-функция должна быть эффективной и удовлетворительно балансирующей распределение данных между разделами. При разделении данных в соответствии с диапазонами значений ключа строки данных таблицы помещаются в раздел базы данных исходя из заранее приписанного к этому разделу диапазону значений ключа. В некоторых базах данных требуется, чтобы такого рода разделение выполнялось только для первичного (уникального) ключа. Для больших таблиц в качестве ключа разделения часто используется столбец временной метки. Циклическое разделение данных организуется самым простым образом - все разделы связываются в циклически связанную цепочку, и следующая строка таблицы помещается в следующий раздел. Основным преимуществом циклического разделения является эффективное распределение данных по разделам при выполнении массивной загрузки большой таблицы.

В большинстве СУБД, ориентированных на поддержку систем класса DSS (Decision Support System - системы поддержки принятия решений), используется разделение на основе хэширования, обеспечивающее равномерное распределение данных между разделами и облегчающее выполнение соединений, если две таблицы разделены по одному и тому же ключу (конечно, в этом случае строки обеих таблиц с одинаковым значением хэш-функции от значения ключа должны храниться в одном и том же разделе). В СУБД разряда "shared-nothing" (такие системы основываются на несимметричных мультипроцессорных архитектурах, в которых процессоры не имеют совместно используемых ресурсов основной и внешней памяти) соединения совместно разделенных таблиц выполняются существенно быстрее, чем при применении других способов разделения. Реально, если соединяются две таблицы, не являющиеся совместно разделенными, используется динамическое перераспределение строк соединяемых таблиц. Стоимость перераспределения различна для разных серверов баз данных и сильно зависит от размеров таблиц. В системах типа Extended Parallel Server (XPS) компании Informix Software Inc., в которых обеспечивается очень высокая эффективность коммуникаций между узлами, соединения не совместно разделенных таблиц выполняются всего на 10% медленнее, чем если бы они были совместно разделенными. Однако в системах типа shared-nothing, не обеспечивающих должную оптимизацию перераспределений, не совместно разделенные таблицы соединяются более чем в два раза медленнее. Разделение на основе хэширования применяется в системах Teradata (NCR Corp.), DB2/6000 Parallel Edition (IBM Corp.), MPP (Sybase Inc.). В системах Non-Stop SQL (Tandem Computers Inc.) и DB2 V.4 для MVS, которые ориентированы на эффективную поддержку мощных систем класса OLTP (On-Line Transaction Processing - оперативная обработка транзакций), для больших таблиц применяется разделение по диапазонам ключа. В сервере баз данных компании Informix можно использовать все три вида разделения. Компания Oracle не будет поддерживать разделения таблиц до выпуска восьмой версии, однако уже в версии 7.3 существует возможность моделировать разделение путем создания отдельной таблицы для каждого раздела и определения представления, в котором все эти таблицы объединяются. Используется специально разработанная техника оптимизации запросов, адресованных к подобным представлениям.

Масштабируемость СУБД, ориентированных на OLTP-приложения продолжает оставаться ограниченной, хотя, например, сервер Oracle 7.3 продемонстрировал хорошие возможности масштабируемости на симметричном мультипроцессоре Cray Research 6400. Ограниченность масштабируемости связана с использованием одного экземпляра базы данных и соответствующим наличием критических участков в работе сервера (например, при сериализации транзакций с помощью синхронизационных блокировок). Одним из наиболее существенных нововведений в Oracle 7.3 было применение нескольких списков свободных блоков с целью снижения уровня конкуренции за этот ресурс.

В отличие от реализаций распределенных баз данных, в которых каждый экземпляр базы данных является относительно независимым, в реализациях баз данных с несколькими экземплярами (multiple database instances), таких как Oracle Parallel Server или Informix XPS, все экземпляры представляют единый образ базы данных. Для организации баз данных с несколькими экземплярами применяются архитектуры с разделением (shared-everything) и без разделения (shared-nothing) ресурсов. В архитектурах с разделением ресурсов для каждого экземпляра базы данных доступен любой блок базы данных; разделение данных не зависит от наличия нескольких экземляров базы данных, хотя в некоторых реализациях допускается связь между экземплярами базы данных и разделами таблиц. В реализациях без разделения ресурсов экземпляры базы данных явно привязываются к разделам таблиц. Обращения к блокам раздела можно выполнять только в том экземпляре базы данных, к которому приписан раздел.

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

Решением, которое позволяет добиться требуемого уровня производительности реализаций баз данных с разделением ресурсов, является использование трехуровневых архитектур приложений. Распространенные двухуровневые конфигурации (сервер баз данных и рабочие станции пользователей) не масштабируются к объемам информации, характерным для VLDB. В трехуровневой архитектуре появляется промежуточный уровень, в основе которого обычно находятся мониторы транзакций. Мониторы транзакций Tuxedo (BEA Systems Inc.) и Encina (Transarc Corp., теперь эта компания принадлежит IBM) доминируют на рынке UNIX-систем; CICS - на рынке MVS. Использование надежного промежуточного программного обеспечения дает много преимуществ. Прежде всего, логика бизнес-приложений явно отделяется от уровней представления и доступа к базе данных. Проблема доступа к часто изменяемым блокам решается за счет явного использования средств маршрутизации в зависимости от данных (Data-Dependent Routing - DDR). Такие средства поддерживаются в большинстве мониторов транзакций для осмысленной маршрутизации транзакций к конкретным экземплярам базы данных. Трехуровневая архитектура обеспечивает высокий уровень масштабируемости приложений, поскольку мониторы транзакций обеспечивают возможности подключения к базе данных гораздо более эффективно, чем в двухуровневой модели. Наконец, использование мониторов транзакций позволяет повысить уровень доступности баз данных.

В системах без разделения ресурсов отсутствует проблема доступа к часто изменяемым блокам. Однако при использовании таких систем в режиме OLTP возникает другая проблема. В большинстве реализаций индексные структуры являются локальными для разделов. Индексы, указывающие на строки раздела таблицы управляются одним экземпляром базы данных. С одной стороны это упрощает реализацию, но с другой стороны - вызывает трудности с масштабированием масштабных OLTP-приложений. В случае, когда транзакция производит сильно селективный индексный доступ к разделенной таблице, а индексный столбец не тот, по которому производилось разделение, СУБД не знает, в каком разделе содержатся желаемые строки. Приходится адресовать запрос ко всем разделам и использовать их локальные индексные структуры. Понятно, что использование широковещательного стиля выполнения запроса приводит к утрате масштабируемости, поскольку сколько бы экземпляров базы данных не добавлялось к системе, все они будут участвовать в выполнении транзакции. Заметим, что локальная индексация вполне хорошо работает в режиме DSS, поскольку в этих системах запросы обычно не слишком селективны, и накладные расходы на широковещание допустимы. Среди систем без разделения ресурсов только Non-Stop SQL демонстрирует хорошую масштабируемость в режиме OLTP.

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

В системах класса OLTP оказывается достаточным использовать оптимизацию запросов, основанную на правилах, или упрощенную оптимизацию, основанную на оценках. Однако в системах класса DSS при наличии сложных и непредсказуемых запросов качество оптимизатора, основанного на оценках, становится критическим фактором. Компания Oracle впервые применила этот подход к оптимизации запросов в версии 7.0 (до этого оптимизация основывалась на использовании правил). В версии 7.3 оптимизатор существенно усовершенствован. Внедрен набор стратегий оптимизации, позволяющих использовать параллелизм для ускорения выполнения отдельных запросов. При оценке стоимости плана запроса используются гистограммные статистики, характеризующие истинное распределение значений столбцов. В версии Oracle8 ожидается появление дополнительных возможностей оптимизации. Компания IBM собирается внедрить стратегии оценочной оптимизации, разработанные в рамках проекта Starburst, в реализации DB2 как для MVS, так и для UNIX. Ожидается, что это произойдет в первой половине 1997 г. с выпуском продукта Common Server. Сервер XPS компании Informix обладает очень высокой производительностью благодаря эффективной реализации алгоритма соединения на основе хэширования с возможностями распараллеливания. Oracle внедрил алгоритм хэширования с соединением в версию 7.3, другие компании собираются скоро это сделать. В СУБД компании Red Brick Systems Inc. используются стратегии оптимизации, специально ориентированные на звезднообразную схему организации баз данных. Благодаря продуманному применению техники индексации и оптимизации для специфических для DSS запросов, во многих случаях продукт демонстрирует производительность, на порядок превосходящую производительность реляционных систем. В продукте Sybase IQ применяется аналогичный подход с комбинацией побитовой индексации и разумного разделения таблиц.

Координаты компаний:

Cray Research Inc. (Silicon Graphics Company): www.cray.com
IBM Corp.: www.ibm.com
Informix Software Inc.: www.informix.com
NCR Corp.: www.ncr.com
Oracle Corp.: www.oracle.com
Sybase Inc.: www.sybase.com
Tandem Computers Inc.: www.tandem.com