Интеграция данных и композитные бизнес-сервисы: Часть 3. Создание уровня данных множественной принадлежности с контролем доступа и системой защиты

В этой статье, третьей в данной серии, рассказывается, как возможности IBM® DB2® помогают решить проблемы, связанные с архитектурой данных и их защитой в реализации Software as a Service (SaaS). Основной заботой потребителя SaaS является защищенность данных. Основной заботой провайдера SaaS является архитектура данных, обеспечивающая эффективные с точки зрения затрат администрирование и обслуживание данных и одновременно удовлетворение потребностей потребителей сервиса. DB2 9 предоставляет возможности хранения XML, что упрощает конфигурируемость и расширяемость данных. DB2 9 также предоставляет авторизацию на уровне строки. DB2 V8 и более поздние версии предоставляют технологии сегментирования и резервирования, решающие задачи масштабируемости и обслуживания. В настоящей статье вы познакомитесь с тем, как эти функциональные возможности DB2 могут использоваться для создания архитектуры данных множественной принадлежности (multi-tenant data architecture). Такая архитектура данных решает основные проблемы как потребителей, так и провайдеров SaaS.

Мэри Тейлор, старший архитектор информационных систем, IBM

Мэри Тейлор (Mary Taylor) является старшим разработчиком архитектуры информационных систем. Она работает в группе Strategic Technology Architecture and Incubation (STAI) и в данный момент занимается пилотным проектом SOA CBS. Среди ее интересов DB2 и DataStage.



Чанг Джи Гуо, сотрудник отдела исследований, научный сотрудник, IBM

Чанг Джи Гуо (Chang Jie Guo) – фотографияЧанг Джи Гуо (Chang Jie Guo) работает над сервисами следующего поколения в отделе исследований IBM China Research Lab, Пекин, Китай. В последние годы занимался некоторыми ключевыми технологиями в области Software as a Service (SaaS), включая массовую множественную принадлежность (multi-tenancy), динамичное управление бизнес-процессами (Business Process Management – BPM) и Web 2.0.



12.04.2010

Введение

Для SaaS-приложения существуют разные степени изоляции данных – от изолированной среды до полностью общей. В этом спектре можно выделить следующие реализации:

  • Полностью изолированные: отдельная база данных для каждого владельца
  • Частично общие: общая база данных, отдельная схема
  • Полностью общие: одна и та же база данных, одна и та же схема
Рисунок 1. Сравнение изолированной и общедоступной среды
Рисунок 1. Сравнение изолированной и общедоступной среды

На рисунке 1 сравниваются варианты изоляции с точки зрения простоты конфигурирования:

  • Слева показана изолированная среда E1. Каждый владелец имеет свою собственную базу данных. E1 предлагает наибольшую гибкость с точки зрения конфигурирования, так как таблицы спроектированы с пользовательскими столбцами для поддержки единственного владельца.
  • В середине показана общая база данных с индивидуальными схемами E2. E2 предлагает меньшую степень изоляции данных по сравнению с E1. E2 предлагает такое же конфигурирование, как и E1 (при помощи пользовательских столбцов).
  • Справа показана среда с общей схемой E3. Этот подход обычно рассматривается как самый трудный для настройки. Он требует использования либо столбцов с парами имя/значение, либо предварительно размещенных полей для удовлетворения уникальных требований владельцев.

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

