Я видел несколько сообщений о мультитенантных подходах с Mongo, но надеюсь, что смогу получить более конкретную обратную связь для более специфических требований.
Вот что я знаю со стороны бизнеса:
- «Бесплатная оценка»: должна позволять бесплатную и простую регистрацию нового арендатора (заказчика); многие из них останутся в системе с низкой активностью и громкостью, и надолго.
- Аналитика [на одного клиента] является ключевым компонентом решения. Нет острой необходимости в аналитике в реальном времени, и большая ее часть может быть выполнена в «пакетной» обработке на одного арендатора.
- Может также потребоваться некоторая перекрестная "внутренняя" аналитическая обработка, но на более поздних этапах.
Я предполагаю, что необходимость «легкого» выделения нового арендатора не согласуется с подходом «база данных на арендатора».
Предполагается, что я храню отдельные коллекции для отдельных арендаторов в одной и той же БД:
- Было бы эффективно запланировать так много агрегаций, сокращающих карту, для каждой коллекции арендатора (в отличие от "одного большого" сканирования коллекций с несколькими арендаторами)
- Есть ли практический способ выполнения аналитических вычислений в нескольких коллекциях?
- Существуют ли другие проблемы с большим количеством коллекций, помимо общего количества коллекций и индексов? Например, потеря поддержки некоторых библиотек и инструментов, предназначенных для работы с фиксированным набором коллекций?
В качестве альтернативы при управлении мультитенантными коллекциями с фиксированным набором:
- Каковы "лучшие практики" для структуры коллекций? Должен ли я хранить «документ арендатора» «по ссылке» в каждом документе в мультитенантной коллекции?
- Каковы "лучшие практики" для запуска карты-сокращения в таком случае? Стоит ли попробовать одну огромную карту-уменьшение или запустить несколько задач уменьшения карты, фильтруя коллекции для каждого арендатора?
Спасибо,
Max