Здравствуйте, AnonThisTime, Вы писали:

ATT> И как это делают системы "залогинился один из Х00000 пользователей и видит только свои данные"? Одна БД на всех? Отдельная БД на пользователя? Свой вариант...

Multi-Tenant Data Architecture
http://en.wikipedia.org/wiki/Virtual_private_database

Здравствуйте, AnonThisTime, Вы писали:

ATT>никто и не спорит, что один сервант ляжет быстро. Плюс тут, что масштабировать с отдельными базами нагрузку на порядки легче просто добавив хост и перенеся туда 1-N БД. Все! Имея одну БД мы имеем жесткий секс с секционированием/шардингом. Нуууу, кому что...

До секционирования и шардинга еще надо дорости на промышленной БД. Для нее 100 гб — не много, а если хорошо писать запросы, то и больше потянет. Представляешь сколько данных в 100 гб влезит? А при больших объемах как ты их шардить будешь?

ATT>>>БД, занавес с бекапом/восстановлением данных отдельных пользователей
R>>а)нормальные люди не удаляют данные и не имеют таких проблем. Очистку от старых данных делают раз в несколько мес, во время плановых обслуживаний.
ATT>да-да, это вы скажите реальным пользователям, которым фиолетово на твои проблемы с архитектурой. Надо поднять старые данные и прямо сейчас.
не, данные вообще не удаляются, просто их клиент не видит.

R>>б)при необходимости нет никаких проблем с перегоном части пользовательских данных из бакапа просто скриптами
ATT>и привет блокировки и прощай работа других пользователей. были, знаем.
Блокировки они на строки ставятся, могут эскалироваться если у тебя совсем плохие запросы. Правишь запросы и проблем нет. А если есть, то используешь какие-нить хитрые схемы partitioning и все работает.

Проектируется веб-приложение, где будут (1) пользователи (П), каждому П (или группе) будет соответствовать отдельная БД со своими предметными данными. Данные о П хранятся в своем виде в БД, к которой этот П принадлежит. Затем, будет (2) клиентское браузерное приложение на Сирвелате, которое общается с (3) stateless серверами приложений, которые, в свою очередь, общаются с (4) БД (которых будет много). Т.е. классическая 3х звенка.
При логине П нужно четко определить, к какой БД он (П) относится и только к ней (3) должен коннектится. Т.е. нужна такая себе кросс-БД "имя пользователя — БД", куда лезет (3) при каждом запросе от (2), ищет по имени польз. его БД и работает с ней.

Вопрос 1: где почитать про внутренности реализации многопользовательких онлайн систем (желательно 3х и более звенных), где данные каждого пользователя не должны пересекаться? Отдельные БД мне видятся резонными в этом случае, т.к. 1) безопастность (БД будет возможно запаролена + лежать на отдельном шифрованном томе + нет возмозможности, из-за бага, увидеть данные другого пользователя) 2) бекапить/восстанавливать можно без проблем, не влияя на остальных.
Вопрос 2: может кто реализовывал аналог, правильным ли путем иду я с этой "кросс БД"? может получилось сделать удобнее другим вариантом? Указанный вариант пока драфтовый, но чего-то он мне не сильно нравится, т.к. имена разных П могут пересекаться, а запрет создавать пользователей, имя которого уже застолбил другой П приведет к ненужным вопросам от П, т.е. такая архитектура влияет на поведение системы, что не есть гуд.

зы: вообще, очень интересно, как сделаны системы с множеством пользователей типа Бейзкампа и т.п. в этом плане. Если есть линки "на почитать", поделись плиз.

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

Здравствуйте, AnonThisTime, Вы писали:

ATT>Проектируется веб-приложение, где будут (1) пользователи (П), каждому П (или группе) будет соответствовать отдельная БД со своими предметными данными. Данные о П хранятся в своем виде в БД, к которой этот П принадлежит. Затем, будет (2) клиентское браузерное приложение на Сирвелате, которое общается с (3) stateless серверами приложений, которые, в свою очередь, общаются с (4) БД (которых будет много). Т.е. классическая 3х звенка.
ATT>При логине П нужно четко определить, к какой БД он (П) относится и только к ней (3) должен коннектится. Т.е. нужна такая себе кросс-БД "имя пользователя — БД", куда лезет (3) при каждом запросе от (2), ищет по имени польз. его БД и работает с ней.

