В продолжение моих изысканий методов построений SaaS, и опят несколько абстрактно...
Итак, надо сделать SaaS, предоставляющей клиентам что-то вроде специализированной CMS, и мечтательно предполагается, что клиентов будет десятки тысяч. У клиентов будет бд (MySQL, MariaDB или PostgreSQL), в которой хранится и собственно данные, и данные об интерфейсе работы с этими данными (включая дизайнерские особенности). Получается, у каждого клиента далеко не одна таблица, а, скажем, сотня, но при этом структуры и количество таблиц у всех клиентов одинаковые.
Как это сделать?
Можно создать одну бд, с мильеном таблиц, различающихся префиксом. Является ли минусом - бд с охрененным количеством таблиц?
Как любителю матрешек, мне бы хотелось, чтоб даже у одного клиента было несколько бд, как минимум, разрграничивающие интерфейс от самих данных.
Является ли минусом мильен бд, хоть и с небольшим количеством таблиц?

Прошу прощения за некоторую неточность формулировки вопроса, интересует в первую очередь механизм работы бд MySQL, MariaDB или PostgreSQL (насколько быстро и ресурсоемко) в случае одновременного обращения на сервер нескольких клиентов, когда:
a) на всех клиентов одна бд с мильеном таблиц;
б)  у каждого клиента своя бд (одна или несколько) со сравнительно небольшим кол-ом таблиц;
в) можно ли использовать для какой-то оптимизации то, что структуры таблиц в случае а) или бд (в случае б) абсолютно зеркальны у каждого клиента?

>  на всех клиентов одна бд с мильеном таблиц;

Поскольку "структуры и количество таблиц у всех клиентов одинаковые", то можно обойтись и без мильена. Если в каждую таблицу добавить поле ID_клиента, то она будет одна на всех.

Хорошо это, или плохо - не знаю. Таблица-то одна, и это плюс, но есть и минусы (растет объем таблицы, может возникнуть вопрос с разграничением доступа к записям, усложняется работа с таблицей и т.п.). Это уж на месте виднее.

Мне вариант б). больше нравится. Данные - это собственность клиента, вот пусть он сам их и ведет, и за косяки в данных пусть сам отвечает. Но есть шанс, что замучают гневными вопросами типа "программа не работает", а на самом деле - косяк в данных. Это надо иметь в виду и заранее предусмотреть жесткий контроль данных при вводе.

> KilkennyCat ©   (20.08.16 02:42) 

посмотри в сторону ORM, современные CMS все больше переходят на те или иные реализации этого подхода.

Я за вариант а)

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

Ну и что что клиентов "десятки тысяч"?
Из этого же ничего не следует.
Если в таблицах по 1 записи по клиенту - то это семечки, если как то по другому то и смотреть надо на это "как"..

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

> Игорь Шевченко ©   (20.08.16 10:13) [4]

тоже думаю о варианте a), хотя он мне не нравится, но ощущение, что он правильней.


> ухты ©   (20.08.16 11:20) [5]

поэтому и спрашиваю, потому что не знаю механизма. мож для каждой транзакции идет открытие-закрытие бд, как например в локальной SQlite , что ресурсоемко и для десятка тысяч бд даже с одной таблицей с одной записью с одним полем int.


> Юрий Зотов ©   (20.08.16 14:19) [6]

да, это третий вариант. тут вырастает количество записей в таблице.

Хранение в одной бд смущает еще тем, что физически это будет, грубо говоря, один файл.

> Хранение в одной бд смущает еще тем, что физически это будет,
>  грубо говоря, один файл.


А где здесь повод для смущения ?

> это будет, грубо говоря, один файл.

Который можно спереть...

> Игорь Шевченко ©   (20.08.16 15:10) [8]

вот ты спросил и я не смог найти объяснения, точнее смог, но и сам же себе опроверг их.
мда..

возьми парадокс.
там грубо говоря не один файл, а много файлов.

