Как правильно реализовать структуру бд для многопользовательской платформы?

Стоит задача реализовать платформу по созданию Интернет магазинов - что-то похожее на конструктор сайтов. Правильно ли будет данные для всех магазинов хранить в одной бд, или для каждого им разворачивать отдельную базу? Кто разрабатывал подобные приложения, может есть более логичный подход к задаче?
  • Вопрос задан
  • 1532 просмотра
Пригласить эксперта
Ответы на вопрос 3
Melkij
@Melkij
PostgreSQL DBA, contributor
У конструкторов типичный workload - около нуля на большинство площадок и небольшой процент активных. Заворачивать индивидуально каждого в свою БД - сильно утомительно в поддержке. Дожили до 1000 созданных сайтов (что не так уж много если не сказать "вообще крохи") - у вас 1000 баз, что уже весьма дофига. Выкатить в прод новую версию приложения - уже приключение.

Если вы хотите SaaS - т.е. у конечных пользователей прямого доступа в БД нет никакого - то в поддержке сильно проще будет классическая схема шардирования. К тому же у вас данные разных клиентов заведомо по предметной области никак не пересекаются.
- в таблицах специфичных для клиентов вводится site_id и входит в уникальные ключи и прочее счастье ограничений целостности (для postgresql можете дополнительно прикрутить row level security и база будет дополнительно приглядывать)
- отдельно размещается ваш биллинг и управление пользователями, где помимо прочего пишете таблицу соответствия, какой site_id расположен на каком физическом хосте и в какой базе данных (плюс список ro-реплик)
- закешировать соответствие сайта базе можно в каком-нибудь redis и ходить с одного единого пула серверов приложений что сильно проще по масштабированию приложения (если сервер приложения рассматривать как stateless, что опять же сильно проще в поддержке).

В итоге схема позволяет работает с осмысленным числом крупных баз (начиная с одной и вводя новые по необходимости), неактивные сайты мигрировать в архивные базы, горячие от дорогих клиентов - выделять хоть даже в отдельную инфраструктуру. Кстати, фокус с отделением vip-клиента в отдельную инфраструктуру позволяет дать этому клиенту и прямой доступ в базу при необходимости и возможность пилить кастомный функционал именно для него.
Ответ написан
@BorisKorobkov
Web developer
Если это группа магазинов под одной торговой маркой, продающие разные категории товаров (один косметику, другой бытовую технику, третий книги и т.д.), то все в одной БД, юзеры - в схеме public, каждый магазин - в отдельной scheme. По мере роста нагрузки, возможно, придется схемы выносить в отдельные БД/сервера.

Если это разные магазины для разных владельцев - конечно, все в отдельных БД и, возможно, даже на разных серверах.
Ответ написан
AlexanderYudakov
@AlexanderYudakov
C#, 1С, Android, TypeScript
Раз вы задаете такой вопрос, значит задача вам явно не по зубам.
Бросайте эту гиблую затею.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы