Развертывание Django - локальное и удаленное

Question

У меня есть проект django, использующий postgres, для которого 85% + используются в локальной сети.Остальные 15% из Интернета.Время от времени случаи использования WAN достигают 90% в течение определенного часа или пары часов.

Проект - это просто приложение общего назначения, которое обслуживает небольшой город в штате Нью-Йорк (штат Нью-Пальц).

Доставка больших файлов или потокового мультимедиа через наши локальные 54 Мбит / с довольно хорошая;мы хотели бы сделать что-то вроде общественного доступа к телевидению и радио довольно скоро.

Производительность - не единственная проблема;Мы также хотим иметь возможность использовать приложение при полном отсутствии подключения к Интернету.Это в основном академическое упражнение, но не полностью: мы теряем нашу связь несколько раз в год во время штормов, и мы хотели бы быть в курсе.

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

Я бы хотел, чтобы экземпляр rackspace разрешал запись в базу данных, но передавал их в мою локальную БД, как только это было удобно, сохраняя локальную БД в качестве авторитетной.

Возможно ли это?Это хорошая практика?Это хорошо задокументировано?Есть ли лучший простой способ?

Answer 1

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

Сказав это, вот несколько общих советов.

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

Я видел огромные улучшения в производительности приложений Django за несколько простых шагов:

1. Анализ запросов к базе данных с помощью django-debug-toolbar, убедитесь, что вы создали индексы для всех столбцов, которые появляются в предложениях WHERE (если только эти столбцы не являются особенно тяжелыми при записи)

2. Убедитесь, что память вашего сервера не перегружена (free -m в linux, посмотрите во второй строке).

3. Убедитесь, что вы «долго кешируете» статическое содержимое (и в идеале оно подается с CDN ).

4. Если ваш провайдер облачного хостинга предлагает серверы баз данных, попробуйте их. Они, вероятно, в сотни раз быстрее, чем вы могли бы достичь самостоятельно VPS .

5. Опять же, с помощью django-debug-toolbar, посмотрите, какие SQL-запросы выполняются долго. Подумайте, кэшируются ли эти запросы? Если это так, используйте низкоуровневый API-интерфейс кэширования django, чтобы избежать ненужного повторного запуска дорогостоящих запросов к базе данных.

Также, если это возможно, выберите облачный хостинг, который географически близок вам. Разница между задержкой 300 мс и задержкой 8 мс огромна.

После всего этого, если вам все еще нужно локальное зеркало удаленной базы данных, это можно сделать.

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

Django позволяет вам настроить маршрутизаторы базы данных для каждой модели и для чтения / записи. Однако будьте очень осторожны при переходе на путь чтения из одного БД и записи в другой; никакая схема репликации базы данных не может гарантировать достаточно низкую задержку, чтобы не вызывать несоответствия данных.

Однако вы можете обнаружить, что вы можете добиться прагматичного результата, запустив ваше приложение contrib.auth (пользователи, сеансы) в базе данных чтения / записи, но другие приложения типа «отчеты» на зеркале только для чтения.

Надеюсь, это даст вам некоторые идеи.

РЕДАКТИРОВАТЬ: Поскольку вы продолжаете добавлять / изменять вопрос. Я собираюсь прояснить несколько вещей для вас:

Это возможно?

Да. При наличии достаточного количества времени и денег все возможно.

Это хорошая практика?

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

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

Хорошо ли это задокументировано?

Необычные развертывания редко документированы, это определенно необычное предложение.

Есть ли лучший простой способ?

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

Заключительные мысли

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

Тот факт, что это сложный вопрос, говорит мне, что вам нужно упростить ваше мышление относительно того, что является фактическим требованием.Можете ли вы подумать о тесте, который ваша система пройдет, а сегодня - нет, если вы добьетесь той выгоды, которую должны предоставить?

Answer 2

реализуемое Конечно.

Хорошая практика? Если вы можете себе позволить стоимость / скорость развертывания только в стойке, я бы просто запустил его в облаке.

Хорошо задокументировано? Различные части (репликация, автоматическое развертывание и т. Д.). Вам придется собрать их вместе, чтобы получить конкретный вариант использования.

Есть ли лучший способ? Зависит ... Единственная главная проблема, которую я вижу, - это синхронизация базы данных. Потенциальный способ обойти серверы стойки - это указать на вашу локальную базу данных через некоторый межсетевой экран / vpning. Тогда у вас просто есть веб-серверы в облаке с сценарием развертывания, чтобы сделать все необходимые обновления. Проблема в том, что если ваша внутренняя сеть выходит из строя, вы как бы облажались Если это только для внутреннего использования компанией, это время простоя может быть приемлемым. Трудно сказать, не зная вашего конкретного случая использования.