Эт всё средствами нормальной СУБД реализуется.
В MSSQL например есть user, есть login и есть role; их можно в хитрых комбинациях связать между собой и ювелирно раздать права на доступ к конкретным базам данных и конкретным таблицам.
Сервер приложений пусть пользователя аутентифицирует (со stateless-сервера приложений не снимается обязанность аутентификации), а СУБД — авторизует.

Здравствуйте, vimba, Вы писали:

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

тут проблема не в маршрутизации. Чтобы маршрутизировать, нужно знать куда, т.е. нужно привязать пользователя к определенной БД, к которой уже будет стучаться апп.сервер. Вот в этом то и был вопрос.

Здравствуйте, baranovda, Вы писали:

B>Здравствуйте, AnonThisTime, Вы писали:

ATT>>Проектируется веб-приложение, где будут (1) пользователи (П), каждому П (или группе) будет соответствовать отдельная БД со своими предметными данными. Данные о П хранятся в своем виде в БД, к которой этот П принадлежит. Затем, будет (2) клиентское браузерное приложение на Сирвелате, которое общается с (3) stateless серверами приложений, которые, в свою очередь, общаются с (4) БД (которых будет много). Т.е. классическая 3х звенка.
ATT>>При логине П нужно четко определить, к какой БД он (П) относится и только к ней (3) должен коннектится. Т.е. нужна такая себе кросс-БД "имя пользователя — БД", куда лезет (3) при каждом запросе от (2), ищет по имени польз. его БД и работает с ней.

B>Эт всё средствами нормальной СУБД реализуется.
B>В MSSQL например есть user, есть login и есть role; их можно в хитрых комбинациях связать между собой и ювелирно раздать права на доступ к конкретным базам данных и конкретным таблицам.
B>Сервер приложений пусть пользователя аутентифицирует (со stateless-сервера приложений не снимается обязанность аутентификации), а СУБД — авторизует.

естественно апп.сервер аутентифицирует юзверя, стейтлес не причем. Доп. привязка виртуального пользователя к реальному в БД тоже планируется, как последняя инстанция в защите. Вопрос был в том, как привязать пользователя к его БД. И как это делают системы "залогинился один из Х00000 пользователей и видит только свои данные"? Одна БД на всех? Отдельная БД на пользователя? Свой вариант...

Здравствуйте, AnonThisTime, Вы писали:

ATT>И как это делают системы "залогинился один из Х00000 пользователей и видит только свои данные"? Одна БД на всех? Отдельная БД на пользователя? Свой вариант...

Во первых:если у тебя пользователи под разными логинами ходят в базу, то тебе надо создавать эти логины, удалять их, обеспечивать смену паролей итп. Для этого нужны права в БД, которые еще могут и не дать. Но самое плохое, что появляется куча мест где надо управлять учетными данными, это сделает твое приложение по сути более подверженным ошибкам, чем если ты не будешь этого делать.

Во вторых: если ты создаешь базы данных под каждого пользователя, то на это тоже нужны права, которые могут и не дать. Кроме того админы, которым надо будет заниматься резервным копированием твоих БД, будут тебя ненавидеть. Оно тебе надо?

В третьих: если ты даже будешь иметь одну базу, но делать аутентификацию пользователей на уровне БД, а наружу выставлять только view, которые внутри себя будут накладывать предикаты с фильтром по текущему пользователю, а изменения делать с помощью instead of триггеров а этих view, то все равно то что написано в "во первых" остается актуально. Хотя вариант с одной базой и view актуален для корпоративных сред, но не для трехзвенки.

В итоге самый адекватный вариант — хранение все в одной базе и фильтрация на уровне сервера.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, AnonThisTime, Вы писали:

ATT>>И как это делают системы "залогинился один из Х00000 пользователей и видит только свои данные"? Одна БД на всех? Отдельная БД на пользователя? Свой вариант...

G>Во первых:если у тебя пользователи под разными логинами ходят в базу, то тебе надо создавать эти логины, удалять их, обеспечивать смену паролей итп. Для этого нужны права в БД, которые еще могут и не дать. Но самое плохое, что появляется куча мест где надо управлять учетными данными, это сделает твое приложение по сути более подверженным ошибкам, чем если ты не будешь этого делать.

