Вопросы Теги

Лучший мультисенентный подход для MongoDB [дубликат]

Если вы не инициализировали ссылочный тип и хотите установить или прочитать одно из его свойств, он будет генерировать исключение NullReferenceException.

Пример: 

Person p = null;
p.Name = "Harry"; // NullReferenceException occurs here.

Вы можно просто избежать этого, проверив, является ли переменная не нулевой: 

Person p = null;
if (p!=null)
{
    p.Name = "Harry"; // Not going to run to this point
}

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

Итак, если вы имеете дело со типами значений, NullReferenceExceptions не может произойти. Хотя вам нужно поддерживать оповещение при работе со ссылочными типами!

Только ссылочные типы, как следует из названия, могут содержать ссылки или буквально буквально ничто (или «нуль»). Если типы значений всегда содержат значение.

Типы ссылок (эти должны быть проверены):

  • динамический
  • объект
  • string

Типы значений (вы можете просто игнорировать эти):

  • Числовые типы
  • Интегральные типы
  • Типы с плавающей запятой
  • decimal
  • bool
  • Пользовательские структуры

66
задан Braintapper 1 May 2010 в 04:55
поделиться

6 ответов

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

Во время моего исследования я нашел эту статью на сайте поддержки mongodb : http://support.mongohq.com/use-cases/multi-tenant.html

Ребята заявили, что избегают 2-х опций любой ценой, которые, как я понимаю, не особенно специфичный для монгоба. У меня сложилось впечатление, что это применимо для большинства исследований NoSQL, которые я исследовал (CoachDB, Cassandra, CouchBase Server и т. Д.) Из-за специфики дизайна базы данных.

Коллекции (или ведра или, тем не менее, они называют это в разных БД) - это не то же самое, что и схемы безопасности в РСУБД, несмотря на то, что они ведут себя как контейнер для документов, которые они бесполезны для применения хорошего разделения арендаторов. Я не мог найти базу данных NoSQL, которая может применять ограничения безопасности на основе коллекций.

