Multi-tenant vs multi-user
Any system may have multiple users. In a multi-user system multiple users can use the application (e.g. Exact Synergy).
The term multi-user does not imply anything for the architecture of the system. On the other hand, while a multi-tenant system
is a multi-user system, multi-tenancy tells us something about the architecture of the system: namely that multiple users share
the same application and database instance. Note that it is possible to have a multi-user system, which is not multi-tenant.
Правильно ли я понимаю, что при multi-tenancy у меня может быть несколько баз для каждой группы пользователей, т.е. много многопользовательская (saas), а при single-tenancy у меня только одна база, одна на всех?
Пример: нынешний фб это single-tenant mult.-users, а если бы в каждой корпорации\стране был бы аналогичный фб то это multiply-tenant mult.-user.
Т.е. *tenancy это обобщение многопользователькости.
В принципе верно. Multi-tenancy одна из основных характеристик SaaS.
"Физически" одно приложение на физических/виртуальных серверах, но при этом логически — разные окружения со полностью собственными настройками.
Здравствуйте, DeathKnight, Вы писали:
DK>В принципе верно. Multi-tenancy одна из основных характеристик SaaS. DK>"Физически" одно приложение на физических/виртуальных серверах, но при этом логически — разные окружения со полностью собственными настройками.
А как такое реализовывается? Приложение крутится на виртулке, а как ему отдаётся своё окружение?
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, DeathKnight, Вы писали:
DK>>В принципе верно. Multi-tenancy одна из основных характеристик SaaS. DK>>"Физически" одно приложение на физических/виртуальных серверах, но при этом логически — разные окружения со полностью собственными настройками. K>А как такое реализовывается? Приложение крутится на виртулке, а как ему отдаётся своё окружение?
Например каждой группе пользователей (тенанту) свою базу данных
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
PhD студент из Голландии (видимо покурив хорошо), пишет свой бред на тему архитектуры. Вы бы еще на дваче что-нибудь выкопали. Тоже хороший источник.
S>Правильно ли я понимаю, что при multi-tenancy у меня может быть несколько баз для каждой группы пользователей, т.е. много многопользовательская (saas), а при single-tenancy у меня только одна база, одна на всех? S>Пример: нынешний фб это single-tenant mult.-users, а если бы в каждой корпорации\стране был бы аналогичный фб то это multiply-tenant mult.-user. S>Т.е. *tenancy это обобщение многопользователькости.
Да, это большее общий случай. Multi-tenancy предполагают что в рамках одной системы работают несколько независимых организаций (tenants). Соответственно эти тенанты должны:
1. Видеть только себя и свои данные (изоляция)
2. Иметь возможность устанавливать независимые политики безопасности (роли, группы и тд)
3. Иметь различные точки доступа к системе, например acme.jira.org и foo.jira.org
4. Иметь серьезные гарантии, что данные из одной конторы не утекут в другу
5. Иметь серьезные гарантии, что если один тенант убьет, например перегрузит свою систему, на остальных это не повляет
6. Иметь отдельный биллинг и интеграцию с on-prem системами организации
Все эти требования имеют достаточно много архитектурных последствий, одно из которых может быть использование раздельных БД. Но это как правило не самая сложная часть
G>PhD студент из Голландии (видимо покурив хорошо), пишет свой бред на тему архитектуры. Вы бы еще на дваче что-нибудь выкопали. Тоже хороший источник.
Да, написано крайне странно, поэтому вопрос и задал.
G>Все эти требования имеют достаточно много архитектурных последствий, одно из которых может быть использование раздельных БД. Но это как правило не самая сложная часть
А какая самая сложная?
Я правильно понимаю, что multi-tenancy это B2B решения в массе своей?
Здравствуйте, Sharov, Вы писали:
G>>Все эти требования имеют достаточно много архитектурных последствий, одно из которых может быть использование раздельных БД. Но это как правило не самая сложная часть
S>А какая самая сложная?
Изоляция тенантов как правило требует очень много думать на тему безопасности и управления ресурсами.
S>Я правильно понимаю, что multi-tenancy это B2B решения в массе своей?
Да. Мне сложно представить зачем это может быть нужно в B2C.
Здравствуйте, Gurney, Вы писали:
S>>Я правильно понимаю, что multi-tenancy это B2B решения в массе своей? G>Да. Мне сложно представить зачем это может быть нужно в B2C.
Может быть более сложный случай, с трёхуровневой организацией, ну как джира в облаке. Т.е. есть организации, которые как тенанты получют себе некий изолированный environment. И есть консультант Джон До как конечный пользователь, который может быть приглашён с одной и той же учёткой в один или несколько рабочих тенантов одновременно.
Аналогично для, скажем, плафтормы для всяких жилкомсервисов (где организация может иметь тенант из нескольких домов на обслуживании, и третим уровнем физлицо как владелец нескольких квартир, как из разных домов одного тенанта, так и из разных домов разных тенантов). Или всякие электронные дневники, когда у родителей несколько детей могут учитсья в разных школах (скажем, общеобразовательный лицей для младшего ребёнка, матшкола для среднего и гуманитарный колледж для старшего)
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, DeathKnight, Вы писали:
DK>>В принципе верно. Multi-tenancy одна из основных характеристик SaaS. DK>>"Физически" одно приложение на физических/виртуальных серверах, но при этом логически — разные окружения со полностью собственными настройками. K>А как такое реализовывается? Приложение крутится на виртулке, а как ему отдаётся своё окружение?
Способов много, например, я учавствовал в проекте, где это делалось логически, по сути в каждой сущности было clientId, так как была необходимо иерархии между данными клиентов.
Это технически простой, но ведущий к коллизиям между клиентами способ. Плохо с точки зрения безопасности.
Еще один способ с которым я лично сталкивался — скажем, многоуровневая база:
на верхнем уровне хранилище общих данных типа статики и админских данных, ниже у каждого клиента может быть отдельная схема или база.
Здравствуйте, Gurney, Вы писали:
G>Изоляция тенантов как правило требует очень много думать на тему безопасности и управления ресурсами.
Ты имеешь в виду изоляция без разделения на разные базы? Не так много, достаточно продумать несколько базовых правил.
G>Да. Мне сложно представить зачем это может быть нужно в B2C.
Для шардирования и снижения нагрузки. Онлайн игры к примеру.