Мульти-аренда с SQL / WCF / Silverlight

Question

Мы создаем приложение Silverlight, которое будет предлагаться как SaaS. Конечным продуктом является клиент Silverlight, который подключается к службе WCF. Поскольку число клиентов потенциально велико, обновление должно быть простым, желательно, чтобы все экземпляры могли обновляться за один раз.

Не реализовав мультитенантность раньше, я ищу мнения о том, как достичь

• Простые обновления
• Безопасность данных
• Масштабируемость

Три различных модели для рассмотрения перечислены в msdn

1. Отдельные базы данных. Это нелегко поддерживать, поскольку все изменения схемы необходимо будет применять к базе данных каждого клиента в отдельности. Есть ли другие недостатки? Профи это разделение данных и безопасность. Это также допускает небольшие модификации для каждого клиента (что может быть более хлопотно, чем стоит!)
2. Общая база данных, отдельные схемы. Столбец TenantID добавляется в каждую таблицу. Гарантировать, что каждый клиент получает правильные данные, потенциально опасно. Прост в обслуживании и хорошо масштабируется (?).
3. Общая база данных, отдельные схемы. Аналогично первой модели, но у каждого клиента есть свой набор таблиц в базе данных. Трудно восстановить резервные копии для одного клиента. Ремонтопригодность аналогична модели 1 (?).

Есть какие-нибудь рекомендации по статьям на эту тему? Кто-нибудь исследовал нечто подобное в приложении Silverlight SaaS? Что мне нужно учитывать на стороне клиента?

Answer 1

У меня похожий случай, но мое решение - использовать оба преимущества.

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

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

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

Спасибо

Answer 2

Как насчет решений, которые предоставляют готовую архитектуру, такую ​​как SaaSGrid от Apprenda? Они позволяют принимать решения о базе данных во время развертывания и обслуживания, а не во время разработки. Похоже, они активно трансформируют и управляют уровнем данных, а также предоставляют механизм обновления.

Answer 3

У нас также есть продукт SaaS, и мы используем решение № 2 (Shared DB / Shared Schema с TenandId). Некоторые вещи, которые следует учитывать для Share DB / Одна и та же схема для всех:

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

2. Разделение данных очень очень важно, вы не хотите, чтобы в конечном итоге показывали часть данных одному арендатору, принадлежащему другому арендатору. в каждом запросе должен быть WHERE TenandId = ..., и вы должны быть в состоянии проверить / применить его в течение разработки.

3. Расширение схемы - это то, что могут дать вам решения 1 и 3, но вы можете обойти это, разработав способ расширения полей, связанных с документами / таблицами в вашем домене, которые имеют смысл ( т.е. метаданные для таблиц, как упоминается в статье MSDN)

Answer 4

Зависит от типа приложения и масштаба данных. У каждого есть недостатки.

1a) Отдельные базы данных + один экземпляр WCF / клиент. Синхронизация всего будет сложной задачей. Как вы одновременно обновляете X серверов БД, что если один из них вышел из строя и теперь не синхронизирован и не совместим с уровнем клиент / WCF?

1b) «Силосы», отдельная БД / WCF / Клиент для каждого клиента. У вас нет проблемы с синхронизацией, но у вас есть накладные расходы на управление множеством разных экземпляров каждого слоя. Также вам придется взглянуть на лицензирование SQL, я не могу вспомнить, лицензируются ли отдельные экземпляры SQL отдельно ($$$). Даже если вы можете установить столько экземпляров, сколько захотите, накладные расходы нескольких экземпляров не будут тривиальными после определенного момента.

3) В основном те же проблемы, что и 1a / b, за исключением лицензирования.

2) Лучший сценарий обновления / управления. Вы правы в том, что поддержание изоляции данных представляет собой серьезную проблему (1a технически разделяет эту проблему на более высоком уровне). Другая проблема заключается в том, что если ваше приложение интенсивно использует данные, вам нужно беспокоиться о масштабируемости данных. Например, если ожидается, что каждый клиент будет иметь десятки / сотни миллионов строк данных. Затем вы начнете сталкиваться с проблемами и производительностью запросов для отдельных клиентов из-за общего объема клиентской базы. Клиенты более терпимы к замедлениям, вызванным их собственным объемом данных. Говорят, что это медленно, потому что данные других 99 клиентов велики, как правило, не нужно.

Если вы точно не знаете, что с самого начала вы будете иметь дело с огромными объемами данных, я бы, вероятно, сейчас остановился на # 2 и начал бы рассматривать кластеризацию или переход к настройке 1a / b, если это потребуется в будущем.

Answer 5

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