G>Во вторых: если ты создаешь базы данных под каждого пользователя, то на это тоже нужны права, которые могут и не дать. Кроме того админы, которым надо будет заниматься резервным копированием твоих БД, будут тебя ненавидеть. Оно тебе надо?

G>В третьих: если ты даже будешь иметь одну базу, но делать аутентификацию пользователей на уровне БД, а наружу выставлять только view, которые внутри себя будут накладывать предикаты с фильтром по текущему пользователю, а изменения делать с помощью instead of триггеров а этих view, то все равно то что написано в "во первых" остается актуально. Хотя вариант с одной базой и view актуален для корпоративных сред, но не для трехзвенки.

G>В итоге самый адекватный вариант — хранение все в одной базе и фильтрация на уровне сервера.

Нет, не туда. Все 3 пункта относятся к класической системе с множеством пользователей, которую обслуживают локальные админы клиента и т.п. и т.д. У меня же немного другое:
(1) вся логика секьюрити моя и ее данные (подзователи, права и т.п.) лежат в этой БД, БД-шную планирую прикрутить параллельно, но это не приоритетно. Т.е. во всех БД пользователь один, под которым ходят туда апп.серверы.
(2) права на создание БД будут и бекапы на совести самой системы, админы тут не при делах. Их дело, максимум, обеспечить хранилище бекапов.
(3) вот этого как раз и очень не хочется. При росте нагрузки (кол-во пользователей и их данных), приобритаемые проблемы (тормоза работы с данными у пользователей с 20 "заказами" из-за миллионов заказов другого пользователя => необходимость масштабирования/партиционирования/т.п. БД, занавес с бекапом/восстановлением данных отдельных пользователей) перекрывают все мыслимые преимущества. Лучше бороться с небольшими проблемами в отдельной БД) чем со снежным комом в одной.

Тут нужно смотреть с другой стороны: допустим это будет невыездной SaaS, никаких прав/озлобленных админов не будет, у БД будет один пользователь sa, вся секьюрность реализуется самостоятельно. Будет N-пользователей, с отдельной БД со своими данными, при логине которых нужно работать только со своей БД. При чем несколько пользователей могут шарить одну БД, как сотрудники одной компании. Пока вижу только вариант, описанный мной. Есть еще варианты?

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, AnonThisTime, Вы писали:

ATT>> И как это делают системы "залогинился один из Х00000 пользователей и видит только свои данные"? Одна БД на всех? Отдельная БД на пользователя? Свой вариант...

W>Multi-Tenant Data Architecture
W>http://en.wikipedia.org/wiki/Virtual_private_database

Спасибо!!! Вот это видимо то, что я ищу.

Здравствуйте, AnonThisTime, Вы писали:

ATT>Тут нужно смотреть с другой стороны: допустим это будет невыездной SaaS, никаких прав/озлобленных админов не будет, у БД будет один пользователь sa, вся секьюрность реализуется самостоятельно. Будет N-пользователей, с отдельной БД со своими данными, при логине которых нужно работать только со своей БД. При чем несколько пользователей могут шарить одну БД, как сотрудники одной компании. Пока вижу только вариант, описанный мной. Есть еще варианты?

Так ты для начала определись у тебя cloud решение или нет? В облаке можно наращивать количество БД без геморроя, а в on premise варианте — нет. Потом определись какие характеристики нужны. Потому уже думай какое решение.

Если у тебя on-premise решение, то с одной базой будет проще и дешевле, а производительность будет не хуже.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, AnonThisTime, Вы писали:

ATT>>Тут нужно смотреть с другой стороны: допустим это будет невыездной SaaS, никаких прав/озлобленных админов не будет, у БД будет один пользователь sa, вся секьюрность реализуется самостоятельно. Будет N-пользователей, с отдельной БД со своими данными, при логине которых нужно работать только со своей БД. При чем несколько пользователей могут шарить одну БД, как сотрудники одной компании. Пока вижу только вариант, описанный мной. Есть еще варианты?

G>Так ты для начала определись у тебя cloud решение или нет? В облаке можно наращивать количество БД без геморроя, а в on premise варианте — нет. Потом определись какие характеристики нужны. Потому уже думай какое решение.

