MongoDB Atlas - подход к мультитенантным приложениям и архитектуре данных

Question

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

Веб-приложение, над которым я работаю, является базовым c прототипом раннего состояния, построенным на nodejs, express, react, typescript и использует Mon go Atlas для базы данных при использовании Auth0 для аутентификации. Я хотел бы получить правильную архитектуру данных, прежде чем приступить к созданию приложения, которое будет соответствовать модели продукта SaaS.

Текущее состояние

Я создал приложение, позволяющее регистрация пользователя, аутентификация, обновление профиля пользователя. В настоящее время пользователи могут зарегистрироваться, что создает пользователя в Auth0 и создает запись сведений о пользователе (имя, номер телефона, адрес электронной почты и т. Д. c) в документе Mon go Atlas со следующей структурой:

Mongo Atlas Cluster
  --users (Database)
    --users (Collection)
      --user_record (Document)

Вот пример документа записи пользователя:

_id:ObjectID("5ced24301914b800066d629b")
given_name:"James"
family_name:"Test"
email:"email@gmail.com"
password:"$$6ag2$xVFSPdbhekW9Dx.opGJlluytGb9Ktka5uZshUg4Hw0GmOt4N/wAi."
addressLineOne:"Line 1"
addressLineTwo:"Line 2"
city:"New York"
company:"Company Name"
country:"USA"
postCode:"10001"
telephone:"555 789 987"

Future State - Multi-Tenancy

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

Основными преимуществами будут:

1. Highly Scalable
2. Изолировать данные от других клиентов

Структура кластера Mon go Atlas будет выглядеть, как в этом примере, где есть 3 клиента, каждый со своей собственной выделенной базой данных клиентов:

Mongo Atlas Cluster
  --tenant_tenant1 (Database)
  --tenant_tenant2 (Database)
  --tenant_tenant3 (Database)
  --user_management (Database)
    --user_management (Collection)
      --user_record_1 (Document)
      --user_record_2 (Document)
      --user_record_3 (Document)

Схема документа user_record может быть расширена, чтобы идентифицировать базу данных клиента, когда пользователь входит в приложение, как в этом примере:

_id:ObjectID("5ced24301914b800066d629b")
tenant_db:"tenant_tenant1"
tenant_db_user:"dbuserid"
tenant_db_password:"%26ag2$xVFSPdbhekW9Dx.opGJlluytGb9Ktka5uZshUg4Hw0GmOt4N/wAi"
given_name:"James"
family_name:"Test"
email:"email@gmail.com"
password:"$$6ag2$xVFSPdbhekW9Dx.opGJlluytGb9Ktka5uZshUg4Hw0GmOt4N/wAi."
addressLineOne:"Line 1"
addressLineTwo:"Line 2"
city:"New York"
company:"Company Name"
country:"USA"
postCode:"10001"
telephone:"555 789 987"

Для этого я полагаем, что Mon go Atlas API должен быть использован как стандартная строка подключения Mon go с использованием Mon goose is specific c к отдельной базе данных. API-интерфейс Mon go Atlas позволяет создавать базы данных в дополнение к почти всем функциям Mon go Atlas.

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

Мои основные вопросы:

1. Как вы думаете, это хороший подход при настройке мультитенантности для приложения с использованием Mon go Atlas?
2. Как вы думаете, есть лучший или другой подход?
3. Видите ли вы какие-либо потенциальные подводные камни с этой архитектурой позже?

Спасибо за вашу помощь и с нетерпением жду ваших мыслей по этому поводу это.

Джеймс