Подтвердить что ты не робот

Multi-Tenant, или Not To Multi-tenant

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

Я принял решение на раннем этапе использовать отдельные приложения с отдельными базами данных для каждой ветки, поскольку это был самый простой способ обслуживать три разных ветки с разрозненными данными и требованиями к коду. Я также хотел избежать управления идентификаторами арендаторов в каждом запросе, например, мне пришлось использовать устаревшее приложение ASP.NET(cringe), которое я построил в 2007 году... ужас.

Но теперь требования к данным для веток сходятся, и по мере расширения бизнеса мне нужно иметь возможность быстро развертывать новые ветки и совместно использовать глобальные SKU продуктов.

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

Соображения для централизованной базы данных:

  • Глобальные продукты SKU
  • Упрощенные заявки на инвентаризацию
  • Легче резервное копирование
  • Разверните один раз вместо каждой ветки

Соображения против централизованной базы данных:

  • Легче дифференцировать требования к ветки с отдельными БД
  • Модульное развертывание (одна сбитая ветвь не разбивает все)
  • Сложнее управлять и разрабатывать для общего БД
  • Мне нужно повторно спроектировать нумерацию счетов (последовательность, сгенерированная семенем)
  • Меньше предложений WHERE везде
  • Восстановление одной разбитой ветки имеет большое значение для других ветвей.

Вряд ли когда-либо будет 10 веток. Сейчас 3.

Разработчики, имеющие опыт работы в этой области в реальном мире, что бы вы сделали в моей ситуации? Хранить приложения и базы данных отдельно или объединяться в одну гигантскую систему?

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

Второй вопрос о смешивании данных также не является проблемой. Просто посмотрите на salesforce.com или на любой другой крупномасштабный сайт. Они абсолютно используют архитектуру с несколькими арендаторами и, судя по количеству сдвига клиентов, которые их используют, это не кажется проблемой. Главное, что вы можете обеспечить своим клиентам, чтобы их данные были защищены.

Ответ 2

Если вы говорите о 10 ветких, многопользовательская аренда кажется большой ценой с небольшой пользой.

Есть осложнения с многопользовательской арендой, о которых вы не говорите:

  • Вершина становится сложной. Клиентам X, Y и Z может понадобиться новая функция, а клиенты A, B и C - нет. Приложение с несколькими арендаторами облегчает всем, особенно если новая функция требует изменений схемы базы данных. Это не невозможно, это просто сложнее.
  • Некоторым клиентам очень неудобно смешивать данные в тех же таблицах, что и другие клиенты. Несмотря на то, что мы знаем лучше, это кажется для них угрозой безопасности. Юридические отделы ненавидят его. Кроме того, если вы отправляете необработанные данные для клиента, общая база данных требует осторожности.

Вы можете устранить несколько болей с помощью лучших практик:

  • Автоматизация развертывания. Это должно облегчить добавление нового клиента или обновление/понижение рейтинга существующего клиента. Обслуживание базы данных (резервное копирование, восстановление индексов) также должно быть настроено автоматически.
  • Храните общие данные (SKU, инвентарь) в центральной базе данных и каждый экземпляр приложения обращается к нему напрямую или через службу.

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

Ответ 3

Честно говоря, это деловой вопрос. Вы либо сможете поставлять более настраиваемые функции в меньшую группу пользователей в настройке с несколькими арендаторами, но с большим объемом ИТ-ресурсов. То есть вам понадобится больше людей и аппаратное обеспечение (руководство читает это: деньги), но обеспечивает большую гибкость.

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

Если у вас лично есть сок, чтобы сделать этот звонок, и бизнес просто должен слушать то, что вы говорите, или вы можете подтолкнуть руководство так или иначе, я предлагаю задать СЕВЕРУ ряд вопросов о том, какой сценарий вы предпочитаете:

A) Вы хотите, чтобы у вас было больше людей, которые управляли этим делом и обменивались зарплатой /responsibilty Б) Насколько вам известно, скоро будет 4-я группа пользователей? C) Как долго вы хотите остаться в этой компании?

Если вы ответите "да" на первые два, вам, вероятно, понадобится многопользовательский.

