MultiTenant по сравнению с несколькими DBS
Я разрабатываю пользовательское решение для CRM, которое будет продано с помощью модели Web/SaaS. Я ожидаю десятки или сотни клиентов, использующих это решение. Я буду использовать MS SQL в качестве механизма дб.
Опция 1 состоит в том, чтобы иметь единственный DB и включать столбец TenantId в таблицы, подходящий индекс и использование 'где арендованный = {...}' На каждом доступе дб.
Опция 2 состоит в том, чтобы иметь отдельный DB для каждого клиента, избегая потребности в TenantId и где пункты.
Я ожидаю, что у каждого клиента будут сотни тысяч записей, не миллионы.
Поскольку я вижу его, будет общее количество страниц данных, какой бы ни опция я иду для. Решение кажется в центре на том, лучше ли SQL в управлении несколькими DBS или единственный DB с TenantId и индексом. Первоначально решение будет работать на единственном сервере БД, но в конечном счете переместится в SAN.
У кого-либо есть какие-либо представления об этом?
2 ответа
Есть интересная статья MSDN под названием Многопользовательская архитектура данных , которую вы, возможно, захотите почитать. Авторы делают краткий анализ того, где один подход может быть более уместным, чем другой:
Количество, характер и потребности все арендаторы, которых вы ожидаете обслуживать, влияют ваше решение по архитектуре данных в различные пути. Некоторые из следующих вопросы могут склонить вас к большему изолированный подход, в то время как другие могут склоняет вас к более общему подход.
Сколько у вас потенциальных арендаторов рассчитывать на цель? Вы можете быть нигде почти возможность оценить перспективное использование с авторитетом, но мыслить порядками: вы создаете приложение для сотни арендаторов? Тысячи? Десятки тысяч? Более? Чем больше ты ожидайте, что ваша база арендаторов будет скорее всего, вы захотите рассмотреть более общий подход.
Сколько места для хранения вы ожидаете данные среднего арендатора, чтобы занять? Если вы ожидаете, что некоторые или все арендаторы хранить очень большие объемы данных, подход с отдельной базой данных, вероятно, Лучший. (Действительно, хранилище данных требования могут заставить вас принять в любом случае модель отдельной базы данных. Если так, будет намного проще спроектировать приложение таким образом из начало, чем перейти к подход с отдельной базой данных позже.)
Сколько одновременных конечных пользователей у вас рассчитывать на поддержку со стороны среднестатистического арендатора? Чем больше число, тем больше подходить к более изолированному подходу будет соответствовать требованиям конечного пользователя.
Планируете ли вы предложить на одного арендатора? дополнительные услуги , такие как резервное копирование и восстановление для каждого арендатора возможность? Такие услуги проще предлагать через более изолированные подход.
Обратите внимание, что «общий подход» - это вариант 1, а «изолированный подход» - это вариант 2 в вашем случае. Когда речь заходит о первых двух пунктах, вы не предвзято относитесь ни к одной из сторон, поэтому я думаю, что буду основывать свое решение на последних двух пунктах.
Если вам не нужно связывать данные между арендаторами, лучше всего использовать несколько баз данных. Легче обслуживать, проще настраивать, и производительность будет намного лучше. При наличии данных от нескольких клиентов в одной таблице блокировки таблиц и поисковые запросы по большим таблицам могут и, скорее всего, замедлят ваше решение.
Единственная причина поделиться одним db, я бы посмотрел, если у вас очень много клиентов и очень мало строк на одного клиента.