> iop ©   (20.08.16 18:28) [11]

Выше я упоминал три варианта, MySQL, MariaDB или PostgreSQL. Возможно, имеет право на существование еще и MSSQL. Но точно не Парадокс.
И если мне не изменяет память, то у MySQL три файла - индексы, данные и инфо о структуре. MariaDB, вероятно, не сильно ушла в сторону. Про PostgreSQL и MSSQL не знаю.

какая вообще разница сколько там файлов, если с файлами работает сервер, а ты работаешь с объектами сервера?

у оракла всего одна бд на весь инстанс и минимум файлов
у мсскл несколько бд и минимум по два файла на бд.
у мускула полный аналог парадокса.

но нам-то што с этого?

> iop ©   (20.08.16 19:20) [13]
>
> но нам-то што с этого?

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

KilkennyCat ©   (20.08.16 20:03) [14]

> хочется заранее понять и спрогнозировать возникновение хотя
> бы основных подводных камней.


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

ну вот взять к примеру бэкапирование. или изменение структуры. или еще какие-либо административные действия. Если имеется раздробление на кусочки, то это можно делать этапно, не приостанавливая надолго работу всей системы, и время каждого этапа минимально, а за малое время и каким-то неприятностям возникнуть сложнее.
Потом подумал, и понял, что никто не запрещает делать что-либо как угодно параноидально в любых вариантах.
В общем, сам не понимаю, чего боюсь. И боюсь, что боюсь вовсе не того, чего надо бояться, а чего надо бояться - о том не знаю.
Такие вот сомнения.
У меня нет опыта работы с большими и многоклиентскими решениями.

> У меня нет опыта работы с большими и многоклиентскими решениями.


Глаза боятся, руки делают.
Насчет бекапа - в больших многоклиентских системах существует техническое обслуживание, во время которого на сайте вешается объявление - извините, у нас перерыв на такое-то время. Как вариант.
Насчет CMS - ты хочегь сделать что-то вроде аналога blogspot.com, если я тебя правильно понял ?

Если имеется раздробление на кусочки,

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

и нужно сделать alter table

берешь и делаешь.

а если в мускуле все на раздробленных кусочках,
то типа я возьму фар нажму ф4 и руками там побырому наалтерю таблицы?

> Игорь Шевченко ©   (20.08.16 21:46) [17]
>
> ты хочегь сделать что-то вроде аналога blogspot.
> com, если я тебя правильно понял ?

Примерно. Разница лишь в том, что у клиента уже может быть (и скорее всего) свой сайт и сервис будет инклюдом в него.


> iop ©   (20.08.16 21:54) [18]
> а если в мускуле все на раздробленных кусочках,
> то типа я возьму фар нажму ф4 и руками там побырому наалтерю
> таблицы?

Нет, зачем же. Создам некий инструмент администрирования, который будет, например, учитывать временную зону клиента, и какие-либо изменения для каждого клиента будут локальной ночью. Это в любом случае придется делать.
Чтобы сократить
> техническое обслуживание, во время которого на сайте вешается
> объявление

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

> Kerk ©   (20.08.16 23:23) [20]

Вот... если уж ты по уши, то мне ваще кранты :)

все эти заморочки с выбором по файлам странны.

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

> iop ©   (21.08.16 00:09) [22]
>
> все эти заморочки с выбором по файлам странны.
>
> клиент заказывает такси,
> диспетчер ему говорит, что есть новый опель, старый мерс
> и трехлетняя приора.
> а клиент заморочен скольки клаппаный движок в каждой.

Ничего странного. Клиент озабочен тем, чтобы он достиг нужной точки в нужное время.

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

> KilkennyCat ©   (21.08.16 00:59) [24]

<OFFTOP>
Уж как мне всё это до боли знакомо. :)
</OFFTOP>

Ничего странного. Клиент озабочен тем, чтобы он достиг нужной точки в нужное время.