Обзор подхода

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

  1. Защищенность данных

    Защищенность данных – это способ, используя который, вы гарантируете, что каждый владелец имеет доступ только к своим данным. В изолированной среде каждый владелец имеет свою собственную базу данных, и доступ администрируется на уровне базы данных. Но при переходе на общую среду, в которой данные нескольких владельцев размещаются в одной и той же базе данных или в одних и тех же таблицах, необходимо подумать о дополнительных механизмах защиты, например, о доступе к данным на уровне строк или о представлениях (views) данных для владельцев. В данной статье рассматривается управление доступом на уровне строк, которое предоставляет DB2.

  2. Масштабируемость и производительность

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

  3. Обслуживание

    Общая инфраструктура также поднимает вопросы обслуживания, особенно связанные с операциями создания резервных копий и восстановления. Традиционная поддержка на уровне СУБД сконцентрирована только на некоторых аспектах данной функциональности, таких как обслуживание баз данных и табличных пространств, и не учитывает новый фактор – владельцев. В данной статье обсуждается эта тема и предлагается практический подход.

  4. Расширяемость

    Четвертой темой, которая будет рассмотрена в данной статье, является расширяемость базы данных в общей среде. Одно из преимуществ реализации уровня изолированных данных, или даже уровня общих данных с индивидуальными схемами, заключается в том, что изменения в базе данных для одного владельца можно сделать непосредственно в таблицах базы данных без учета влияния этих изменений на других владельцев. Недостатком реализации уровня данных с общей схемой является сложность реализации настройки данных владельца. В статье описывается, как использование pureXML DB2 9 упрощает эту настройку до такой степени, что простота использования становится сравнимой с использованием специализированных столбцов на уровне изолированных данных.

1. Защищенность данных

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

1.1. Изоляция управления доступом к данным на уровне приложения

Когда один владелец пытается обратиться к общим таблицам, обработка этого запроса на доступ делегируется общей учетной записью базы данных. Она является общей для всех пользователей и обладает привилегиями на доступ ко всем данным определенного владельца в общих таблицах. Делегированная учетная запись является уникальной среди различных владельцев. В SQL-выражение необходимо вставить подзапрос "where tenant_id = xyz" для фильтрации записей, не принадлежащих текущему владельцу. Например, такой запрос приложения, как Select name, address, phone from customerData должен быть переписан следующим образом: Select name, address, phone from customerData where tenant_id='xyz'.

1.1.1. Ограничения контроля доступа к данным на уровне приложения для множественной принадлежности

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

Оригинальное SQL-выражение:

SELECT * FROM SALES_ORDER WHERE TENANTID = 'xyz' AND SOID = '" + Order_Id + "'

Если переменная Order_Id формируется пользователем-злоумышленником специфичным способом, SQL-выражение может выполнить больше, чем подразумевал автор кода. Например, установив переменную Order_Id как:

'123' or '0'='0'

мы получим новое SQL-выражение:

SELECT * FROM SALES_ORDER WHERE TENANTID = 'xyz' AND SOID = '123' or '0'='0'

Очевидно, что в данном случае будет иметь место нелегальный доступ к данным всех владельцев в общей таблице.

1.2. Изоляция управления доступом на уровне СУБД посредством LBAC

Label-Based Access Control (LBAC) – это новая функциональная возможность системы защиты, предоставляемая DB2 9. Она позволяет точно решить, кто имеет доступ по чтению и записи к отдельным строкам и отдельным столбцам, значительно увеличивая, таким образом, уровень вашего контроля над тем, кто может обращаться к данным. LBAC управляет доступом к объектам таблиц посредством использования защитных меток (security label) и политик безопасности (security policies). Защитные метки идентифицируют критерий, используемый для принятия решения, кто должен иметь доступ к определенным частям данных в базе. Защитные метки могут ассоциироваться с отдельными строками и столбцами базы данных и предоставляются пользователям, чтобы разрешить им обращаться к этим данным. Политики безопасности описывают критерий, использующийся при принятии решения о том, кто имеет доступ и к каким данным. Пользователи, пытающиеся обратиться к объекту, должны иметь предоставленную им защитную метку. Если есть соответствие, доступ разрешается, в противном случае – запрещается.

Рисунок 2. Взаимосвязи объектов LBAC
Object relationships of LBAC

На рисунке 2 показаны основные взаимосвязи объектов в LBAC. Имеется три типа защитных меток, которые ассоциируются и предоставляются трем различным объектам базы данных соответственно – строка, столбец и пользователь. Защитная метка состоит из одного или нескольких компонентов меток. Защищенная таблица должна иметь столбец с типом DB2SECURITYLABEL, в котором хранятся защитные метки, используемые для подключения политики безопасности к таблице. Пользователям предоставляется доступ к соответствующим защитным меткам для доступа к защищенной таблице во время исполнения. Подробная информация о LBAC приведена в документах "Руководство администратора DB2 V9: Реализация" и "DB2 Label-Based Access Control: Практическое руководство" (developerWorks, май 2006) (EN).

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

