Здравствуйте.
Планируется реализовать сервис для email-маркетинга. В системе существует множество аккаунтов, которые могут содержать несколько пользователей для их управления, а также списки рассылки, маркетинговые кампании, информация о рассылке и т.д.

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

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

Ниже я попытался привести некоторые плюсы и минусы каждого варианта.

Использование одной большой базы данных

Плюсы:
1. Нужно поддерживать только одну базу данных.

Минусы:
1. Хранение информации об аккаунта в одной базе данные может откывать возможность доступа одного аккаунта к данным другого (данные об аккаунте в принципе независимы друг от друга).
2. Копирование очень большой базы данных может занимать много времени.

Использование отдельной базы данных для каждого аккаунта
Плюсы:
1. Данные разным аккаунтов изолированы друг от друга.
2. Работа с маленькой базой данных аккаунта выполяется быстро.

Минусы:
1. Нужно поддерживать много БД (поддержка большого числа бд кажется настоящим кошмаром).
Спасибо.

АнатоЛой,

Но ведь можно использовать множество экземпляров БД и даже физические располагать на разных серверах, ведь так?

АнатоЛой,

Количество аккаунтов может достигать со временем десятков тысяч, а может и сотен.

АнатоЛой,

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

Lemegeton,

Дело в том, что для каждого акканта нужно хранить не только списки пользователей, сообщения рассылки, но много другой информации (сколько открывались сообщения, кем) и эта количество этих данных будет быстро расти, требуется рассчитывать много параметров.
Сотни тысяч аккаунтов, в каждого аккаунте десятки-сотини тысяч подписчиков, статистика по каждой маретинговой компании каждого подписчика. Кажется, базу перекапывать придется очень и очень много, а расчет статистики может быть очень трудоемким.
А бэкап такой базы делать не будет проблематично?
Если встанет вопрос масшибирования, в каком направлени потом двигаться?
Встает вопрос зачем люди извращаются с большим количество баз данных (по одной на аккаунт).

На самом деле я изначально склонялся к одной базе, но теперь терзают сомнения.

Если кого интересует и кто в ладах с английским, может посмотреть ссылки, что пишут люди по этому поводу:
http://stackoverflow.com/questions/128919/extreme-sharding-one-sqlite-database-per-user
http://stackoverflow.com/questions/2804452/database-per-application-vs-one-big-database-for-all-applications
http://stackoverflow.com/questions/617833/user-authentication-when-using-single-database-per-client
http://stackoverflow.com/questions/13348/what-are-the-advantages-of-using-a-single-database-for-each-client

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

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

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

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

Роман Дынник,

А не будет ли проблемой большое время бэкапа одной большой БД?

Роман Дынник,

Как я понимаю разница между спамом и email-маркетингом огромная. Спам приходит к вам вопреки вашего желания и вы не можете от него отписаться. Здесь же для того, чтобы вам приходили сообщения вы должны дать согласие и в любой момент можете отписаться. Чувствуете разницу.
Если кто-нибудь попытается отправлять спам с помощью такой системы (придет жалоба от пользователя, провайдера), его просто заблокируют.

АнатоЛой,

Может быть подскажите, сколько примерно будет выполняться резервное копирование базы данных несколько десятков гигибайт, во время работы сайта? Порядок цифр.

Роман Дынник,

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