Архитектура программного обеспечения и проектирование баз данных: одна база данных / веб-приложение для каждой компании или одна база данных / веб-приложение для всех компаний?

Я с нуля разрабатываю веб-приложение для базы данных SQL. Приложение будет управлять информацией для клиентов, работающих в той же отрасли. Другими словами, информация (сущности и отношения между ними) относительно каждого клиента не слишком сильно меняется от одного к другому. Однако объем информации продиктован размером компании. Приложение может быть размещено на нашем сервере (ах) или в любом другом месте по выбору клиента.

Мой первый вопрос: каковы плюсы и минусы следующих вариантов:

  • A. Управляйте информацией о нескольких клиентах в одной базе данных;
  • B. Управлять информацией об одном клиенте в каждой базе данных; так что у каждого клиента будет своя база данных;

Мой второй вопрос: каковы плюсы и минусы следующих методов развертывания?

  • A. Каждый клиент получает свой собственный сервер (узел);
  • Б. Используйте большие диски RAID с одним мощным сервером с несколькими веб-сайтами;

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

Используемые технологии:

  • База данных: MS SQL
  • Платформа: ASP.NET
  • Язык: C#

Любые комментарии или предложения приветствуются,

Спасибо,

Каллен

Ответов (6)

Решение

Я бы не рекомендовал давать каждому клиенту свою базу данных. Я планировал сделать это для моего текущего приложения, и меня пригласили в единую базу данных. Хорошо, ведь сейчас у нас 300 клиентов. Можете ли вы представить себе управление 300 базами данных? Обновлять каждый раз при обновлении? Убедитесь, что каждый из них обновлен, и т. Д.

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

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

Вы действительно хотите просмотреть следующее:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

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

* обновлено новой ссылкой

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

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

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

Если вас беспокоят затраты на оборудование, вы можете изучить такие услуги облачного хостинга, как Amazon s2 , Google App Engine и Microsoft Azure .

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

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

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

У меня есть опыт ведения однопользовательского проекта с 40 клиентами. У каждого клиента есть отдельные файлы приложения ASP.NET и база данных SQL Server. Двоичные файлы ядра приложения одинаковы для каждого клиента, но у клиентов тоже есть настраиваемые модули.

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

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

Плюсы

  • Подходит для программного обеспечения для бизнеса. Легко настроить, но вы все равно получаете выгоду от повторного использования
  • Мы можем использовать экземпляры SQL Express на сервер, если каждая база данных не превышает 4 ГБ.
  • Много разделения между клиентами. Например, у каждого клиента может быть отдельный пул приложений IIS.
  • Безопасность на более системном уровне, а не полностью на уровне приложений
  • Версия ПО для одного клиента может быть заморожена на длительное время
  • Ошибки обычно обнаруживаются не на каждом клиенте.
  • Новые функции могут быть расширены в зависимости от реального клиентского спроса. Первые клиенты функции - это в основном бета-тестеры.

Минусы

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

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

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

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

Будут ли когда-либо настраиваться приложения, и если да, может ли отдельная база данных вызывать проблемы?