Подтвердить что ты не робот

Многопользовательский PHP SaaS - Разделять БД для каждого клиента или группировать их?

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

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

Параметры, которые, как мне кажется, хранятся в таблице, касаются хранения данных:

Вариант 1. Храните все в одной большой базе данных и используйте поле "client_id" в таблицах, которые ему нужны (около 30 таблиц, к которым оно относится) и имеют "таблица клиентов", хранящая их основные настройки, данные и т.д., и домен для их сопоставления. Затем это просто устанавливает глобально доступную переменную, содержащую их индивидуальный идентификатор клиента - я, очевидно, должен будет изменить каждый отдельный запрос, чтобы проверить столбец client_id.

Вариант 2. Имейте мастер-таблицу с таблицами "общая ссылка" и таблицей "клиенты". Затем есть "блоки" других баз данных, каждая из которых содержит, скажем, 10 клиентов. Клиент получит свои собственные таблицы базы данных с префиксом их идентификатора клиента. Это добавляет немного защиты для защиты от просмотра других данных клиента, если что-то пошло не так.

Вариант 3. Точно так же, как и вариант 2, за исключением того, что у вас есть 1 база данных для каждого клиента, полностью изолируя их от других клиентов и теоретически предоставляя немного больше защиты, если 1 клиентская таблица были взломаны или иным образом повреждены, это никому не повлияет. Самый большой недостаток заключается в том, что при развертывании нового клиента необходимо создать всю базу данных, пользователя и пароль и т.д. Может ли это также вызвать слишком много накладных расходов, или это будет почти так же, как если бы у вас были все в одном базы данных?

Несколько пунктов: некоторые из этих клиентов будут иметь 5000+ клиентов вместе со всеми подробностями для этих клиентов - вот почему вариант 1 может быть немного проблемой - если у меня есть 100 клиентов, которые могли бы равняться более полумиллиона строк в 1 таблице.

Правильно ли я думаю, что вариант 3 - лучший способ пойти в ситуации, когда ключом является безопасность данных клиента (и информации о платежах). Из рекомендаций, которые у меня были, несколько человек сказали, что идут с вариантом 1, потому что "его легче", однако я действительно этого не вижу. Я вижу это как потенциальное узкое место в очереди, так как я уверен, что я могу перемещать клиентов намного проще, если у них есть собственная база данных.

(FYI. Система основана на PHP на основе MySQL)

4b9b3361

Ответ 1

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

Ответ 2

Я согласен с Ozzy - я сделал это для онлайн-продукта базы данных. У нас была одна основная база данных, в которой в основном была прославленная таблица пользователей. У каждого клиента была своя база данных. Что было здорово в этом, так это то, что я мог перемещать одну базу данных клиентов с сервера A на сервер B легко [mysql] и мог делать это с помощью средств командной строки в крайнем случае. Кроме того, выполнение обслуживания на больших таблицах, сброс/добавление индексов может действительно испортить ваше приложение, особенно если, скажем, добавление индекса блокирует таблицу [mysql]. Это затрагивает всех. С, по-видимому, меньшими базами данных, вы более невосприимчивы к этому и имеете больше возможностей, когда вам нужно развертывать изменения уровня схемы. Мне просто нравится гибкость.

Ответ 3

Когда много лет назад я разработал платформу для создания приложений SaaS на PHP, я выбрал третий вариант: мультитенантный код и базы данных с одним арендатором.

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

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