Конечно, вы можете использовать защиту на основе ролей mongodb для ограничения доступа на уровне базы данных / сервера. ( http://docs.mongodb.org/manual/core/authorization/ )

Я бы порекомендовал 1-й вариант, когда:

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

Я бы пошел на вариант 3, если:

  • Вы собираетесь сделать это даже в этом сценарии, но это будет огромным. имеют небольшой список арендаторов (несколько сотен).
  • Специфика бизнеса требует, чтобы вы могли поддерживать большие различия в структуре базы данных для разных арендаторов (например, интеграция с сторонними системами, импорт-экспорт данных.
  • Ваш дизайн приложения позволит клиентам (арендаторам) внести существенные изменения в среду выполнения приложений (добавление модулей, настройка полей и т. д.).
  • Если у вас достаточно ресурсы для быстрого развертывания с новыми аппаратными узлами.
  • Если вам необходимо хранить версии / резервные копии данных для каждого арендатора.
  • Существуют законодательные / нормативные ограничения, которые заставляют вас держать разных арендаторов в разных базах данных (даже в центрах обработки данных).
  • Если вы хотите полностью использовать (g16) Существуют большие различия в размерах между арендаторами (у вас много мелких арендаторов и несколько очень крупных арендаторов).
  • / g26]

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

42
ответ дан typeoneerror 25 August 2018 в 01:34
поделиться

В MSDN имеется разумная статья о архитектуре данных с несколькими арендаторами , о которой вы могли бы обратиться. Некоторые ключевые темы, затронутые в этой статье:

  • Экономические соображения
  • Безопасность
  • Вопросы арендатора
  • Нормативные (юридические)
  • Умение задано

Также затронуты некоторые шаблоны конфигурации программного обеспечения как службы (SaaS).

Кроме того, стоит использовать gander интересная запись из парней SQL Anywhere .

Мой собственный личный подход - если вы не уверены в принудительной безопасности / доверии, я бы пошел с вариантом 3, или если проблема масштабируемости запретить возврат к варианту 2 как минимум. Тем не менее ... Я не профессионал с MongoDB. Я очень нервничаю, используя общую «схему», но я с радостью отнесусь к более опытным практикующим.

2
ответ дан AJ. 25 August 2018 в 01:34
поделиться
  • 1
    Я знаком с этой статьей MSDN, так как моим первоначальным планом было использование реляционной базы данных. Тем не менее, мои данные неструктурированы, и теперь я изучаю NSQL dbs как MongoDB. Не похоже, что MongoDB поддерживает ACL так, как это делает Lotus Domino, и я действительно не хочу изобретать колесо, что заставляет меня думать, что 2 или 3 - это путь. Я также не знаю, есть ли ограничения, которые я могу встретить в отношении # коллекций или dbs, разрешенных в MongoDB. – Braintapper 1 May 2010 в 05:11

Я нашел хороший ответ в комментариях по этой ссылке:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb -deployment /

В принципе вариант # 2, кажется, лучший способ пойти.

Цитата из комментария Дэвида Миттона:

Мы решили не иметь базу данных для каждого клиента из-за того, как MongoDB выделяет свои файлы данных. Каждая база данных использует собственный набор файлов:

Первый файл для базы данных - dbname.0, затем dbname.1 и т. Д. Dbname.0 будет 64MB, dbname.1 128MB и т. Д. ., до 2 ГБ. Когда файлы достигают 2 ГБ, каждый последующий файл также имеет 2 ГБ.

Таким образом, если последний файл данных присутствует, например, 1 ГБ, этот файл может быть на 90% пустым, если он был недавно достигнут.

из руководства.

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

Облицовка будет стандартной для сбора, что представляет проблему где коллекция никогда не достигает минимального размера, чтобы начать ошпаривание, как это имеет место для многих наших (например, коллекции просто хранят данные для входа пользователя). Однако мы просили, чтобы это также можно было выполнить на уровне каждой базы данных. См. http://jira.mongodb.org/browse/SHARDING-41

Нет компромиссов с производительностью, использующих множество коллекций. См. http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

8
ответ дан Braintapper 25 August 2018 в 01:34
поделиться
  • 1
    Как было предложено в других ответах, №2 не является хорошим подходом. Пожалуйста, подумайте об изменении принятого ответа, потому что это может пропустить привести других разработчиков. – clopez 28 May 2014 в 19:24
  • 2
    Изменен принятый ответ, поскольку с 2010 года ситуация существенно изменилась, когда вопрос был задан впервые. – Braintapper 28 May 2014 в 22:38

Согласно моим исследованиям в MongoDB. Trucos y consejos. Aplicaciones multitenant. эта опция не рекомендуется, если вы не знаете, сколько арендаторов вы можете иметь, это могут быть тысячи, и это будет сложно, когда дело доходит до осколков, также представьте, что у вас есть тысячи коллекций в одной базе данных. .. Поэтому в вашем случае рекомендуется использовать вариант 1. Теперь, если у вас будет ограниченное число пользователей, это уже по-другому, и да, вы могли бы использовать второй вариант, как вы думали.

0
ответ дан Osleynin Mambell Ramos 25 August 2018 в 01:34
поделиться

В то время как обсуждение здесь посвящено NoSQL и в первую очередь MongoDB, мы в Citus используют PostgreSQL и создаем базу данных с распределенными / распределенными многоуровневыми данными.

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

Для более неструктурированных данных мы используем столбец JSONB PostgreSQL для хранения таких данных и данных, относящихся к арендатору.

0
ответ дан Sumedh 25 August 2018 в 01:34
поделиться

Я бы выбрал вариант 2.

Однако вы можете установить параметр командной строки mongod.exe --smallfiles. Это означает, что максимальный размер файла составит 0,5 гигабайта, а не 2 гигабайта. Я проверил это с монго 1.42. Таким образом, вариант 3 не является невозможным.

2
ответ дан TTT 25 August 2018 в 01:34
поделиться
Другие вопросы по тегам:

Похожие вопросы: