Мультисайт и несколько баз данных на Django

Через админку джанги - нет, своими силами (написав свою админку - запросто). Мультисайтинг - это не для джанги. Там нужно поднимать отдельный uwsgi сервер для каждого сайта и на него уже проксировать nginx, статику выносить в nginx, в свою структуру папок и т.п., чтобы nginx разруливал статику под каждый Django сайт. Сервер баз данных типа постгресса - там легко сделать что вы хотите: под каждый сайт своя база данных, и уже в ней таблицы джанги. Баз данных на одном постгресс сервере может быть сколько угодно.

ну вот одминку допилить то можно как угодно, + читаем доку, там все хорошо описанно.

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

Враньё

как лучше сделать?

ТЗ написать и на его основе разработать архитектуру.

для каждой базы данных новую vds покупать?

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

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

Да, есть очень много способов.

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

Ну с чего-то же надо начинать :)

А вообще нужная основная управляющая база данных? Или просто много параллельных баз данных? Что вообще тогда будет в главной базе?

не понял зачем поднимать отдельный uwsgi для каждого сайта.

Ну а как вы в одном инстансе джанги будете хранить множество settings.py? Там же хеш для подписывания кук, установленные приложения и т.п.

Начни с туториала.
Что и для чего тебе нужно решать должен архитектор.
Джанга это не CMS, это даже не конструктор.
Это набор деталей для строительства завода по производству конструкторов.
Построить можно что угодно.
И ничто не мешает выстругать своих деталей, если в коробке чего-нибудь специфичного вдруг не окажется.

Вороньё

Елементарно будет.
Для начала изучи программирование вообще и питона в частности.
Вопрос не «как», но «зачем».
Но это вопрос к архитектору, а не для форума.

Понты - они до хорошего не доводят.

Я видел в инете экстеншены (middleware) для джанги чтобы сделать мультисайтинг. Вот, даже в составе джанги что-то есть:https://docs.djangoproject.com/en/1.9/ref/contrib/sites/

Базы плодить не нужно.

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

может есть смысл разбить базы на отдельные модули?

Может ты уже ТЗ написал и определился с архитектурными требованиями?
А с точки зрения ORM количество баз особой роли не играет.

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

Срочно посмотри вот этого телепузика:
https://www.youtube.com/watch?v=_Kex5hwGE-w

Тут правильно сказали про ТЗ. Без конкретных требований советовать что-либо - это как руками дым ловить.
Предположим, имеем требование жесткого взаимодействия/связи между сайтами. Тогда храня все в одной базе, вы уже тем самым упрощаете себе жизнь. Можете, допустим, делать запросы к нескольким сайтам сразу, использую объединения.
Или, допустим, взаимодействия/связей быть не должно, но бэкенд должен быть унифицированным для всех сайтов (отличаются только представления на фронте). Тогда, конечно, проще хранить все в отдельных базах, а коннект к конкретной определять внутри реализации интерфейса роутинга. Скажем, за счет какого-либо дополнительного свойства при запросе, пусть это будет домен 3-го уровня. Т.е. route1.domain.xx -> db1 / route2.domain.xx -> db2 и т.д. Здесь тоже можно поиметь плюсы, допустим при нагрузке масштабирование потребуется классическое горизонтальное. И внедрятся будет очень просто. Докупили сервер, перенесли N-кол-во баз, переписали реализацию интерфейса роутинга с учетом remote connect, и все.
Вообщем без конкретных требований в ТЗ - действительно сказать что-либо сложно. Я привел пример всего-лишь двух псевдо-требований. Если бы можно было увидеть основной список - можно было бы посоветовать что-то конкретное, причем аргументируя каждое решение.

Спасибо посмотрю.

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

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

А почему плодить не нужно?

ЕМНИП, postgres будет создавать по несколько процессов на каждую базу. Вот и будет у тебя на тачке тыща процессов просто так болтаться. С mysql, по-моему, такого нет. Я поэтому и посоветовал хранить всё в одной базе.

база может стать очень тяжелой, может есть смысл разбить базы на отдельные модули?

Это не совсем так работает. «Тяжесть» базы в первую очередь зависит от структуры и запросов, и только потом уже от объёма. Потом, «база» это тоже не то что ты думаешь, это всего-лишь набор таблиц. «Тяжесть» таблиц, их индексов и запросов определяют «нагрузку на базу». Если вы в одной базе всё сделаете, но дадите каждому сайту свои таблицы то всё будет хорошо.

Но, опять-таки, по условию вообще не понятно что за продукт вы готовите, сколько там будет реально данных и насколько вы понимаете что делаете. Все говорят что «у них будет мульон статей», а потом проект через год помирает в зачаточном состоянии и все «оптимизации» оказываются коту под хвост. Так что я бы не гнался за производительностью (оптимизация без экспериментов и нагрузочного тестирования ничего не стоит), я бы просто старался не делать серьёзных косяков. А таблица на миллион записей это фигня если у вас есть правильные индексы. Накрайняк, можно прикрутить кэширование :).

А какие-либо общие данные для всех интерфейсов имеются? Те, которые нужно хранить где-то в одной централизованной базе. Если да, я все же бы посмотрел в сторону решения разделения баз, но с использованием remote-connect для глобальной. За счет remote-connect решаете проблему централизованного наполнения, за счет глобальной базы, решаете проблему хранения спец. данных (допустим все пользователи, которыми может манипулировать root (изменять/добавлять/устанавливать права)). Может быть реализация прав будет позволять некоторым локальным пользователям также иметь доступ к данным других в одной группе прав, но это уже различные виды утопий :) Вообщем смысл такой - сначала нахождения всех ваших главных поинтов, затем уже проектирование.

Ну вот еще один поинт. Основные требования должны лежать на поверхности, и логически вытекать из самой задачи. Если архитектура была спроектирована без учета важного поинта, и даже еще не реализовано ничего, то даже перепроектировать достаточно затратно (зависит от общей сложности проекта), не говоря уже о самой реализации. Основные поинты должны быть видны сразу. Если они возникают в процессе проектирования - это какое-то неправильное проектирование :)

Кстати, по поводу поиска. Вы сказали что сайтов может быть много, и как следствие - данных для индексации. Поэтому, скорее всего, вы все равно будете использовать какие-либо поисковые движки, типа ES/Сфинкса/etc, поэтому у вас не будет проблемы разделения. Все равно глобальный индекс для поиска будет физически в другом месте находиться.

Если вы в одной базе всё сделаете, но дадите каждому сайту свои таблицы то всё будет хорошо.

Вот это плюсую, и не нужно заморачиваться.

Вот скажи какая будет нагрузка? (1)

Судя по тому что ты написал, ты сам все не до конца понимаешь(2)

Напишите уже хоть как.