Как создать многопользовательскую базу данных со структурами общих таблиц?

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

до сих пор я видел три варианта:

  • Multi-Database (каждый арендатор получает свой собственный-почти такой же, как 1 сервер на клиент)
  • Multi-Schema (недоступно в MySQL, каждый арендатор получает свою собственную схему в общей базе данных)
  • общая схема (наш текущий подход, возможно, с дополнительной идентификационной записью в каждом столбце)

Multi-Schema-моя любимая (с учетом затрат). Однако создание новой учетной записи и выполнение миграций кажется довольно болезненным, потому что мне придется перебирать все схемы и изменять их таблицы / столбцы / определения.

Q: Multi-Schema, похоже, предназначена для того, чтобы иметь несколько разные таблицы для каждого арендатора - я не хочу этого. Есть ли какие-либо СУБД, которые позволяют мне использовать решение Multi-schema multi-tenant, где структура таблицы совместно используется всеми арендаторами?

P. S. По мульти я имею в виду что-то вроде ультра-мульти (10.000+ арендаторы).

107
database-design multi-tenant mysql sql

4 ответов

однако есть некоторые компании конечно, кто боится, что их данные могут быть скомпрометированным, поэтому мы оцениваем иное решение.

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

есть интересная статья MSDN под названием Архитектура Данных С Несколькими Арендаторами, которые вы можете проверить. Именно так авторы обращались к заблуждение по отношению к общему подходу:

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

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

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

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

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

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

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

обновление: далее, чтобы обновить ожидаемое количество арендаторов.

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

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

в приведенной выше статье MSDN упоминаются три шаблона безопасности, которые решают вопросы безопасности для подхода к общей базе данных:

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

обновление 2: по-видимому, ребята Microsoft переместили / сделали новую статью по этой теме, исходная ссылка исчезла, и это новая: Multi-tenant SaaS шаблоны аренды базы данных (слава Шаи Кереру)

76

мой опыт (хотя и SQL Server) заключается в том, что мульти-база данных-это путь, где каждый клиент имеет свою собственную базу данных. Поэтому, хотя у меня нет опыта mySQL или Ruby On Rails, я надеюсь, что мой ввод может добавить некоторую ценность.

причины включают в себя :

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

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

EDIT:
Поскольку я опубликовал этот ответ, теперь ясно, что мы говорим о 10,000+ арендаторах. Мой опыт работы с сотнями крупномасштабных баз данных - я не думаю, что 10 000 отдельных баз данных будут слишком управляемыми для вашего сценария, поэтому я не поддерживаю подход с несколькими БД для вашего сценария. Тем более, что теперь ясно, что вы говорите о небольших объемах данных для каждого арендатора!

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

15

Ниже приведена ссылка на Белую книгу Salesforce.com о том, как они реализуют multi-tenancy:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

Они имеют 1 огромную таблицу с 500 строковыми столбцами (Value0, Value1, ... Value500). Даты и числа хранятся в виде строк в формате, позволяющем преобразовать их в собственные типы на уровне базы данных. Существуют таблицы метаданных, определяющие форма модели данных, которая может быть уникальной для каждого арендатора. Есть дополнительные таблицы для индексации, отношения, уникальные значения и т. д.

Почему нервотрепка?

каждый клиент может настроить свою собственную схему данных во время выполнения без внесения изменений на уровне базы данных (alter table etc). Это, безусловно, трудный способ сделать что-то подобное, но очень гибкий.

14

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

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

более масштабируемый подход-это абсолютно случайное распределение арендаторов, хранящихся в одной базе данных, но в разных логических фрагментах (или таблицы). В зависимости от вашего языка существует ряд библиотек, которые могут помочь в этом. Если вы используете Rails, есть библиотека для аренды acts_as_tenant, это помогает гарантировать, что ваши запросы арендатора только оттягивают эти данные. Есть также камень apartment - хотя он использует модель схемы, он помогает с миграциями по всем схемам. Если вы используете Django, есть номер, но один из самых популярных, похоже, находится через - схемы. Все это помогает больше на уровне приложения. Если вы ищете что-то еще на уровне базы данных напрямую, Citusбыл фокусируется на создании этого типа sharding для multi-tenancy работа больше из коробки с Postgres.

7