Тема номера: Системы высокой готовности

Вайнит Буш,
корпорация Oracle

Архитектура базы данных: Кластерная против Федеративной
(Database Architecture: Federated vs. Clustered,
by Vineet Buch, Oracle Corporation)

Источник: An Oracle White Paper, февраль 2002,
http://otn.oracle.com/deploy/performance/
pdf/TWP_FEDERATEDVCLUSTERED.PDF

• * Краткий обзор
• * Введение
  • * Что такое федеративная база данных
  • * Что такое кластерная с разделяемыми дисками архитектура базы
• * Разработка приложений
  • * Перенесение сложных OLTP-приложений
  • * Разработка новых OLTP-приложений
• * Масштабируемость
• * Работоспособность
• * Управляемость
  • * Что происходит, когда добавляется узел
• * Эталонные TPC-C тесты для федеративных баз данных
  • * Схема теста TPC-C изначально секционирована
  • * Большинство SQL-обращений в TPC-C являются локальными
• * Заключение

 КРАТКИЙ ОБЗОР

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

Эта статья содержит техническую оценку двух различных архитектур баз данных:

• федеративная (federated) архитектура, которую представляет Microsoft SQL Server, и
• кластерная с разделяемыми дисками (shared-disk cluster) архитектура, реализованная в Oracle9i Real Application Clusters.

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

В этой статье не рассматриваются кластеры баз данных типа "shared-nothing" ("разделяемое ничто", без разделения, обособленные - ред.). Федеративные базы данных представляют собой шаг к построению shared-nothing кластеров, на самом же деле они фактически являются всего лишь распределенными (distributed) базами данных. Однако кластерная без разделения (shared-nothing) база данных, типа IBM DB2 7.2 EEE, есть единая база данных, с единственным словарем данных, а не набор свободно связанных баз данных. Сравнение кластеров без разделения (shared-nothing) с диск-разделяемыми (shared-disk) кластерами приводится в другой Белой Книге Oracle: "Technical Comparison of Oracle Real Application Clusters vs. IBM DB2 UDB EEE", которая выложена на http://www.oracle.com.

 ВВЕДЕНИЕ

 Что такое - федеративная база данных?

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

Базовые данные горизонтально (horizontally) секционированы между всеми задействованными серверами. Для каждого DBA-администратора, также как для каждого Разработчика Приложений (Application Developer), существует четкое различие между “местными” (“local”) и “удаленными” (“remote”) данными. Приложения получают единое логическое отображение данных при использовании представлений UNION ALL и распределенного SQL (Distributed SQL). Microsoft называет эту технологию DPV (Distributed Partitioned Views - распределенные секционированные представления). DPV строятся отдельно на каждом узле, поскольку необходимо каждый раз явно задавать, какие секции (partitions) являются местными, а какие удаленными.

Фигура 1: Архитектура федеративной базы данных

