Мультитенантным или не Мультитенантным

Question

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

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

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

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

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

• Артикул глобального продукта
• Упрощенная инвентаризация
• проще для резервного копирования
• Развернуть один раз вместо каждой ветви

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

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

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

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

---

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

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

Если вы ответите утвердительно на первые два, то, вероятно, вам нужен мультитенант.

Answer 4

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

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

Итак, вСводка:

1. ApplicationData для каждого продукта и имеет одинаковую схему для каждого продукта.
2. MasterData для каждого клиента для продукта.
3. Есть один илибольше экземпляров ClientData для клиента в продукте.

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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