не клауд, но причем это тут? Наращивать кол-во БД можно и в не-облаке.
По-поводу "определись" — в первом посте было "... веб-приложение с множеством пользователей с отдельными БД...типа Basecamp", что говорит само за себя, что это не единичная инсталляция на стороне клиента.
Характеристики и драфтовое решение описаны опять таки в первом посте.

G>Если у тебя on-premise решение, то с одной базой будет проще и дешевле, а производительность будет не хуже.

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

Здравствуйте, AnonThisTime, Вы писали:

ATT>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, AnonThisTime, Вы писали:

ATT>>>Тут нужно смотреть с другой стороны: допустим это будет невыездной SaaS, никаких прав/озлобленных админов не будет, у БД будет один пользователь sa, вся секьюрность реализуется самостоятельно. Будет N-пользователей, с отдельной БД со своими данными, при логине которых нужно работать только со своей БД. При чем несколько пользователей могут шарить одну БД, как сотрудники одной компании. Пока вижу только вариант, описанный мной. Есть еще варианты?

G>>Так ты для начала определись у тебя cloud решение или нет? В облаке можно наращивать количество БД без геморроя, а в on premise варианте — нет. Потом определись какие характеристики нужны. Потому уже думай какое решение.

ATT>не клауд, но причем это тут? Наращивать кол-во БД можно и в не-облаке.

Потому что не в облаке надо эти БД бекапить как минимум. В облаке уже готовая инфраструктура по наращиванию БД, а on-premise надо её создавать.

ATT>По-поводу "определись" — в первом посте было "... веб-приложение с множеством пользователей с отдельными БД...типа Basecamp", что говорит само за себя, что это не единичная инсталляция на стороне клиента.
ATT>Характеристики и драфтовое решение описаны опять таки в первом посте.
Тогда более чем подходит одна база на все.


G>>Если у тебя on-premise решение, то с одной базой будет проще и дешевле, а производительность будет не хуже.

ATT>на стороне клиента этой проблемы вообще не будет, т.к. там будет одна БД для этого клиента и все. Речь шла о реализации разделения данных в веб-приложении, где люди могут регистрироваться и работать со своими данными. Возмем за пример веб-систему элементарной домашней бухгалтерии, где человек или группа (некая компания) ведет свою бухг. и при это не видит не свои данные.
ATT>wildwind подкинул интересную ссылку по теме, пока курю.

Я тебе вкратце написал что там есть.

ATT>Нет, не туда. Все 3 пункта относятся к класической системе с множеством пользователей, которую обслуживают локальные админы клиента и т.п. и т.д. У меня же немного другое:
ATT>(1) вся логика секьюрити моя и ее данные (подзователи, права и т.п.) лежат в этой БД, БД-шную планирую прикрутить параллельно, но это не приоритетно. Т.е. во всех БД пользователь один, под которым ходят туда апп.серверы.
ATT>(2) права на создание БД будут и бекапы на совести самой системы, админы тут не при делах. Их дело, максимум, обеспечить хранилище бекапов.
ATT>(3) вот этого как раз и очень не хочется. При росте нагрузки (кол-во пользователей и их данных), приобритаемые проблемы (тормоза работы с данными у пользователей с 20 "заказами" из-за миллионов заказов другого пользователя
это ты боишься того чего нет. Как раз на туевой хуче отдельных баз сервер сдохнет под нагрузкой намного раньше, ибо там будет куча транзакшн логов, куча рандомного доступа. Расход оперативки вырастет на порядок а то и больше, верхние уровни B+деревьев обычно не вытесняются из б-пула, статы там вообще живут перманентно, кэши планов разрастутся.
ATT>БД, занавес с бекапом/восстановлением данных отдельных пользователей
а)нормальные люди не удаляют данные и не имеют таких проблем. Очистку от старых данных делают раз в несколько мес, во время плановых обслуживаний.
б)при необходимости нет никаких проблем с перегоном части пользовательских данных из бакапа просто скриптами

вся эта затея — просто космическая глупость. Ты еще в качестве БД мускуль поставь, чтобы уж совсем все напрочь убить

Здравствуйте, rm822, Вы писали:

