Что выбрать, единую базу или по базе на каждого пользователя?

Question

[Sergey Romanov]

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

Answer 1

[Станислав Макаров]

Все зависит от того, что предполагается давать пользователю в управление. Если сервис таков, что юзер никогда-никогда не должен получать доступ к базе, то тогда можно в одном наборе таблиц. Хотя разные БД будут проще в администрировании и на порядок безопаснее (вдруг где-то забудете сделать WHERE по id магазина). Если между магазами не будет общих данных, тогда преимуществ от использования одной базы ИМХО практически нет.

Comments

[Sergey Romanov]

Спасибо. У меня тоже вот не понятные сомнения на единую базу. Но и на то что бы плодить баз тоже не хочется. А что если будут 10 000 клиентов. Что будет столько баз? Тоже как то не понятно. Ведь их все нужно мониторить, ведь это SaaS а значит ты несешь ответственность за работоспособность базы.

И вот это то что вы упомянули о WHERE тоже серьезная вещь.

Короче однозначного решения пока не принял.

Answer 2

[Ivanq]

Вообще, без разницы. Но если важна читабельность базы данных человеком, лучше разделять хотя-бы по таблицам.

Comments

[Sergey Romanov]

Что значит читабельность? И как без разницы? Ведь например будет 100 клиентов у каждого по 2000 товаров. Это значит что в единой базе будет 200 000 товаров а в отдельных только по 2. Ну и маштабируйте это на больше клиентов. Конечно можно уплавлять базой, опимизировать и даже 1 000 000 000 записей могут работать быстро если знаешь что делаешь, а если на каждого пользователя отдельная база то вряд ли кто достигнит лимита где начинаются проблемы. Или например поехала база, слетел индекс или еще что из за одного пользователя, а перестанет работать у все. То есть нужна система бесперебойной работы где будет база мастер и слэйв и если одна отключится, вторая начнет работать. Это доп. ресурсы.

[Ivanq]

Sergey Romanov: Суммарно все равно одинаковое количество. Я предложил - первый вариант

Answer 3

[Пума Тайланд]

зависит сугубо от того как вы будете масштабировать базу и шардировать её.
если у вас от силы будет сто юзеров то вообще без разницы

Comments

[Sergey Romanov]

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

[Пума Тайланд]

Sergey Romanov: ну так ответьте сперва себе как вы будете шардировать данные то 7 отсюда выйдет сразу же ответ на ваш вопрос.

[Sergey Romanov]

Я думал использоать AWS Aurora а там это все уже полностью включено. Можно расширять до 15 экземпляров прчем в разных зонах. Одна мастер другие слейвы. Бесперебойная работа. Моментальное обнаружение проблем и их исправление и т.д.

[Пума Тайланд]

Sergey Romanov: аврора это форк mysql
все таки слейвы это не шардинг, если вы рассматриваете в разрезе одного сервера и слейвов, то без разницы.
верить в то что данные автоматом отмасштабируются в mysql это немного смешно

[Sergey Romanov]

Аврора это не форк mysql. Это база данных разработаная AWS но она совместима с mysql. Это умных ход. Все клиенты могут с ней наботаь. Переезд кода прост. Написать новую базу проблематчно в плане продвижения. Да и пользоваться. Привязался к ней и все. А тут получается любой код который работает на mysql можно на нее перевсти.

[Пума Тайланд]

Sergey Romanov: ахахаха посмотрите переменные внутри Авроры и вы найдёте с какой версии мускулы они сделали форк. Это форк сделанный в авс