Выделенная база данных для каждого пользователя по сравнению с отдельной базой данных для каждого пользователя

Question

В ближайшее время я разработаю большую систему cms, где пользователи смогут настраивать свой веб-сайт для управления новостями, продуктами, услугами и многое другое о своей компании. Подумайте о покупке без части электронной коммерции (по крайней мере пока). rdbms - это MySQL, а пользовательская база будет около 150 (может быть, больше).

Я пытаюсь выяснить, какой из этих двух подходов будет лучше.

DEDICATED для каждого пользователя

PROS: (? И возможного будущего шардинга)

• производительности: запрашивают меньшую базу данных только с вашими данными лучше, чем запрашивая гигантскую базу данных с каждым пользователем данными?
• легко «экспортировать мои данные» для пользователей: я могу просто сбросить свою собственную БД не извлекая все и положить его в какой-нибудь большой закодированной логической datastruct

единой базы данных для каждого пользователя

ПРОФИ:

• менее общие накладные
• статистика: только один децибел для запроса, чтобы получить и агрегатное все, что мне нужно
• резервная копия: одна свалка (не уверен в этом, потому что у меня нет опыта в кластерном захоронении)

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

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

Answer 1

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

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

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

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

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

150 пользователей не так много. Не беспокойтесь о масштабируемости, пока у вас не будет рабочей нагрузки для клиентов. Когда это произойдет, вы можете добавить оперативную память MySQL, разделы, твердотельные диски, репликацию, memcached, sharding и все, что связано с другими дорогостоящими и высоконагруженными файлами. Если вы добавите эти вещи, прежде чем отправиться жить, вы просто займете больше времени и нанесите больше денег, прежде чем вы начнете жить. Нехорошо.