Можете ли вы действительно увеличить масштаб с Django ... учитывая, что вы можете использовать только одну базу данных? (В файлах models.py и settings.py) - PullRequest
5 голосов
/ 24 января 2010

Django позволяет использовать только одну базу данных в settings.py. Это мешает вам расширяться? (миллионы пользователей)

Ответы [ 6 ]

11 голосов
/ 24 января 2010

Django теперь поддерживает для нескольких баз данных .

8 голосов
/ 24 января 2010

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

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

Для каждой страницы 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. Постройте столько, сколько вам нужно. Все они идентичны, все параллельно, и все разделены с Вакамоле.

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

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

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

3 голосов
/ 24 января 2010

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

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

1 голос
/ 24 января 2010

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

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

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

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

1 голос
/ 24 января 2010

Уже есть несколько хороших ответов (например, С. Лотт), однако я подумал, что мне следует добавить еще несколько вещей:

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

Я понимаю привлекательность Order By или SQL Procedures, однако у вас есть только одна база данных, но у вас есть несколько серверов django, позвольте серверам справиться с этим, если вы можете.

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

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

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

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

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

Обдумайте настройку и следите за вашими запросами / индексом

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

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

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

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

0 голосов
/ 24 января 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...