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

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

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

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

Безопасность данных

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

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

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

Разрешения. Используйте списки управления доступом (ACL) для определения того, кто имеет право доступа к данным приложения, и что они могут делать с этими данными.

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

Шаблоны обеспечения безопасности данных

Выбирайте шаблон обеспечения безопасности, исходя из используемой многотенантной модели:

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

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

Шифрование данных тенанта (применяется ко всем трем многотенантным моделям). Защитите данные с помощью симметричного шифрования, и секретный ключ тенанта – с помощью ассиметричного шифрования (с применением пары открытый/секретный ключ). Используйте олицетворения для доступа к базе данных с применением

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

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

Хранение и расширяемость данных

Существует множество способов хранения размещаемых данных. Для реализации хранения данных в размещаемых приложениях разрабатывается два разных подхода: системы управления размещенными реляционными базами данных (hosted relational database management systems, RDBMS) и нереляционное хранилище в облаке. Реляционные базы данных обеспечивают хранение структурированных данных и больше подходят для транзакционных систем или приложений с интенсивным вводом/выводом. Также обычно такие базы данных обеспечивают меньшую задержку и расширенные возможности запросов. Под хранилищем в облаке, напротив, подразумевается хранилище для любых типов данных, которое размещается в облаке; сюда также относятся сервисы, обеспечивающие функциональность базы данных, сервисы для неструктурированных данных (например, хранилище файлов для цифровых мультимедиа), сервисы синхронизации данных и устройства хранения данных, подключаемые к сети (network-attached storage, NAS). Сервисы данных часто предоставляются по модели повременной оплаты или, в данном случае, оплате за гигабайт данных (включая и хранящиеся, и переданные данные).

Хранение в облаке предлагает ряд преимуществ, таких как возможность хранения и извлечения больших объемов данных из любой точки земного шара в любое время. Сервисы хранения данных быстры, недороги и практически неограниченно масштабируемы. Могут возникать проблемы с надежностью, но даже самые лучшие сервисы дают сбой время от времени. Также возможны неполадки с приложениями, чувствительными к большой задержке, поскольку каждое взаимодействие с сервисом хранения требует передачи данных по сети. Наконец, для сисем хранения в облаке может быть проблематичной поддержка транзакций. Как правило, эти системы ориентированы на секционирование и доступность и не всегда могут гарантировать согласованность.

Хранилище Microsoft Azure (на момент написания данного документа находящееся на этапе ранней предварительной версии1) включает ряд сервисов, обеспечивающих различные нужды хранилища и доступных через REST API:

1 С 1 февраля 2010 года в промышленной эксплуатации (прим. научного редактора).

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

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

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

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

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

◦Фильтрация на основании расширяемых столбцов представляет проблему в связи с предопределенностью типов данных. Например, использование типов данных переменной длины, таких как varchar, для всех расширяемых столбцов ограничивает возможность фильтрации по числовым значениям с применением операторов <, > и =. Возможным решением является выделение фиксированного количества полей для каждого общего типа данных или предоставление пользователю возможности помечать столбцы как доступные для поиска и использовать отдельную таблицу для хранения полей определенного типа.

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

◦Неправильная интерпретация базой данных значений null может привести к разреженному распределению данных и необоснованному чрезмерному расходованию пространства. Если один из тенантов расширяет только одно поле, тогда как остальные расширяют по 20 полей, база данных и страницы в памяти будут разрастаться. В Microsoft SQL Server 2008 предлагается

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

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

◦Этот подход требует инкапсуляции и абстракции слоя доступа к данным и наличия обработчика запросов, хотя O/RM-инфраструктуры, такие как Microsoft Entity Framework (EF) или инфраструктура с открытым исходным кодом NHibernate, могут упростить реализацию. Больше сведений по данным вопросам можно найти в материалах, приведенных в разделе Дополнительные источники в конце этой главы.

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

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

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

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

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

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