Обзор OpenEdge 11 Multi-Tenancy

Одной из самых важных и полезных возможностей в новом релизе OpenEdge 11 (ожидается в декабре 2011 года) является прямая поддержка Multi-tenancy в базе данных. Что такое Multi-tenancy, и зачем это нужно? Я расскажу вам об этом.

Термин «multi-tenancy» возник в области Software-as-a-Service (далее SaaS). Когда продавец предлагает своё приложение в качестве сервиса, это значит, что клиентам не придется покупать отдельный компьютер для работы с ним, как и не понадобится набирать штат специалистов для обслуживания этого приложения или бэкапов данных. Вместо этого пользователи подписываются на сервис, и его поставщик (вендор) делает все необходимое. Клиенты просто используют сервис в Интернете,  не имея представления о том, где и на каких серверах он работает. Когда вы пользуетесь поисковыми системами, вы ведь не знаете, где они размещаются физически, да это и не важно для вас  – аналогичная ситуация и с SaaS-приложениями.

SaaS-приложение, с которым вы, вероятно, уже знакомы – это электронная почта. Google, Microsoft, Yahoo и прочие провайдеры предоставляют своим абонентам почтовые сервисы. Используя их, вы знаете только о точке входа, кто-то другой отвечает за всё, что касается эксплуатации и технического обслуживания сервиса. Вы же благополучно получаете, читаете, создаете и отправляете свою почту.

Всё это просто, даже тривиально для SaaS-пользователей. Но что насчет несчастного поставщика решений? Поставщик должен делать всю «грязную» работу ИТ. Содержит ли он отдельный сервер для каждого своего клиента так же, как если бы все клиенты запускали приложение на своих личных компьютерах? Нет, конечно же, нет. Поставщик сервиса делает всё возможное, чтобы снизить свои операционные расходы. Это тот случай, когда на помощь приходит Multi-tenancy. Каждый из клиентов SaaS-продавца называется «арендатор» (tenant), это слово заимствовано из сферы аренды жилья. В многоквартирном доме может быть множество жильцов-арендаторов, каждый из которых имеет отдельное пространство для жизни. Точно так же можно разместить несколько приложений-арендаторов на одном компьютере.

С некоторым числом арендаторов, разделяющих один и тот же компьютер, поставщик SaaS должен покупать и обслуживать меньше машин, а значит и выполнять меньший объем работы. При этом ни один из арендаторов не может видеть других арендаторов или их данные, и фактически ничего не знает ни о них, ни об их существовании. В большинстве SaaS-приложений так и происходит, и поскольку для OpenEdge реализация данного сервиса не сложна, то многие из SaaS-продавцов просто создают для каждого из арендаторов отдельную базу данных. Но это означает, что вы должны выполнять резервное копирование, изменение схемы и другие обслуживающие функции индивидуально для каждой базы каждого арендатора. Намного лучше, если бы арендаторы могли также разделять одну базу данных. Такую базу мы и называем Multi-tenancy-базой данных.

В OpenEdge 10 и в более ранних версиях требовались не очень большие доработки, чтобы сделать Multi-tenancy-базу. Многие наши партнеры, засучив рукава, так и сделали. Для этого необходимо было следующее:

• Добавить столбец с уникальным идентификатором (tenant id) в каждую базу данных. Такой «tenant id» будет содержать уникальное значение, возможно, цифровое, присвоенное каждому арендатору. Таким образом, это значение будет указывать на то, какому из арендаторов принадлежат данные в каждой строке таблицы.
• Добавить столбец «tenant id» в каждый индекс в качестве главного компонента ключа.
• Создать таблицу для хранения имен арендаторов и их уникальных идентификаторов, а также присвоить каждому арендатору «tenant id».
• Пройтись по всему коду вашего приложения и везде, где создается новая запись в таблице, присвоить корректное значение полю «tenant id».
• Изобрести способ отслеживания действующего «tenant id» на текущий момент времени.
• Найти в коде приложения все запросы к таблицам и изменить условие поиска данных (WHERE), добавив в него следующее условие «(tenantId = currentTenant) and». Не забыть также об операторе CAN-FIND. Убедиться, что условие поиска по «tenant id» добавлено для каждой таблицы в многотабличных запросах.

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