Чтобы избежать потенциальной угрозы SQL-внедрения, описанной выше, необходимо настроить отдельную учетную запись для каждого владельца. Это означает, что запросы от различных владельцев на доступ к данным этих общих таблиц обрабатываются с использованием различных учетных записей базы данных. Таким образом, можно воспользоваться преимуществами механизма LBAC, чтобы гарантировать изоляцию контроля доступа владельцев на уровне СУБД.

На рисунке 3 показан базовый подход для поддержки сценария с множественной принадлежностью. Набор LBAC-правил – это предопределенный набор правил, использующихся при сравнении защитных меток. При сравнении значений двух защитных меток одно или несколько правил из набора используются для определения того, блокирует ли одно значение другое. В DB2 9 есть один набор правил под названием DB2LBACRULES. В этом наборе правил имеется 16 предварительно скомпонованных компонентов защитных меток, и каждый из них имеет 64 независимых элемента. В примере, приведенном ниже, для общей таблицы SALES_ORDER создается политика безопасности под названием "MTSecurityPolicy_Sales_Order" с набором защитных меток внутри. Каждая защитная метка содержит один элемент, выбранный из 16 компонентов меток. Имя защитной метки сохраняется в столбце DB2SECURITYLABEL таблицы SALES_ORDER и является механизмом, ассоциирующим владельца с его данными. Чтобы гарантировать изоляцию контроля доступа владельца, на один и тот же элемент не должна ссылаться более чем одна метка.

При размещении владельца оператор может просто выбрать одну неиспользованную метку и предоставить ее учетной записи владельца. Например, в показанном на рисунке 3 сценарии администратором базы данных могли бы быть выполнены следующие команды при размещении TenantA, TenantB и TenantX:

  • GRANT SECURITY LABEL MTSecurityPolicy_Sales.0001 to USER TenantA for all access
  • GRANT SECURITY LABEL MTSecurityPolicy_Sales.0002 to USER TenantB for read access
  • GRANT SECURITY LABEL MTSecurityPolicy_Sales.1024 to USER TenantX for delete access

При использовании LBAC SQL-внедрение никогда не будет проблемой, поскольку доступом владельцев к данным управляет менеджер базы данных на уровне СУБД, а не система защиты на уровне приложения.

Рисунок 3. Простой LBAC-механизм поддержки множественной принадлежности
Рисунок 3. Простой LBAC-механизм поддержки множественной принадлежности

1.2.1. Ограничения DB2 LBAC для множественной принадлежности

В текущей версии LBAC, предоставляемой в DB2 9, для политики безопасности можно указать не более 16 компонентов защитных меток, и каждый компонент может содержать не более 64 элементов. Следовательно, если каждая защитная метка использует один элемент для изоляции каждого владельца, как показано на рисунке 3, максимальное число поддерживаемых владельцев не может превышать 1024 (16×64).

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

Рисунок 4. Изолирующие владельцев защитные метки с двумя элементами
Рисунок 4. Изолирующие владельцев защитные метки с двумя элементами

2. Масштабируемость и производительность

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

Существуют два традиционных подхода к масштабированию:

  • Масштабирование вверх (масштабирование по вертикали) путем добавления дополнительных ресурсов (таких как CPU, память и дисковое пространство) к существующим машинам. Это простой в использовании и управляемый подход. Однако он может не обеспечить линейную масштабируемость. При добавлении ресурсов существуют определенные накладные расходы на их обслуживание, ограничивающие масштабируемость отдельных систем.
  • Масштабирование вширь (масштабирование по горизонтали) через добавление дополнительных машин к существующей системе. По сравнению с вертикальным масштабированием этот подход обеспечивает более рентабельное и плавное масштабирование, поскольку позволяет постепенно расширять систему путем добавления дополнительных ресурсов к изначально недорогому набору аппаратного обеспечения. Хотя данный тип масштабирования неминуемо приведет к увеличению сложности обслуживания, он может также улучшить надежность и доступность системы, в некоторых случаях благодаря избыточности.

