Обратите внимание: я отвечаю с точки зрения SQL Server, поэтому я упоминаю некоторые концепции, специфичные для SQL Server, но я полагаю, что все эти концепции имеют эквиваленты в других основных платформах RDBMS с аналогичными преимуществами и ограничениями.
Я также, вероятно, продолжу редактировать этот ответ, поскольку я думаю о других потенциальных плюсах / минусах.
Ну, это действительно зависит от схемы, объема и т. Д. Что именно хранит магазин? Чем он отличается от хранения данных о 50000 кошек, 50000 продуктов или 50000 орехов?
Есть несколько причин (помимо одного лишь аспекта размера), почему вы можете не захотеть хранить данные для 50000 различных клиентов в одной базе данных, если действительно данные могут быть полностью разделены по клиентам (не включая таблицы поиска, такие как почтовые индексы или таблицы для конкретного приложения, которые могут быть помещены в единую центральную базу данных):
если один клиент перерастает приложение, нет простого способа извлечь только свои данные и перенести их на другой экземпляр, сервер и т. д. для масштабирования, если вы не планируете заранее и не разбиваете на что-то вроде CustomerIDи не имеете 50 000 файловых групп (вы ограничены в любом случае, до 15 000 разделов или до 1000, если вы используете более старую версию SQL Server и слишком много файловых групп может иметь катастрофические последствия ). Также обратите внимание, что для разделения требуется Enterprise Edition.
если окажется, что все ваши клиенты просто слишком велики для этого экземпляра, масштабирование означает получение нового оборудования и перемещение всей базы данных туда (и, возможно, повторение этого в будущем).
Удаление клиента может быть столь же болезненным, так как вам придется удалить несколько% строк из очень больших таблиц, и это будет недешево.
вы, вероятно, будете иметь широкое распространение данных о клиентах (один клиент с миллиардом строк, другой клиент с 5000). Это может привести к таким вещам, как сниффинг параметров и отрицательная производительность, включая количество элементов и качество плана (поскольку вы, вероятно, будете повторно использовать одни и те же планы для одних и тех же запросов в отношении очень разных наборов данных).
на всех ваших клиентов распространяются одинаковые SLA и планы HA / DR. Либо у вас есть вся база данных в режиме полного восстановления с n-минутным резервным копированием журнала, либо вы работаете в простом режиме и полагаетесь на полное + разностное резервное копирование. Если вам нужно вернуться из-за ошибки клиента или вам необходимо восстановить базу данных на определенный момент времени, это влияет на каждого отдельного клиента.
Существует вероятность ошибок при извлечении данных - ошибки, например, в случаях, когда предложения могут привести к тому, что один клиент увидит данные другого клиента или все данные других клиентов.
это может иметь юридические последствия (некоторые компании будут предъявлять строгие требования о том, чтобы вы не размещали их данные в той же базе данных, что и любая другая компания, и особенно их конкурентов).
если важна безопасность данных какого-либо одного клиента, то достичь этого гораздо проще, используя разделение базы данных, чем разделение внутри таблицы.
Некоторые преимущества наличия каждого клиента в отдельной базе данных (или, по крайней мере, наличие нескольких баз данных, каждая для группы клиентов):
- с точки зрения размера, он займет примерно такой же размер на диске.
- масштабировать проще, поскольку вы можете просто переместить базу данных (или несколько) на другой сервер.
- удаление клиента и всех его данных примерно соответствует
DROP DATABASE.
- вы используете больше памяти для планов (или у вас меньше планов в кеше для каждого клиента), но, по крайней мере, эти планы имеют отношение к данным в соответствующих базах данных и менее подвержены проблемам с отслеживанием статистики / параметров.
- Вы можете легко иметь различные SLA и планы DR, размещая одни базы данных полностью, а другие - просто. Кроме того, восстановление или восстановление на определенный момент времени влияет только на этого клиента.
- Вы можете легко разместить различные базы данных (скажем, ваши высокоприоритетные клиенты) на более быстрый ввод-вывод. Вы можете сделать это в одной базе данных с файловыми группами, но управлять этим гораздо сложнее (по крайней мере, IMHO).
Некоторые недостатки:
- Помимо размера, вы, вероятно, не захотите иметь 50000 баз данных на одном экземпляре SQL Server, поэтому это, вероятно, будет означать масштабирование до нескольких серверов.
- время запуска увеличивается, потому что при запуске каждой базы данных есть некоторые накладные расходы.
- приложение должно быть немного умнее - вместо того, чтобы просто иметь CustomerID в предложении where, оно должно динамически подключаться к базе данных CustomerID. Это не сложно с надлежащим средним уровнем, но это изменение.
- да, у вас много копий одних и тех же таблиц и процедур, но код и схема идентичны в разных базах данных, только данные разные. Таким образом, развертывание изменений кода / схемы теперь является просто циклом, а не одним выполнением.
- обслуживание немного отличается, когда вы управляете 50 000 баз данных - опять же, общий размер примерно одинаков, но процесс должен измениться - вы не можете просто дефрагментировать / переиндексировать / создавать резервные копии всех 50 000 баз данных одновременно. Сказав это, на моей предыдущей работе я управлял экземплярами с 500-1000 одинаковыми базами данных, и разница между управлением 3 одинаковыми базами данных и 750 одинаковыми базами данных - просто время, которое требуется.