Клапана-то здесь причем?
Ни таксопарк ни водила не даст клиенту воспользоваться заказанной услугой на уровне клапанов движка.
Будь клиент хоть механиком мотористом восьмидесятого уровня.

> iop ©   (21.08.16 12:11) [26]
>
> Ничего странного. Клиент озабочен тем, чтобы он достиг нужной
> точки в нужное время.
>
> Клапана-то здесь причем?

А при том что "клиент озабочен"! И при том что клиент не верит на слово диспетчеру.
Тут с одной стороны прав ИШ, когда говорит
> Глаза боятся, руки делают

а с другой стороны надо с чего-то начинать делать. А с чего именно непонятно.

>  надо с чего-то начинать делать. А с чего именно непонятно.
с чего всегда, с постановки задачи, так думается )

Перечитал первый пост. Ну дак база на сервере же? И структура не различается у клиентов. Тогда разумнее одна БД на всех а в БД  одна структура на всех. Вроде бы целый mail.ru работает на MySQL и я сильно сомневаюсь что у них там на каждого из 30 миллионов клиентов что-то отдельно создаётся, кроме как, добавление клиента в таблицу "список клиентов" с присвоением ему ID.

> KilkennyCat ©   (20.08.16 20:03) [14]
> привычка понимать механику всего, учитывая, что весь проект
> мне делать в одиночку, полностью, начиная с установки сервера
> и заканчивая его поддержкой. хочется заранее понять и спрогнозировать
> возникновение хотя бы основных подводных камней.

"Подводные камни" - в администрировании БД и её тюнинге правильными индексами, если количество записей в таблицах будет большим.
Сколько там файлов - никого не парит вообще.

Кстати, ЮЗ назвал весьма верный критерий при выборе: разграничение прав готовыми средствами сервера БД.
Как правило, сервера БД элементарно (т.е. встроенными средствами) позволяют разграничить доступ разным пользователям к разным таблицам или разным БД в рамках одного сервера.
А вот разграничить доступ на уровне записей в одной таблице готовыми средствами администрирования - вроде где-то слышал, но это точно не типичная задача, поддерживаемая большинством серверов. (чтобы другой пользователь не получил чужие даные, не изменил чужие данные намеренно или из-за ошибки в твоём ПО.) Т.е. в этом случае придётся разграничивать уже в своём приложении (или самописных хранимых процедурах), а это время на написание, отладку, риск собственных ошибок при развитии приложения и, как следствие, несанкционированный доступ к данным или их изменение.

Если это вообще критично для задачи - то стоит про это подумать. Если не критично - то пофик, валить однотипные данные клиентов в одни и те же таблицы, разделяя по user_id.

А вот разграничить доступ на уровне записей в одной таблице .....

над этим можно думать когда пилишь обычную двузвенку.

а майл-ру (к примеру) живи он хоть на оракле с роулевел секурити
никогда и низачто не будет пускать на sql сервер всех своих 30 мультов клиентов под разными личными аккаунтами.

так что про эту фичу в этом конкретном случае можно тоже не париться.

>KilkennyCat
FYI:

http://dataconomy.com/sql-vs-nosql-need-know/
https://www.oreilly.com/ideas/data-modeling-with-multi-model-databases

Другая неплохая статья:
https://www.mongodb.com/nosql-explained

>Является ли минусом мильен бд, хоть и с небольшим количеством таблиц?
Мое мнение: не является.
Но на мой взгляд, логичнее и удобнее в поддержке иметь одну БД Production на клиента (естественно, можно создать еще и несколько других подобных БД (тест, пред-production, etc))

Performance.
Достигается другими путями ежели в SQL DB, особенно учитывая легкость в "горизонтальном" наращивании мощностей.

ПС. Для выполнения моих задач, я остановился на ArangoDB.
http://vschart.com/compare/arangodb/vs/mongodb

> Empleado ©

спасибо.