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

Question

[devilsD]

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

Answer 1

[Melkij]

У конструкторов типичный workload - около нуля на большинство площадок и небольшой процент активных. Заворачивать индивидуально каждого в свою БД - сильно утомительно в поддержке. Дожили до 1000 созданных сайтов (что не так уж много если не сказать "вообще крохи") - у вас 1000 баз, что уже весьма дофига. Выкатить в прод новую версию приложения - уже приключение.

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

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

Comments

[Boris Köln]

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

Да ладно?

[Melkij]

Boris Korobkov, ага. Да, это автоматизируется. И автоматизация обязательно добавит новых граблей, которых банально нет с одной большой базой. А понадобится ли вообще вторая база - ещё большой вопрос.

[Boris Köln]

Melkij, и чем же автоматизация одной БД с 10000 таблиц отличается от автоматизации 1000 БД с 10 таблицами?

[Melkij]

Boris Korobkov, ммм. Какие 10000 таблиц? Вы о чём и откуда они взялись?

[Boris Köln]

Melkij, допустим простой сайт с 10 табличками. А сколько БД/таблиц будет для 1000 сайтов?
Или предлагаете все данные РАЗНЫХ сайтов хранить в ЕДИНОЙ таблице?!!

[Melkij]

Boris Korobkov, 10 таблиц и будет. Данные 100% типовые, что им делать в разных таблицах?
Дорастёт база до полутеррабайтного размера хотя бы - ну можно спилить что-нибудь горячее (или наоборот холодное) на отдельный кластер СУБД.
Или вы собираетесь убеждать DBA, ежедневно работающего с базами на несколько террабайт под нагрузкой в тысячи qps, что игрушечная табличка всего-то в десяток-другой гигабайт - это охренеть какой объём данных и ничего работать не будет?

[Boris Köln]

Melkij, Суммарное количество данных во всех вариантах будет одинаковым. Вопрос только в том, сваливать ли данные по разным сайтам в ОДНУ большую таблицу-помойку или таки структурировать по разным таблицам/схемам/БД.

То есть вы предлагаете в каждую таблицу добавить id сайта и не забывать его проверять при каждом sql?

[Melkij]

Boris Korobkov, и в чём проблема нормализовать данные? Чем сущность "сайт" отличается от сущности "пользователь"? Или для истории заказов у вас тоже по своей таблице на каждого пользователя?

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

[devilsD]

Melkij, я тоже склоняюсь к шардированию. Может я переоценил обьемы данных - активных магазинов будет порядка 4-6т.

[Константин]

Boris Korobkov, идея работы с одной БД и единой структурой под много пользователей (сайтоконструктора например) — это настолько распространённый сценарий, что крупные БД под это дело спициальные опции сделали вроде упоминавшегося row level security у Postgres или private database у Oracle. Там проверка id пользователя автоматически в каждый селект в неявном виде вставляется. Никакого большого риска забыть это проверить нет. Но можно и на коленках реализовать своё. Тогда да, нужно не забывать.

Answer 2

[Boris Köln]

Если это группа магазинов под одной торговой маркой, продающие разные категории товаров (один косметику, другой бытовую технику, третий книги и т.д.), то все в одной БД, юзеры - в схеме public, каждый магазин - в отдельной scheme. По мере роста нагрузки, возможно, придется схемы выносить в отдельные БД/сервера.

Если это разные магазины для разных владельцев - конечно, все в отдельных БД и, возможно, даже на разных серверах.

Answer 3

[Александр Юдаков]

Раз вы задаете такой вопрос, значит задача вам явно не по зубам.
Бросайте эту гиблую затею.

Comments

[devilsD]

Помнится, что-то подомное мне советовали, когда я начинал изучать веб. Меня интересовал выбор фреймворка для разработки crm, за 3 месяца осилил эту задачу. Уже 3й год уверено работаю c yii и symfony, внедряюсь в пайтон. Сейчас на реальном проекте есть возможность освоить новую технологию, в чем смысл бросать эту "затею", ?