DB2 предоставляет много разных технологий для эффективной поддержки обоих механизмов масштабирования. Дополнительная информация содержится в IBM Redbooks® "Руководство по высокой готовности и масштабированию для DB2 на Linux, UNIX и Windows" и "Руководство по развертыванию среды интегрированных кластеров DB2", ссылки на которые приведены в разделе "Ресурсы".

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

2.1. Сегментирование базы данных

Функциональность сегментирования базы данных (Database Partitioning Feature – DPF) DB2 9 расширяет возможности DB2 в параллельной среде с несколькими сегментами, улучшая производительность и масштабируемость очень больших баз данных. В сценарии масштабирования вверх можно создать более одного сегмента базы данных на одной и той же физической машине для использования преимуществ архитектуры SMP. В сценарии масштабирования вширь сегменты можно создать на нескольких физических машинах. Каждый сегмент имеет свою собственную память, CPU, диски и элементы управления дисками.

Данные в базе можно распределить по одному или нескольким сегментам, ассоциированным с группами сегментов базы данных. Ключ распределения (distribution key) – это столбец (или группа столбцов), используемый для определения сегмента, в котором хранится конкретная строка данных. Значение ключа распределения хэшируется для генерирования значения индекса карты распределения (в диапазоне от 0 до 4095), которое отображается на сегмент базы данных, размещающий запись.

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

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

2.1.1. Ключ распределения, основанный на приложении

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

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

Обычно ключ распределения указывается в выражении CREATE TABLE. В данном примере в качестве ключа распределения выбран столбец REGION таблицы SALES_ORDER через выражение DISTRIBUTED BY HASH("REGION"). При помощи алгоритма хэширования записи о заказах различных регионов распределяются по различным сегментам равномерно, независимо от того, какому владельцу они принадлежат. Каждый запрос центральный координатор направляет на несколько узлов и возвращает полученные данные владельцу.

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

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

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

2.1.2. Ключ распределения, основанный на владельцах

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

Рисунок 6. Пример сегментирования базы данных, основанного на владельце
Рисунок 6. Пример сегментирования базы данных, основанного на владельце

Как показано на рисунке 6, при размещении нового владельца оператор SaaS-приложения назначает фиксированный идентификатор владельца и значение DBPKey, отображаемое на определенный сегмент базы данных. Эти метаданные сохраняются в репозитории для поддержки взаимосвязей между владельцами и сегментами. При получении запроса на доступ к данным сначала из репозитория метаданных извлекается значение DBPKey владельца и к оригинальному SQL-выражению присоединяется подзапрос DBPKEY=xyz. Затем менеджер базы данных автоматически направляет запрос в соответствующий сегмент, в котором размещены данные владельца.

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

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

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

2.2. Сегментирование таблиц

Сегментирование таблиц обеспечивает способ создания таблицы, при котором данные хранятся раздельно. Его достоинства проявляются как в оптимизации производительности, так и в гибкости обслуживания. С одной стороны, он может потенциально повысить производительность запросов через устранение сегментирования данных. С другой стороны, он может также значительно облегчить управление данными, предоставляя возможности развертывания и свертывания сегментов, используя операторы attach и detach в выражении ALTER TABLE. Как объясняется в следующем разделе, эти две возможности являются важными в сценариях с множественной принадлежностью.

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

Например, как показано на рисунке 7, столбцы TPKey и REGION таблицы SALES_ORDER скомбинированы вместе для формирования объединенного ключа. Для запросов одного владельца можно извлечь соответствующее значение TPKey из репозитория метаданных и добавить его к оригинальному SQL-выражению для исключения сегмента таблицы. Исключение сегмента – это способность оптимизатора определить, что к некоторым диапазонам вообще не нужен доступ для запроса. Это значительно повышает производительность приложений с множественной принадлежностью, поскольку все запросы от одного владельца направляются только в выделенные ему сегменты таблицы. Например, запрос владельца А работает только с сегментами таблицы PAT_0E, PAT_0N и PAT_0S. Более того, изолируя данные различных владельцев в выделенных им сегментах таблицы, можно легко загрузить (выгрузить) и выполнить миграцию данных владельца из общей таблицы, используя функциональные возможности DB2 9 свертывания (roll-in) и развертывания (roll-out). Эти возможности позволяют легко добавлять и удалять сегменты данных из таблицы без перевода базы данных в автономный режим работы.