Ниже приводится пример как можно разнести клиентов между несколькими серверами в архитертуре Microsoft SQL (код взят web-сайта компании Microsoft по адресу http://msdn.microsoft.com/library/en-us/createdb/cm_8_des_06_17zr.asp).

1. Сначала создаем независимые секции на каждом узле:
-- на Server1:
CREATE TABLE Customers_33
(CustomerID INTEGER PRIMARY KEY
CHECK (CustomerID BETWEEN 1 AND 32999),
... -- Additional column definitions)
-- на Server2::
CREATE TABLE Customers_66
(CustomerID INTEGER PRIMARY KEY
CHECK (CustomerID BETWEEN 33000 AND 65999),
... -- Additional column definitions)
-- на Server3:
CREATE TABLE Customers_99

2. Затем зададим связующую информацию (“linked server definitions” - "определения серверных связей") и опции оптимизации запросов на каждом задействованом сервере.

3. Наконец, создадим DPV-представления на каждом узле. Здесь приведен код только для Server1:

CREATE VIEW Customers AS
SELECT * FROM
CompanyDatabase.TableOwner.Customers_33
UNION ALL
SELECT * FROM
Server2.CompanyDatabase.TableOwner.Customers_66
UNION ALL

Подобные, но отдельные представления должны быть созданы на каждом узле.

Федеративная база данных представляет собой распределенную базу, несколько расширеную представлениями UNION ALL, которые логически объединяют физически разнесенные данные.

Когда предложения SELECT при обращении к представлению Customers специфицируют поиск по CustomerID - столбцу секционирования, оптимизатор запросов использует определение CHECK-ограничения, чтобы определить, в таблице какого участника [базы] содержатся нужные строки. DPV-представления могут использоваться не только для запросов, но с некоторыми ограничениями и для обновления строк. При UPDATE оптимизатор запросов применяет ту же самую технологию для определения искомой таблицы участника. Федеративные базы данных не оснащаются каким-либо глобальным словарем данных, поэтому оптимизатору должны быть доступны все узлы, чтобы определить план выполнения запроса.

Таким образом федеративная база данных представляет собой распределенную базу данных с надстроенной DPV-технологией. DPV-представления расширяют представления UNION ALL и распределенный SQL, переадресовывая (базируясь на предикатах по ключу секционирования) обращающиеся к UNION ALL представлениям SQL-предложения к соответствующим распределенным серверам.

 Что такое кластерная с разделяемыми дисками архитектура базы данных?

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

Фигура 2: Конфигурация кластерной с разделяемыми дисками базы данных.

Кластерные с разделяемыми дисками базы данных реализуют сложные cache-sharing алгоритмы (алгоритмы разделения (совместного использования) кеша оперативной памяти - ред.), которые скрывают сложность аппаратных средств.

На каждом узле кластера функционирует свой экземпляр базы данных. Транзакции, запускаемые в любом экземпляре, могут читать и обновлять любую часть базы данных - нет никакой привязки к конкретным узлам. Работоспособность системы основана на использовании быстрой и эффективной системы связи между узлами кластера, например, Virtual Interface Architecture (VIA). Oracle9i Real Application Clusters (RAC) является первой удачной реализацией кластерной с разделяемыми дисками архитектуры и использованием изощренных алгоритмов разделения кешей (shared-cache), что совокупно именуется Cache Fusion ™ (объединенный, или слитый кеш - ред.). Эта технология обеспечивает высокую производительность и масштабируемость без разнесения данных и приложений.

Cache Fusion ™ - это:

• Коллективное использование (быстрых) кешей всех узлов системы базы данных, чтобы обеспечить на любом узле узле запросы к прикладным данным, то есть имеет место действительное "слияние" кешей всех узлов кластера в единый кеш;
• Исключение (медленных) дисковых операций из критической цепочки действий при межузловой синхронизации данных: если два узла оперируют с одним и тем же блоком данных, они синхронизируют действия через свои кеши без перезаписи этого блока на диск;
• Существенное сокращение требуемого количества сообщений между узлами для обеспечения синхронизации их действий;
• Применение кластер-связующих протоколов с низким временем ожидания (low-latency), как для обмена сообщениями базы данных, так и для переправки данных между кешами.

Что на RAC, что на SMP версиях Oracle приложения используют тот же самый программный интерфейс. Cache Fusion ™ скрывает от приложения лежащую в основе архитектуру кластера.

В следующих секциях мы сравним и противопоставим Федеративную и Диск-разделяемую архитектуры баз данных по следующим направлениям:

• Разработка Приложений (Application Development)
• Масштабируемость (Scalability)
• Работоспособность (Availability)
• Управляемость (Manageability)
• Эталонное тестирование (Benchmarking)

 РАЗРАБОТКА ПРИЛОЖЕНИЙ

Oracle9i Real Application Clusters (RAC) не налагает никаких дополнительных ограничений на разработчика приложений. Любое приложение, даже сложное OLTP-приложение, подобное SAP или Oracle e-Business Suite, написанное для использования Oracle9i на SMP-платформе, функционирует без модификации на диск-разделяемом кластере, управляемым RAC. База данных, как единый образ, без секционирования данных, переносится с SMP на кластер.

Напротив, в федеративных базах, типа Microsoft SQL Server, единая база данных раскалывается на многочисленные самостоятельные базы данных. Данные должны быть или распределены между базами-участниками (для приложений, в которых много больших и часто обновляемых таблиц, например, Order Lines), или реплицированы (для приложений, в которых имеются таблицы с контрольными данными (reference data), которые необходимо одинаково использовать на каждом узле, например, Item). Распределение строк данных между базами требует создания распределенных секционированных представлений (Distributed Partition Views), уникальных на каждом узле. А реплицируемые таблицы должны поддерживать синхронизацию (sync) по всем базам данных, используя настраиваемые триггеры INSTEAD OF.

 Портирование сложных OLTP-приложений

Популярные OLTP-приложения (от тех же SAP, PeopleSoft или Oracle) включают тысячи таблиц и уникальных глобальных индексов. Индекс определяется как глобальный, когда он обслуживает (индексирует) все строки единой логической таблицы, независимо от того, на сколько физических таблиц она разделена.

	К-во таблиц	Число индексов перв. ключей (Primary Key)	Число индексов доп. ключей (Alternate Key)
PeopleSoft Oracle eBusiness Suite (ERP only SAP	7493  8155 16500	6438     800 16239	900 5100 2887

Таблица 1. Количество иаблиц и индексов в популярных OLTP-приложениях

Эти приложения для быстрого доступа к данным и обеспечения целостности данных требуют применения глобальных уникальных индексов не только на столбцах первичных ключей. Например, уникальный индекс на столбце Customer_Number в таблице RA_Customers в Oracle eBusiness Suite гарантирует, что существует только один клиент с конкретным значением уникального бизнес-ключа (но это - не первичный ключ!) Customer Number (номер клиента). Без этих индексов жизненно важные прикладные данные могли бы быть повреждены, сдублированы или потеряны.

Приложения никогда не осуществляют "чистый" доступ к данным. Невозможно так определить ключи секционирования прикладных таблиц, чтобы доступ к "локальным" данным был наиболее преобладающим, то есть такими запросами, условия которых могли бы быть удовлетворены исключительно содержанием одной секции данных. Наиболее важные запросы в SAP, PeopleSoft, Oracle eBusiness Suite осуществляют доступ к соединению из нескольких таблиц, и различные запросы используют различные дополнительные ключи в предикатах соединений. А доступ к нелокальным данным необходимо связан с избыточными действиями, снижением производительности за счет выполнения частых распределенных транзакций.

Реально существующие в мире OLTP-приложения на самом деле не могут быть перенесены для функционирования на федеративных базах данных.

Таким образом, чтобы перенести PeopleSoft или SAP на федеративную базу данных SQL Server, потребовалось бы создание и управление тысячами DPV (по одному представлению на каждую разделенную таблицу) - задача по силам разве что Геркулесу (Herculean). А так как DPV не могут поддерживать глобальные уникальные индексы на дополнительных ключах, это мероприятие могло бы привести к серьезным нарушениям целостности важнейшей бизнес-информации. Следовательно, существующие OLTP-приложения не могут быть портированы для функционирования на федеративных базах данных.

Приложения же, разработанные для Oracle9i на SMP, не требуют никаких усилий при переносе на Oracle9i Real Application Clusters.

 Разработка новых OLTP-приложений

Базы данных федеративной конфигурации не обладают также рядом других возможностей, которые необходимы для разработки любого OLTP-приложения, включая даже те приложения, в которых можно было бы пробовать работать без глобальных уникальных индексов на дополнительных ключах. Такими важные механизмами, которые поддерживает каждый отдельный узел SQL Server, но которые не обеспечиваются при использовании DPV-представлений в федеративных базах данных с многжественными узлами, являются:

• Отсутствие уникальных (других, нежели первичный ключ) столбцов на всей федерации базы
• Триггеры (Triggers)
• Ограничения проверки (Check constraints)
• Атрибуты DEFAULT, TIMESTAMP, IDENTITY
• Ссылочные ограничения целостности (Referential integrity constraints)

Эти возможности необходимы для OLTP-приложений, и все главные продавцы баз данных обеспечивают их в своих SMP-предложениях. Oracle9i Real Application Clusters же предоставляет перечисленные возможности в диск-разделяемых архитектурах.

Таким образом, федеративные базы данных не подходят для применения OLTP- приложений, тогда как диск-разделяемые архитектуры являются хорошей платформой для развития OLTP.

 МАСШТАБИРУЕМОСТЬ

Масштабируемость (Scalability) - первый стимул для клиента, чтобы перейти от SMP-платформы к многоузловой вычислительной среде, типа федеративной или диск-разделяемой архитектуры. Однако, в федеративной базе данных имеются ей свойственные барьеры по масштабируемости. Например, в федеративной SQL Server запросы к DPV масштабируются с повышением только, если ключ секционирования включается в предикат запроса. А если ключ секционирования не является частью предиката запроса, то производительность снижается (большее количество узлов ведет к худшему выполнению).

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

Рассмотрим федеративную базу данных с 10 узлами с DPV-представлением на таблице Employee со столбцами (Employee Number Primary Key, Email, …). Классический OLTP-запрос с использованием дополнительного ключа, например:

SELECT * FROM Employee 
   WHERE EMAIL = ‘joe.smith@acme.com’ 

обработается на всех 10 узлах, хотя возвратит только одну строку. Если Вы добавите еще несколько узлов (скажем, до 12), этот запрос выполнится еще хуже, так как теперь будет требоваться ответ от 12 узлов, вместо 10.

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

И напротив, уже начиная 90-ых годов, версии диск-разделяемых кластеров (таких, как IBM DB2-Sysplex для Mainframe или Oracle Parallel Server (параллельный сервер Oracle)) очень хорошо масштабировали с повышением рабочую нагрузку, главным образом, по чтению при использовании дополнительных ключей. А Oracle 9i Real Application Clusters очень хорошо повышает производительность на типичных для OLTP рабочих нагрузках по чтению-записи при использовании дополнительных ключей. Стало очевидным, что масштабируемость диск-разделяемого кластера - это очень хорошее качество, которое постоянно улучшается, поскольку поставщики непрерывно совершенствуют реализацию технологии разделяемого кеша. Нет никаких архитектурных подводных камней, препятствующих повышению масштабируемости диск-разделяемых кластерных баз данных.

Тестирование характеристик производительности реально существующих в мире приложений, подобно SAP, показало, что масштабность приложения растет почти линейно (90 %) в зависимости от увеличения (2 -> 4 -> 8) числа узлов в RAC-кластере.

Примечание. Тестовые испытания Oracle9i RAC, SAP® R/3® 4.6C проводились в декабре 2001 компаниями Compaq и Oracle на ES45 AlphaServer кластерах под операционной системой Tru64 UNIX. Каждый сервер базы данных был оснащен четырьмя Alpha CPU, по 1GHz каждый, с восьми мегабайтным кешем уровня L2.

Фигура 3: Показанная при тестировании почти линейная масштабируемость SAP на RAC при использовании SAP SD 3-tier

 РАБОТОСПОСОБНОСТЬ

Данные в федеративных базах разнесены по базам данных, и каждая база данных принадлежит отдельному узлу. Единственный путь доступа к данным, принадлежащим какому-либо узлу, - это запрос требуемых данных от узла и исполнение узлом сделанного запроса. Таким образом, когда узел сбоит (fail), данные, которые на нем находятся, становятся недоступными. И все текущие (in-flight) распределенние транзакции, выполняемые этим узлом, могут заблокировать данные на других узлах. Восстановление после отказа узла требует дополнительных действий по разрешению этих текущих транзакций. При восстановлении выполняется ряд ручных шагов, которые требуют, чтобы система была в автономном (offline) режиме. Microsoft рекомендует, чтобы для каждого узла-участника имелся бы запасной (failover - отказоустойчивый - ред.) узел, что, тем самым, удваивает требования к аппаратному обеспечению, а также сложность и стоимость конфигурации.

С другой стороны, когда отказывает узел диск-разделяемого кластера, все данные остаются доступными для других узлов. Текущие транзакции задействованных узлов откатываются назад (rolled back), так что никакие данные не блокируются отказавшим участником. В Oracle9i Real Application

Clusters реализовано автоматическое восстановление после отказа узла. После обнаружения отказа узла кластер автоматически реконфигурируется и осуществляется те же самые процессы восстановления наката/отката (roll-forward/roll-back), которые работают в вычислительной среде SMP. Если приложения используют функциональность Transparent Application Failover (прозрачная отказоустойчивость приложений), которая обеспечена посредством Oracle Call Interface (OCI - интерфейс вызовов Oracle), то их пользователи [соединенные] с отказавшим узлом переключаются на другой узел кластера и могут продолжать работу без прерывания.

После многих дней или недель непрерывной работы (uptime) в буферном кеше каждого экземпляра мощной многоузловой базы данных содержится большое число блоков базы данных. Так, в ноябре 2001 Oracle и HP опубликовали результаты TPC-C тестирования 100GB буферного кеша базы данных. Вследствие использования технологии Cache Fusion ™ в Oracle 9i Real Application Clusters, большое число блоков данных были обнаружены в кешах более чем одного узла кластера именно потому, что OLTP-данные не могут приемлемым образом разделены по узлам. Следовательно, когда узел восстанавливается после отказа, нет надобности заново загружать его кеш с диска при очередных обращениях к данным. Вместо этого можно получить блоки данных из кешей его соседей по кластеру. Это существенно уменьшает накладные издержки ввода/вывода при восстановлении после отказа узла.

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

 УПРАВЛЯЕМОСТЬ

Легкость управления (manageability - управляемость) RDBMS пропорциональна числу определенных и поддерживаемых объектов. При переходе от базы данных с одним экземпляром (среда SMP) к многоэкземплярной базе данных федеративной или диск-разделяемой архитектуры, Вы несете накладные издержки по инициализации и управлению специфическими для каждого экземпляра конфигурационными параметрами. Таким образом, переход от одиночного экземпляра Oracle9i к многоузловому Real Application Clusters потребует поддержки:

• Конкретных конфигураций каждого экземпляра и параметров его настройки (init-параметры). Большинство этих параметров, вероятно, будет одинаково среди всех узлов;
• Журналов восстановления (Recovery logs) каждого экземпляра.

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

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

 Что случается, когда добавляется узел?

DPV-представления логически объединяют данные, распределенные между узлами федеративной базы данных SQL Server. Добавление узла к федеративной базе данных изменяет распределение (portioning) данных и, следовательно, изменяет выполнение DPV-представлений. Перечислим, что некий администратор базы данных (DBA) или системный администратор (Sysadmin) должен сделать, чтобы добавить узел к федеративной базе данных SQL Server:

• Добавить аппаратные средства ЭВМ;
• Сконфигурировать новый экземпляр (установить специфические параметры экземпляра и т.д.);
• Создать новую базу данных;
• Отсоединить всех пользователей;
• Разгрузить все данные из существующих таблиц;
• Переопределить секционированные таблицы и индексы;
• Переопределить триггеры на секционированных и реплицируемых таблицах;
• Переопределить DPV-представления;
• Перезагрузить все данные так, чтобы разнести их между большим числом секций;
• Повторно подсоединить всех пользователей.

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

Беспроблемное добавление узла к диск-разделяемому кластеру при использовании Oracle 9i Real Application Clusters.

С другой стороны, рассмотрим задачи управления, необходимые при добавлении узла к Oracle9i Real Application Clusters:

• Добавление аппаратных средств;
• Конфигурация нового экземпляра (установка специфические параметры экземпляра и т.д.);

И все! Никакие данные не разгружаются и не перезагружаются, никакого автономного режима - масштабирование без сучка и засоринки.

Таким образом, мы видим, что диск-разделяемые кластеры, подобные Oracle9i Real Application Clusters, намного более легки в управлении (на несколько порядков), чем федеративные базы данных, подобные Microsoft SQL Server.

 ЭТАЛОННЫЕ ТЕСТЫ TPC-C НА ФЕДЕРАТИВНЫХ БАЗАХ ДАННЫХ

Эталонный тест TPC-C (в настоящее время версия 5.0) широко используется как индикатор масштабируемости баз данных для OLTP и соответствующих им аппаратных средств ЭВМ. Эталонный тест моделирует часть приложения ввода заказов для поставщика дискретных изделий. Эталонный тест измеряет количество транзакций в минуту (tpmC - transactions/minute) по новым заказам (New Order), каждые из которых разворачивается в несколько транзакций: присоединение определенных процентов на зарплату (Payment), статус заказа (Order Status), поставка (Delivery) и уровень запаса (Stock Level). Результаты опубликованы на сайте Transaction Processing Council (TPC) (http://www.tpc.org) по двум категориям: тестирание кластеров и не кластеров. TPC приводит эталонные тесты TPC-C на федеративных базах данных в сравнении с кластеризованными результатами. Собрав огромное числа CPU в свободно соединенных конфигурациях, различные поставщики получили очень большие значения TPC-C для федеративных базах данных, особенно для Microsoft SQL Server. На предыдущих страницах этой статьи было показано, что федеративные базы данных не подходят для магистрального развития OLTP-приложений. Почему же тогда самый высокий результат тестирования по TPC-C показала федеративная базы данных Microsoft SQL Server?

Ответ в том, что TPC-C, являясь скорее синтетическим тестом, нежели оценкой рабочей нагрузки реального клиента, имеет некоторые особенности, под которые подстраивались, чтобы получить хорошие результаты в федеративной архитектуре. Такими атрибутами TPC-C, которые не представляют реальности современных OLTP-приложений, являются:

•  Схема TPC-C по своей природе секционирована

Фигура 4: Схема TPC-C.

•  Большинство SQL-обращений в TPC-C являются локальными

Тавлица 2: Локальные данные в секционированной схеме TPC-C

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

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

Объект назначения тестовых данных, а им является клиент базы данных!, должен знать эти особенности эталонного TPC-C теста до того, как ему сообщат результаты “кластерного” тестирования. Результаты, полученные на федеративных базах данных, имеют небольшое, если вообще таковое имеется, соответствие с производительностью базы данных для реально существующих OLTP-приложений.

 ЗАКЛЮЧЕНИЕ

В этой статье было проведено сравнение федеративных баз данных (на примере Microsoft SQL Server) с диск-разделяемыми кластерными базами данных (представителем которых является Oracle9i Real Application Clusters). Было показано, что федеративные базы данных - всего лишь слабые кандидаты для использования в разработке реальных мирового масштаба OLTP-приложений. В то же время диск-разделяемые кластеры очень хорошо поддерживают OLTP-приложения. Мы убедились, что федеративным базам данных присущи существенные недостатки в следующих областях:

• Разработка Приложений;
• Масшабируемость;
• Работоспособность;
• Управляемость.

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