Как хранить данные в базе веб сервиса?

Question

[abonu]

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

• Одна таблица с клиентами всех пользователей, в этой таблице Ключ со значением Пользователя
  
• Отдельная таблица с клиентами для каждого пользователя, имя User1_clients
  
• Отдельная база данных для каждого пользователя
  
• На Хабре читал про вариант с виртуализацией, когда для каждого пользователя создается виртуальная машина со своей версией веб-приложения и БД
  

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

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

Answer 1

[Александр Аксентьев]

Одна таблица с клиентами всех пользователей

единственный нормальный вариант.

Отдельная таблица с клиентами для каждого пользователя, имя User1_clients

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

200-500-1000 клиентов? как это вообще обслуживать?

На Хабре читал про вариант с виртуализацией, когда для каждого пользователя создается виртуальная машина со своей версией веб-приложения и БД

Аналогично. Бесконечные серверные ресурсы? Как обслуживать?

Comments

[abonu]

Александр Аксентьев а как быть, если, например, мне нужно хранить товары пользователей, для каждого это могут быть десятки тысяч, в таком случае это всё будет в одной таблице. Не скажется ли это на производительности?

[Александр Аксентьев]

abonu: десятки тысяч это ничто для субд.
Но это уже вопрос правильности архитектуры и оптимизации.

Когда у вас будет 1000 пользователей и на каждого таблица или еще лучше база своя, то проблем гораздо больше будет, чем при миллионах записей в одной таблице. Да оно даже без "костылей" не запустится например при таким количествах баз/таблиц т.к. это очень много файлов на диске.

[abonu]

Александр Аксентьев: спасибо, плюс вариант с одной таблицей единственный из представленных, который я представляю как реализовать))

Answer 2

[Alexey Epsilon]

Таблица users, в ней все пользователи. Таблица clients, в ней все клиенты всех пользователей.

Далее два варианта. Первый - если каждый клиент может быть прикручен только к одному пользователю, то в таблице clients будет столбец user_id, хранящий id того юзера, к которому он принадлежит.

Второй вариант - когда каждый клиент может быть прикручен к нескольким пользователям. Тогда нужно завести ещё одну таблицу users_clients, в которой будет два поля user_id и client_id. Каждая запись в этой таблице прикручивает одного любого клиента к одному любому юзеру (вариант М:М).

Comments

[abonu]

Понял, спасибо!

Answer 3

[Dimonchik]

Отдельная таблица с клиентами для каждого пользователя

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

Comments

[abonu]

dimonchik2013 а можно ли такое писать на django?