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

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

Пока я видел три варианта:

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

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

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

PS Под мульти я подразумеваю что-то вроде ультра-мульти (10.000+ арендаторов).

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

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

Есть интересная статья MSDN под названием « Многопользовательская архитектура данных» , которую вы, возможно, захотите проверить. Вот как авторы рассмотрели заблуждение относительно общего подхода:

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ: дальнейшая информация об ожидаемом количестве арендаторов.

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

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

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

• Надежные подключения к базе данных
• Фильтр просмотра арендатора
• Шифрование данных клиента

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

ОБНОВЛЕНИЕ 2: По-видимому, ребята из Microsoft переместили / сделали новую статью по этой теме, исходная ссылка исчезла, и это новая: шаблоны аренды многопользовательской базы данных SaaS (слава Шай Керер)

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

Причины почему включают:

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

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

РЕДАКТИРОВАТЬ: с
тех пор, как я опубликовал этот ответ, теперь ясно, что мы говорим о 10 000+ арендаторах. Мой опыт работы с сотнями крупномасштабных баз данных - я не думаю, что 10 000 отдельных баз данных будут слишком управляемыми для вашего сценария, поэтому сейчас я не поддерживаю подход с несколькими базами данных для вашего сценария. Тем более, что теперь ясно, что вы говорите о небольших объемах данных для каждого арендатора!

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

Ниже приведена ссылка на технический документ на Salesforce.com о том, как они реализуют мультитенантность:

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

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

Зачем хлопот?

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

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

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

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