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

Ответ 1

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

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

Существует интересная статья MSDN под названием Multi-Tenant Data Architecture, которую вы можете проверить. Так авторы обратились к заблуждению относительно общего подхода:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

Причины включают:

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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