Ответ 4

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

  • ApplicationData, в которой содержится всего несколько таблиц, содержащих информацию о самих клиентах, например, какую базу данных MasterData (см. ниже) использовать при достижении определенного URL-адреса и какие функции доступны для этого клиента. Каждый продукт имеет только одну ApplicationData, независимо от того, сколько разных клиентов использует этот продукт.
  • MasterData, которая содержит информацию о клиенте, такую ​​как пользователи, роли и разрешения (в нашем случае здесь создаются таблицы, созданные aspnet_regsql). Среди указанных здесь разрешений доступны базы данных ClientData для данного пользователя (см. Ниже). Схема для всех баз данных MasterData (для одного и того же продукта) одинакова.
  • ClientData, которая содержит данные, с которыми пользователь взаимодействует. В одном продукте это данные, которые клиент может искать на основе большого количества критериев, создавать отчеты и т.д. В другом продукте это содержит динамические данные, которые клиент может загрузить, чтобы другие пользователи могли связаться с людьми для проведения опросов по телефону и т.д. Схема для всех баз данных ClientData для одного и того же продукта одинакова.

Теперь одно предостережение: мы фактически используем одну и ту же схему и часто одну и ту же фактическую базу данных для MasterData и ClientData. Это связано с историческими причинами, поскольку возможность разрешить клиенту иметь одну базу данных аутентификации (MasterData), соответствующую нескольким базам данных ClientData, является относительно новой функцией, которая применяется только к одному из наших продуктов. Кроме того, эта структура упрощает развертывание, поскольку большинство клиентов используют только одну базу данных ClientData. Однако у MasterData и ClientData есть отдельные модели сущностей в Entity Framework в наших проектах, и мы должны гарантировать, что между MasterData и ClientData нет прямых связей, таких как внешние ключи.

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

Еще одна вещь, которая действительно помогла нам в этой ситуации, - это инструменты Red Gate, а именно такие инструменты, как Multi- Script, SQL Source Control и Schema Compare. Когда мы что-то обновляем и изменяем схему, мы должны развернуть изменения во всех соответствующих базах данных. Эти инструменты более чем оплачиваются для себя в сжатые сроки. Обратите внимание, что у меня нет связи с Red Gate, кроме как у удовлетворенного пользователя.

Изменить: (в ответ на комментарий)

ApplicationData - это одна база данных для каждого продукта. В трех веб-продуктах мы используем одну и ту же схему для ApplicationData, поскольку они записывают в основном одни и те же типы информации. Однако нет причин, по которым это должно было бы остаться таким образом. Базы данных ApplicationData находятся на одном сервере. Одна из таблиц в ApplicationData указывает на правильное имя сервера и базы данных для клиента MasterData, поэтому MasterData для данного клиента может находиться на любом сервере.

У MasterData есть информация о имени сервера и базы данных для каждой базы данных ClientData, поэтому снова базы данных могут находиться на любом сервере. На практике на данный момент у нас есть только два сервера баз данных производства для этих продуктов. Схема MasterData похожа на продукт, но я не думаю, что они точно такие же (я должен был бы проверить). Каждый клиент имеет свою собственную MasterData. Если клиент покупает несколько продуктов, для каждого продукта для этого клиента есть MasterData; продукты взаимодействуют другими способами (в основном, через веб-службы), если клиент купил эту функцию (или запрашивает индивидуальную разработку такой функции. ClientData для данного продукта всегда имеет одну и ту же схему.

Итак, вкратце:

  • ApplicationData для каждого продукта и имеет одну и ту же схему в каждом продукте.
  • MasterData для каждого клиента для продукта.
  • В продукте есть один или несколько экземпляров ClientData для клиента.

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

Я надеюсь, что ответит на ваш вопрос!

Ответ 5

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

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

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

Ответ 6

Если мы говорим о CRM, то каковы шансы одного клиента быть в нескольких базах данных? Если даже малейшая вероятность того, что вас попросят объединить данные о клиентах через ветки, я бы определенно пошел с одной централизованной базой данных.

Ответ 7

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

Чтение того, что вас особенно интересуют несколько ветвей одного и того же приложения, а не действительно разрозненные приложения, похоже, что большой вариант - создать базу данных вокруг процесса посева (это поддерживает Entity Framework), что позволит вам просто развернуть свой новый код ветвления в ASP.NET, а затем во время первоначальной сборки базы данных, что таблицы физически созданы, чтобы вы опросили "благословенный" сервер и выгрузили все необходимые данные на пограничный сервер.

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

Ответ 8

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

Сравните затраты:

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

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