SaaS: одно веб-приложение к одной базе данных VS.много веб-приложений для многих баз данных

Question

Я планирую разработать довольно маленький SaaS сервис.Каждый бизнес-клиент будет иметь связанную базу данных (та же схема среди баз данных клиентов, разные данные).Кроме того, у них будет уникальный домен, указывающий на веб-приложение, и здесь я вижу следующие 2 варианта:

1. Домены будут указывать на уникальное веб-приложение, которое изменит строку подключения направильная клиентская база в зависимости от домена.(То есть мне нужно будет развернуть только одно веб-приложение.)
2. Домены будут указывать на свое собственное веб-приложение, которое в действительности является одинаковым веб-приложением, реплицированным для каждого клиента, но с соответствующей строкой подключенияклиентская база.(То есть мне нужно будет развернуть множество веб-приложений.)

Это для веб-приложения ASP.NET 4.0 MVC 3.0, которое будет работать на IIS 7.0.Это будет довольно мало, но мне нужно быть масштабируемым.Должен ли я пойти с 1 или 2?

Answer 1

Эта статья MSDN - это большой ресурс, в котором подробно рассматриваются преимущества трех шаблонов:

1. Отделенная БД . Каждый экземпляр приложения имеет свой собственный экземпляр БД. Проще, но может быть сложным в администрировании с точки зрения инфраструктуры базы данных.
2. Разделенная схема . Каждый экземпляр приложения совместно использует базу данных, но разделен с помощью схем. Требует немного больше работы по написанию кода и смягчает некоторые проблемы совершенно отдельной схемы, но все еще имеет трудности, если вам нужно резервное копирование / восстановление отдельного сайта и тому подобное.
3. Общая схема . Ваше приложение отвечает за разбиение данных на основе экземпляра приложения. Это требует большей работы, но является наиболее гибким с точки зрения управления данными.

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

Answer 2

Я не уверен, что это ответ, который вы ищете, но есть третий вариант:

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

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

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