Рисунок 7. Пример сегментирования таблицы, основанного на владельцах
Рисунок 7. Пример сегментирования таблицы, основанного на владельцах

3. Обслуживание

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

DB2 предоставляет поддержку интерактивного инкрементного резервирования и отмены отката (roll-forward) на уровне табличных областей. Более подробная информация по этой теме содержится в книге "Руководство и справочник по восстановлению данных и обеспечению высокой готовности", ссылка на которую приведена в разделе "Ресурсы". Вот два примера.

  • Интерактивное инкрементное резервное копирование табличной области tbsp1 в базе данных testdb:

    db2_all 'db2 BACKUP DB testdb TABLESPACE tbsp1 ONLINE INCREMENTAL TO /home/db2inst1/BACKUPS include logs'

  • Интерактивная отмена отката табличной области tbsp1 в базе данных testdb:

    db2_all 'db2 ROLLFORWARD DB testdb to 2007-10-31-14.21.56.245378 and stop TABLESPACE(tbsp1) online'

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

Рисунок 8. Пример обслуживания табличной области, основанного на владельцах
Рисунок 8. Пример обслуживания табличной области, основанного на владельцах

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

4. Расширяемость

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

  • Пользовательские представления (user views). Представления, созданные на базе общих таблиц базы данных, в которые включены данные только одного владельца. Доступ к представлениям предоставляется владельцу этих данных. Представления выбирают строки по идентификатору владельца и содержат специфичные столбцы таблицы, которыми он интересуется. При добавлении новых столбцов представления других владельцев не нуждаются в повторном создании, пока другие владельцы не захотят включить новый столбец.
  • Предварительно размещенные столбцы (preallocated columns). Создание фиксированного числа дополнительных столбцов в каждой таблице с общим определением (например, varchar (x)). Содержимое этих столбцов должно быть настроено посредством логики приложения в пользовательском интерфейсе (например, приведено к числовому формату или формату даты), позволяя каждому владельцу использовать столбцы подходящим ему способом. Этот подход имеет несколько недостатков. Поскольку столбцы существуют в каждой строке таблицы, для тех владельцев, которые не используют дополнительные столбцы, пространство расходуется неэффективно. Если владельцы, которым требуется большое количество специализированных столбцов, израсходуют все дополнительные столбцы, вам придется изменить таблицу и добавить новые столбцы, потенциально влияя на остальных владельцев.
  • Таблицы расширения (extension tables). Таблицы, использующие идентификатор владельца в качестве ключа и сохраняющие дополнительные специфичные для владельца элементы данных через использование идентификатора записи в соединении с идентификатором владельца. В этом сценарии идентификатор владельца в оригинальной таблице используется для соединения с таблицей расширения с целью помещения в нее дополнительных специфичных для владельца элементов данных, которые не содержатся в базовой таблице, используемой всеми владельцами. Этот подход предпочтительнее предварительно размещенных столбцов, поскольку дополнительные поля размещаются только у тех владельцев, которые их используют.

Данный раздел посвящен четвертой стратегии реализации для общей схемы, а именно – использованию возможностей pureXML DB2 9. DB2 9 хранит XML-данные в иерархической структуре, которая естественным образом отражает структуру XML. Эта структура вместе с новыми методиками индексирования позволяет DB2 эффективно управлять такими данными и избежать сложного и затратного по времени синтаксического анализа, обычно необходимого для XML. Использование подобного подхода поднимает два вопроса:

  • XML-хранилища уже применяются какое-то время. Какие преимущества хранение в формате pureXML имеет в сравнении с существующими механизмами хранения, такими как CLOB-формат и расщепление (shredding)?
  • Какое преимущество хранение данных в формате pureXML имеет в сравнении с традиционным SQL-форматом в контексте расширяемости?

4.1. pureXML в сравнении с традиционным XML-хранением

