Шаблоны многотенантной базы данных SaaS

Применимо к: База данных SQL Azure

В этой статье описаны различные модели аренды, доступные для мультитенантного приложения SaaS.

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

А. Понятия и терминология SaaS

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

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

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

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

B. Как выбрать соответствующую клиентскую модель

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

• Масштабируемость.

  • число клиентов;
  • хранилище на клиент;
  • хранилище в статистической обработке;
  • рабочая нагрузка.

• Изоляция арендаторов: изоляция данных и производительность (ограничивает влияние рабочих нагрузок разных арендаторов друг на друга).

• Стоимость каждого арендатора: затраты на базу данных.

• Сложность разработки:

  • изменения схемы;
  • изменения запросов (требуемые шаблоном).

• Сложность эксплуатации:

  • Мониторинг производительности и управление ею.
  • Управление схемами.
  • восстановление клиента;
  • Аварийное восстановление.

• Возможность настройки: простота персонализации схем на уровне арендатора или класса арендаторов.

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

C. Изолированное однотенантное приложение с однотенантной базой данных

Изоляция на уровне приложения

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

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

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

Управление поставщиками

У поставщика есть доступ ко всем базам данных во всех изолированных экземплярах приложения, даже если эти экземпляры установлены в других подписках клиента. Доступ осуществляется через подключения SQL. С помощью этого перекрестного доступа поставщик может централизовать управление схемой и межбазовые запросы для задач отчетности и аналитики. Если требуется централизованное управление, необходимо развернуть каталог, который сопоставляет идентификаторы клиента с универсальными идентификаторами ресурсов базы данных (URI). База данных SQL Azure предоставляет библиотеку сегментирования, которая используется вместе с ней для создания каталога. Библиотека сегментирования формально называется клиентской библиотекой эластичной базы данных.

D. Мультитенантное приложение с базой данных на клиент

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

Настройка клиента

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

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

Эластичные пулы

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

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

Масштабирование операций для однотенантной базы данных

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

Предположим, что в системе имеется база данных с 1000 клиентов — только одна база данных. У базы данных может быть 20 индексов. Если система преобразуется в 1000 баз данных с одним клиентом, количество индексов увеличивается до 20 000. В Базе данных SQL Azure при автоматической настройке по умолчанию включаются функции автоматического индексирования. С помощью автоматического индексирования выполняется управление всеми 20 000 индексами и их текущими операциями создания и удаления. Эти автоматизированные действия происходят в отдельной базе данных, и они не координируются или ограничиваются аналогичными действиями в других базах данных. Автоматическое индексирование неодинаково обрабатывает индексы в базах данных с разными нагрузками. Такой тип настройки управления индексами был бы крайне неэффективным для масштабирования однотенантной базы данных, если задача по такому управлению должна была бы выполняться вручную.

Ниже приведены другие функции управления, которые поддерживают масштабирование:

• встроенные резервные копии;
• обеспечение высокой доступности; Каждый набор масштабирования помещает свои виртуальные машины в группу доступности с 5 доменами сбоя (FD) и 5 доменами обновления (UD) для обеспечения доступности (дополнительные сведения о доменах сбоя и обновления см.
• шифрование дисков;
• телеметрия производительности.

Автоматизация

Операции управления можно выполнять с помощью скриптов и реализовывать через модель DevOps. Их даже можно автоматизировать и реализовывать в приложении.

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

Е. мультитенантное приложение с мультитенантными базами данных

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

Потеря изоляции клиента

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

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

Низкая стоимость

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

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

F. Мультитенантное приложение с одной мультитенантной базой данных

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

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

G. Мультитенантное приложение с сегментированных мультитенантными базами данных

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

Управление сегментами

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

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

Небольшими базами данных проще управлять

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

Идентификатор клиента в схеме

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

Эластичный пул для сегментов

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

H. Гибридная многотенантная модель базы данных

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

Перемещение клиентов

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

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

Пулы

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

I. Сравнение клиентских моделей

В следующей таблице приведены различия между основными клиентскими моделями.

Связанный контент

• Развертывание и изучение мультитенантного приложения Wingtip, использующего модель SaaS базы данных на клиент — База данных SQL Azure

• Знакомство с SaaS-приложением Wingtip Tickets для размещения клиентов в службе "База данных SQL Azure"