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

Question

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

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

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

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

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

P.S. Под multi я имею в виду что-то вроде ultra-multi (более 10.000 арендаторов).

Answer 1

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

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

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

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

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

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

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

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

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

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

---

ОБНОВЛЕНИЕ: Подробнее об ожидаемом количестве арендаторов.

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

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

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

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

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

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

Answer 2

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

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

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

Почему хлопоты?

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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