Традиционное XML-хранение требует записи XML-документов полностью в CLOB-столбец, или "расщепления" XML-документа на несколько реляционных таблиц. Когда XML сохраняется как CLOB, XML-документ извлекается как один объект. Следовательно, нельзя составить запрос на основе данных, содержащихся в XML-документе. pureXML™ предоставляет возможность запроса по всем элементам в XML-документе. Также он предоставляет возможности индексации и поиска по этим элементам. С другой стороны, расщепление XML-документов на несколько таблиц является затратным по времени и трудным. Преимущество pureXML заключается в том, что данные хранятся в одном столбце таблицы, но возможность индексации и поиска по индивидуальным XML-элементам сохраняется, как и в подходе с расщеплением. Иными словами именно легкие хранение и доступ отличают pureXML от XML-расщепления.

4.2. pureXML в сравнении с SQL-форматом

При использовании pureXML XML-документ сохраняется в одном столбце DB2. Следовательно, DDL (data definition language) для таблицы остается постоянным, независимо от формата XML-элементов. В общей среде с множественной принадлежностью это устраняет необходимость изменения DDL после определения таблицы (предполагается, что все специфичные для владельца данные хранятся в XML-столбце) и предоставляет владельцу возможность настраивать свои данные, не влияя на остальных владельцев. Естественно, независимо от того, храните вы данные в традиционных SQL-столбцах или XML, все изменения базы данных должны рассматриваться совместно с изменениями на уровне приложения, чтобы гарантировать способность кода приложения и кода визуализации приспособиться к изменениям базы данных.

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

Рисунок 9. Хранение данных в изолированной среде
Рисунок 9. Хранение данных в изолированной среде

При помощи DB2 9 была создана одна таблица в среде с общей схемой, которая имеет два столбца: tenantid и customerprofile. Столбец customerprofile был определен как XML. XSD для этого столбца мог бы отличаться по строке – DB2 позволяет использовать несколько XSD с одним и тем же XML-столбцом.

На рисунке 10 вы можете увидеть, что XML-документы банка Bank1 содержат элемент cell phone, в отличие от банка Bank2. Схема для этой таблицы та же, что позволяет обоим владельцам сохранять данные в одну и ту же таблицу. В этом сценарии использовался один XSD (рисунок 11), хотя это и не обязательно.

Рисунок 10. Использование хранилища pureXML-данных
Рисунок 10. Использование хранилища pureXML-данных
Рисунок 11. Пользовательский профиль XSD
Рисунок 11. Пользовательский профиль XSD

Как уже упоминалось, расширения базы данных необходимо рассматривать вместе с изменениями кода приложения и визуализации. В данном сценарии конфигурируемость данных владельца упрощается, благодаря использованию XML-столбца для хранения данных всех владельцев. Кроме того, изменения кода приложения потребовали реализации специфичных для владельцев портлетов, которые можно было бы упростить путем использования одного и того же XSD для двух владельцев с необязательными XML-элементами. Это позволило использовать одни и те же Web-сервисы для обоих владельцев.

Заключение

В данной статье рассматривались методики решения технических проблем на уровне данных, связанных с множественной принадлежностью, использующие возможности DB2 9. Рекомендовалось применять LBAC, чтобы гарантировать безопасность данных. LBAC использует СУБД для реализации системы защиты базы данных, снижающей угрозу SQL-внедрения.

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

И, наконец, что касается расширяемости, то, используя pureXML, вы можете изолировать специфичные для владельца данные в одном XML-столбце в каждой таблице, обеспечивая гибкость для проведения изменений этих данных без влияния на данные остальных владельцев и привлечения DBA для выполнения изменений в DDL.

Ресурсы

Научиться

Получить продукты и технологии

  • Загрузите оценочные версии продуктов IBM и освойте инструментальные средства разработки приложений и продукты промежуточного уровня DB2, Lotus®, Rational®, Tivoli® и WebSphere®. (EN)

Обсудить

Другие файлы для загрузки

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, SOA и web-сервисы
ArticleID=481843
ArticleTitle=Интеграция данных и композитные бизнес-сервисы: Часть 3. Создание уровня данных множественной принадлежности с контролем доступа и системой защиты
publish-date=04122010