ATT>>Нет, не туда. Все 3 пункта относятся к класической системе с множеством пользователей, которую обслуживают локальные админы клиента и т.п. и т.д. У меня же немного другое:
ATT>>(1) вся логика секьюрити моя и ее данные (подзователи, права и т.п.) лежат в этой БД, БД-шную планирую прикрутить параллельно, но это не приоритетно. Т.е. во всех БД пользователь один, под которым ходят туда апп.серверы.
ATT>>(2) права на создание БД будут и бекапы на совести самой системы, админы тут не при делах. Их дело, максимум, обеспечить хранилище бекапов.
ATT>>(3) вот этого как раз и очень не хочется. При росте нагрузки (кол-во пользователей и их данных), приобритаемые проблемы (тормоза работы с данными у пользователей с 20 "заказами" из-за миллионов заказов другого пользователя
R>это ты боишься того чего нет. Как раз на туевой хуче отдельных баз сервер сдохнет под нагрузкой намного раньше, ибо там будет куча транзакшн логов, куча рандомного доступа. Расход оперативки вырастет на порядок а то и больше, верхние уровни B+деревьев обычно не вытесняются из б-пула, статы там вообще живут перманентно, кэши планов разрастутся.

никто и не спорит, что один сервант ляжет быстро. Плюс тут, что масштабировать с отдельными базами нагрузку на порядки легче просто добавив хост и перенеся туда 1-N БД. Все! Имея одну БД мы имеем жесткий секс с секционированием/шардингом. Нуууу, кому что...

ATT>>БД, занавес с бекапом/восстановлением данных отдельных пользователей
R>а)нормальные люди не удаляют данные и не имеют таких проблем. Очистку от старых данных делают раз в несколько мес, во время плановых обслуживаний.
да-да, это вы скажите реальным пользователям, которым фиолетово на твои проблемы с архитектурой. Надо поднять старые данные и прямо сейчас.

R>б)при необходимости нет никаких проблем с перегоном части пользовательских данных из бакапа просто скриптами
и привет блокировки и прощай работа других пользователей. были, знаем.

R>вся эта затея — просто космическая глупость. Ты еще в качестве БД мускуль поставь, чтобы уж совсем все напрочь убить
ну кто здесь Дартаньян ясно. Ты по опыту с такими системами говоришь или только закончил "Товароучет" на 20 пользователей?

Вобщем осмотревшись по сторонам видно, что большинство систем такого типа работают с раздельными БД, со своими + и -. Тема закрыта.

ATT>никто и не спорит, что один сервант ляжет быстро. Плюс тут, что масштабировать с отдельными базами нагрузку на порядки легче просто добавив хост и перенеся туда 1-N БД. Все! Имея одну БД мы имеем жесткий секс с секционированием/шардингом. Нуууу, кому что...
Я всегда хотел увидть как кто-то таскает с сервера на сервер терабайтные БД. Я серьезно

ATT>>>БД, занавес с бекапом/восстановлением данных отдельных пользователей
R>>а)нормальные люди не удаляют данные и не имеют таких проблем. Очистку от старых данных делают раз в несколько мес, во время плановых обслуживаний.
ATT>да-да, это вы скажите реальным пользователям, которым фиолетово на твои проблемы с архитектурой. Надо поднять старые данные и прямо сейчас.
ты не понял. Данные не удяляются, история есть всегда и везде, и пользователи сами могут восстановить то что случайно убили. Иногда они конечно хотят чтобы им что-то восстановили, но это от лени

R>>б)при необходимости нет никаких проблем с перегоном части пользовательских данных из бакапа просто скриптами
ATT>и привет блокировки и прощай работа других пользователей. были, знаем.
Вы где-то не там были. Версионники не при вас изобрели?

R>>вся эта затея — просто космическая глупость. Ты еще в качестве БД мускуль поставь, чтобы уж совсем все напрочь убить
ATT>ну кто здесь Дартаньян ясно. Ты по опыту с такими системами говоришь или только закончил "Товароучет" на 20 пользователей?
В пике товароучет наторговал акций на 10млрд $ за выходные

Здравствуйте, AnonThisTime, Вы писали:

ATT>Вобщем осмотревшись по сторонам видно, что большинство систем такого типа работают с раздельными БД, со своими + и -. Тема закрыта.

