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

Question

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

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

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

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

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

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

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

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

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

Спасибо

Cullen

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

1010 * Pros *

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

против

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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