Можно ли действительно увеличиться с Django …, учитывая, что можно только использовать одну базу данных? (В models.py и settings.py)

База данных - не ваше узкое место.

Внимательно проверь свой браузер.

На каждую страницу HTML вы посылаете (в среднем) 8 других файлов, некоторые из которых могут быть довольно большими. Это ваши JS, CSS, графики и т.д.

Реальным недостатком производительности является то, что браузер запрашивает эти файлы и принимает байты s... l... o... w... l... y...

Чтобы масштабировать, сделайте это.

1. Используйте несколько фронт-эндов, сбалансированных с таким чистым программным решением, как wackamole. http://www.backhand.org/wackamole/

2. Используйте прокси-серверы типа squid для отправки "других" файлов. Они в основном статичны. Именно здесь 7/8 часть работы выполняется загрузкой на клиента. Не скупитесь на то, чтобы получить их правильно.

3. Используйте несколько одновременных mod_wsgi/Django для создания -- редкого -- куска динамического HTML, основанного на запросах БД. Убедитесь, что mod_wsgi находится в демоническом режиме, чтобы у вас было несколько серверов Django, доступных Apache. Создавайте столько, сколько Вам нужно. Они все идентичны, все параллельны, и все общие для Wackamole.

4. Используйте одну быструю базу данных, такую как MySQL, для тех немногих вещей, которые должны поступать из базы данных. MySQL будет использовать несколько ядер на своем сервере, так что он будет масштабироваться достаточно хорошо, без необходимости делать что-либо, кроме покупки памяти. Положите это в отдельную коробку, в отдельном ящике, выделенном и настроенном именно для этого.

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

Наконец, купите книгу Шлосснагла. http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X

Чтение масштабирования до миллионов пользователей не является проблемой базы данных, но исправляется с помощью балансировки нагрузки, кэширования и т.д., см. С. Лотт выше.

Масштабирование записи действительно может быть проблемой с базой данных. "Шардинг" и наличие нескольких БД могут быть одним из решений, но с SQL это сложно, сохраняя при этом реляционность БД. Популярными решениями стали новые типы БД "nosql". Но если у вас действительно есть такие проблемы, то вам нужна серьезная помощь эксперта, а не просто ответы от чуваков Stackoverflow. :)

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

Уже несколько отличных ответов (например, S. Lott), однако я подумал, что я должен трусить с некоторыми важными вещами:

Убедитесь, что не использовать базу данных для логических операций

Я понимаю привлекательность Порядок по или процедуры SQL Однако у вас есть только одна база данных, но у вас есть несколько серверов Django, пусть серверы обрабатывают это, если можете.

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

бросить большее оборудование к проблеме

MySQL и Oracle Scale довольно хорошо с аппаратным обеспечением, если у вас небольшая проблема производительности, вы можете начать с добавления более аппаратного обеспечения.

Разделите вашу базу данных

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

Обратите внимание на тюнинг, и следите за вашими запросами / индексом

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

Не принимайте решение о своих таблицах архитектуры в изоляции, но рассматривать запросы

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

Просто пара мыслей :)

Несколько разных совет:

• Я удивлен никто не упомянул это. Используйте MEMCACHED. Если вы получаете много повторяющихся типов запросов (которые делают большинство WebApps), это может сделать огромное значение.

• Рассмотрим использование отказоустойчивости Oracle и балансировку нагрузки . Это позволяет добавлять поддержку нескольких баз данных в одном соединении БД.

• Другое, что нужно рассмотреть, использует систему , аналогичную дружбе . Это решает проблему «Как мы вносим изменения в базу данных без остановки мира?» больше, чем что-либо.