Мультитенантное приложение: Mongodb Sharding Одна база данных для всех арендаторов VS Одна база данных для каждого арендатора - PullRequest
Новая
       40

Мультитенантное приложение: Mongodb Sharding Одна база данных для всех арендаторов VS Одна база данных для каждого арендатора

0 голосов
/ 20 апреля 2020

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

В настоящее время мой подход к хранению данных моих арендаторов заключается в размещении всех их данных в одной базе данных и использовании Mongodb Sharding для разделения всех данных моего арендатора и увеличения масштаба когда мне это нужно в будущем. Чардинг MongoDB кажется мне отличным способом разделения и управления моими данными.

Однако, есть некоторые люди, которые рекомендуют мне иметь одну базу данных для каждого арендатора . Они говорят, что это лучше, так как легче «мигрировать / управлять / масштабировать» и «более безопасно» Я хотел бы получить второе мнение по этому вопросу.

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

Буду признателен за любые идеи. Заранее благодарю за ответ!

1 Ответ

0 голосов
/ 22 апреля 2020

Это мое мнение, и я хотел бы обсудить его.

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

  • Экземпляр системы базы данных на каждого арендатора : Обычно мы используем этот метод для on-premise решений. Арендаторы используют и управляют своим собственным экземпляром базы данных на своем собственном сервере / в облаке.
  • База данных на каждого арендатора : это самый безопасный способ изолировать данные арендаторов друг от друга для облачного решения. Но требует дополнительных усилий для обслуживания и управления (резервное копирование, изменения в разработке, переиндексация и т. Д. c). Кроме того, приложение должно иметь возможность обрабатывать / объединять соединения для каждой базы данных.
  • Схема для каждого арендатора (в мире MongoDb это будет невозможно, поскольку у него нет схемы)
  • Таблица / коллекция на одного арендатора :
  • Строка / документ на одного арендатора : обеспечивает слабую изоляцию. И должны быть хорошо оптимизированы для каждого вида запросов. Тем не менее, самый простой способ обслуживания.

Рассматривая решение, которое поддерживается очень маленькой командой (2 или 3 человека): Я бы использовал document-based isolation (with a field tenantId) и имел бы несколько sharded clusters для масштабирования данных арендатора с использованием инициалов имен арендаторов в качестве ключа шардинга.

  • кластер # 01: арендаторы с именами начинаются с AH
  • кластер # 02: арендаторы с названия начинаются с HS
  • ...

Учитывая облачное решение, которое используется тысячами клиентов по всему миру и поддерживается большой командой : Вероятно, я получит go с sharded clusters (в разных странах) и распределит арендаторов в соответствующий сегментированный кластер по местоположению арендатора и получит database per tenant.

Рассматривая корпоративное решение: Я предпочитаю предлагать on-premise клиентам.

В дополнение ко всему выше : я могу рассмотреть использование slave replica sets для выполнения операций чтения вместо использования основного экземпляра.

...