Я не знаю кто такие "большинство", но, хочу заметить, исторически подобные системы эволюционировали от (1) связки отдельные БД-отдельные приложения на каждый tenant до (2) одно приложение-одна БД обслуживает всех; (3) потом смешанные системы, когда для "крупных" пользователей заранее выделяется свой инстанс приложения-БД, а остальные крутятся в общей; (4) дальше до одно приложение-много БД управляемых приложением. 4-й вариант самый сложный в реализации, там есть разные варианты и ты просто можешь не дойти до того кол-ва пользователей на котором ты сможешь получить выгоду. Это как попытка склепать робота-андроида минуя стадию заводных механических машинок.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, AnonThisTime, Вы писали:
ATT>>Вобщем осмотревшись по сторонам видно, что большинство систем такого типа работают с раздельными БД, со своими + и -. Тема закрыта.

ANS>Я не знаю кто такие "большинство",
тут как такового большинства нет, а уж реальных примеров совсем единицы. Например Спольски и Ко. говорят, что они юзают раздельные БД и все ОК, Basecamp и Ко. юзают одну БД с колонкой ClientId на каждую таблицу. "и Ко." в данном случае какая-то численность других мельче веб систем.

ANS> но, хочу заметить, исторически подобные системы эволюционировали от (1) связки отдельные БД-отдельные приложения на каждый tenant до (2) одно приложение-одна БД обслуживает всех; (3) потом смешанные системы, когда для "крупных" пользователей заранее выделяется свой инстанс приложения-БД, а остальные крутятся в общей; (4) дальше до одно приложение-много БД управляемых приложением. 4-й вариант самый сложный в реализации, там есть разные варианты и ты просто можешь не дойти до того кол-ва пользователей на котором ты сможешь получить выгоду. Это как попытка склепать робота-андроида минуя стадию заводных механических машинок.
ничего я миновать не хочу, хочется спроектировать архитектуру, которую потом наименее геморно будет сопровождать, обслуживать, изменять, масштабировать. Серебряной пули я и не ожидал.
Кстати, какие траблы видятся при реализации/поддержке (4) варианта, когда отдельная БД на тенант? Некоторые пишут аналогичные рассуждения, но видимо без всякого опыта поддержки оного.
* создать БД для нового клиента легко имея глобальныю БД с привязкой клиент-путь к БД.
* изменять структуру даже тысяч таких БД тоже не сложно имея инструмент автоматической накатки патчей каждого релиза на такие БД, т.к. структуру у всех одинаковая (персонализации на клиента именно структуры БД не будет 100%). Ручное обновление БД не рассматривается в принципе естественно.
* на каждый запрос данных открывается новый коннект к БД и закрывается сразу по завершению, т.е. отличия между "одна БД"+тысячи запросов от разных клиентов нет = кол-во коннектов будет одинаково.
* минус тут, как сказали, в большем расходе памяти на лог транз., кеши таблиц/запросов на куждую БД. Это можно побороть легким переносом тяжелых клиентов на другие сервера простым копированием БД и корректировкой пути в главной БД. Да, это удорожит стоимость юзаемого железа, но за счет клиента (типа обычный, силвер, голд-пакет).
* обслуживать (бекап/полное восстановление) не сложнее одной БД при имении автоматизированной тулзы. А имею одинаковую структуру всех БД так и вообще как одна БД. Да, ошибки нужно отслеживать, но опять таки — все должно быть автоматизированно по максимуму.

Плюсы вижу тут:
* легкое масштабирование нагрузки. Перенос тяжелых БД решает проблему.
* то, что одна БД не даст никак: можно опробировать новые релизы на отдельных (или части) клиентов, просто накатив соотв. релизные патчи на некоторые БД, посмотрев на результат и накатив позже на всех.
* то, что одна БД не даст: при проблеме с данными у одного клиента, можно спокойно разбираться с проблемой не парясь, что можно запороть других клиентов.
* то, что одна БД не даст легко: если клиент хочет получать свои данные для подстраховки (а такое есть часто), ему просто высылается его БД.

ANS>В любом случае, кроме первого, самого примитивного варианта все последующие включают в себя возможность существования разных тенантов в одном инстансе БД. Имхо, из этого и нужно исходить.

Скорее всего буду исходить из симбиоза вариантов: буду иметь таки в каждой таблице по полю КлиентИд и вести в одной БД всех мелких или триальных клиентов. А крупных и платников буду выносить в отдельные БД. Так имхо будет наиболее универсально и в будущем меньше гемора.

Мысли?