Одна или несколько баз данных для приложения для многих клиентов в PHP - PullRequest
5 голосов
/ 03 декабря 2010

Я пишу PHP-приложение на ZF.Клиенты будут использовать его для продажи своей продукции конечным покупателям.Клиенты будут размещать свои приложения на моем сервере, или они могут использовать свои собственные.Большинство из них будет размещать это приложение на моем сервере.

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

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

Какое решение будет иметь лучшую производительность и насколько большой будет разница?Какой из них вы бы выбрали?

Ответы [ 5 ]

5 голосов
/ 03 декабря 2010

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

Если одному клиенту нужно, чтобы вы восстановили его данные, с одной базой данных это тривиально.На общей базе данных гораздо сложнее.

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

Если один сайт будет взломан,у вас нет всех данных для всех в одном месте, ущерб сводится только к взломанному сайту.

Я бы определенно рекомендовал использовать 1 дБ на каждого клиента, если это возможно.

2 голосов
/ 03 декабря 2010

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

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

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

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

Вы не хотите иметь армию из 1000000 сумасшедших клиентов вместо одного злого клиента.

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

1 голос
/ 03 декабря 2010

Производительность, в принципе, вы начинаете с подхода «шардинга».Из-за этого стратегия производительности шардинга будет легкой.

Недостатком является то, что вы можете утверждать, что теряете некоторые (неопределенные) накладные расходы при дублировании.

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

1 голос
/ 03 декабря 2010

В какой-то степени это вопрос личного мнения. Есть плюсы и минусы обеих моделей.

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

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

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

0 голосов
/ 03 декабря 2010

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

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

Модель клиента может иметь много продуктов // почему несколько баз данных?

Быстродействие может быть достигнуто любым из двух способов: простое использование нескольких дбс НЕ выиграет в этом направлении

...