• Склонность к ошибкам. Если вы допустите ошибку при изменении программного кода при создании Multi-tenancy, запросы будут возвращать неправильные данные. А если вы или другой разработчик при исправлении какой-либо ошибки забудете об Multi-tenancy, программа будет возвращать данные другого арендатора.
• Даже если вы будете использовать для хранения данных области Type II, то строки, принадлежащие множеству арендаторов, будут смешаны в блоках данных и кластерах той же таблицы. Это сводит на нет многие преимущества использования областей хранения второго типа. Вы получите более низкую эффективность дискового ввода/вывода, т.к. каждый арендатор должен будет считывать блоки данных, которые содержат данные других арендаторов. Кроме того, у клиентов может появиться мнение, что подобное «смешивание» станет угрозой их безопасности.
• Вы не сможете легко обслуживать каждого арендатора. Как сделать переиндексацию данных только одного арендатора?
• Как восстановить данные одного арендатора, если он сделает, например, такую глупость, как закрытие месяца в середине месяца?
• Вы не сможете сделать распределение дискового пространства между арендаторами или отследить использование дискового пространства каждым из них легким способом, если вообще сможете.
• Среди арендаторов могут возникать взаимные блокировки (Lock). Блокировка таблицы повлечет за собой блокировку всех арендаторов.

Несмотря на эти недостатки, думаю, что преимущества перекрывают их, и есть смысл задуматься об использовании такого подхода. Но что, если вы смогли бы устранить все недостатки? Хотели бы вы совместить, казалось бы, несовместимое? Это тот случай, когда на помощь приходит OpenEdge 11! Должны ли вы сделать все, что я перечислил? Нет! Возникнут ли недостатки, которые были перечислены? Нет! OpenEdge 11 сделает всю тяжёлую работу за вас.

В OpenEdge 11 RDBMS  база данных Multi-tenancy – это встроенная функция. База данных знает об арендаторах, знает - кто они и где их данные. Она знает, где размещать новые данные и где получить существующие для каждого арендатора. Вам не потребуется изменять код доступа к данным действующего приложения. Фактически вам не потребуется значительных изменений вообще! Большая часть кода будет работать так же, как и прежде.

Хорошо, возможно вам действительно потребуется выполнить несколько изменений. Эти изменения относятся к тому, как пользователь должен регистрироваться в приложении и базе данных, и как будет проверяться идентификация пользователя. Я сказал, что база данных знает об арендаторах, но вы должны будете «сказать» ей, к кому из арендаторов принадлежит пользователь. Чтобы помочь вам в этом, в 4GL мы используем то, что называется CLIENT-PRINCIPAL.

CLIENT-PRINCIPAL (далее CP) – это встроенный, расширяемый маркер безопасности, который был добавлен в OpenEdge несколько лет назад в релизе 10.1. Как только идентификационные данные пользователя проверены, CP их инкапсулирует. В OpenEdge 11 мы используем CP (с некоторыми улучшениями) для инкапсуляции пользовательских идентификационных данных и идентификационных данных арендатора. В зависимости от того, какой CP-маркер действует в текущий момент времени при выполнении 4GL-кода, база данных использует соответствующий «tenant id» для принятия решения о том, какие данные возвращать запросу. Для кода, работающего с AppServer и обращающегося к базе данных от имени различных пользователей в разное время, AppServer может легко переключать CP на соответствующий тому пользователю, который обратился к AppServer`у.

Для подготовки к работе с OpenEdge 11 вы должны больше узнать о CLIENT-PRINCIPAL. Это может показаться сложным и даже пугающим, но на самом деле, это действительно очень просто и удобно. Потребуется всего три строки кода, чтобы создать и проверить пользовательские идентификационные данные. Смотрите видео Сары Маршал (Sarah Marshall) с Exchange Online 2010 на PSDN (прим. переводчика: запись размещена здесь «Winning the Security Game Identity Management from Start to Finish»).

В OpenEdge 11 каждый арендатор получает отдельный раздел данных для каждой multi-tenant-таблицы (но не каждая таблица должна быть multi-tenant). У каждого раздела данных есть собственные ассоциированные индексные разделы. Идентификатор арендатора (tenant id) в CP используется для управления тем, какие разделы данных должны быть предоставлены для выборки строк, чтобы арендатор мог получить доступ только к своим данным (и данным в обычных разделяемых таблицах). Также существует специальный арендатор, называемый «super tenant», который концептуально подобен пользователю root в Unix и позволяет увидеть все данные.

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

Я надеюсь, что вам понравится новый релиз. Это действительно здорово.

Автор: Gus Bjorklund
Перевод: Валерий Башкатов
Центр компетенции PROGRESS
(оригинал статьи)