Django - у меня готово небольшое приложение. Стоит ли мне использовать частный VPS или Google App Engine?

Question

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

Теперь, если я хочу установить его на свой собственный Linode VPS, мне нужно настроить mod_python or mod_wsgi,, а также memcache, Ngix, mySQL или Postgresql и т. Д., Чтобы он работал. Если я поставлю это GAE, все, что мне нужно сделать, это преобразовать модели в API-интерфейс GAE.

Что мне нравится в GAE - это масштабирование. (если они действительно могут это сделать)

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

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

Итак, если у вас есть опыт в этом, что вы рекомендуете:

1- Use VPS(s) for everthing
2- Use VPS(s) plus Amazon S3
3- Use VPS(s) plus Amazon S3 & SimpleDB
4- Use GAE

Кроме того: Смогу ли я избежать использования прав JOIN при использовании BigTable?

Примечание: у меня сейчас нет пространственной необходимости, но для таблицы местоположений она может понадобиться позже.

Я бы хотел знать, что ты думаешь!

Answer 1

Есть бизнес-риск и технический риск.

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

Технический риск заключается в том, что ваше приложение не может быть легко реализовано на платформе. Поскольку большинство опций VPS позволяют вам устанавливать произвольное программное обеспечение, они минимизируют это, опять же за счет дополнительных усилий по настройке с вашей стороны. AFAIK, самое большое ограничение, которое GAE навязывает вам, - это трудно выполнять длительные фоновые задачи. (Работа без JOIN и других аспектов ненормализованных данных требует другого подхода, но этот подход довольно распространен в веб-приложениях, независимо от того, где они работают, когда база данных SQL больше, чем может поддерживать один хост.)

Если вы справитесь с обоими этими рисками, GAE, похоже, сэкономит вам значительные усилия. Если вы не можете смириться с этими рисками, вы должны адаптировать свое собственное окружение.

Кроме того, я считаю, что S3 стоит того, независимо от вашего окружения. Это гораздо проще, чем обеспечить надежное резервное копирование статического хранилища локальных серверов, и вам никогда не придется беспокоиться о емкости. Лучше всего использовать его для данных, которые загружены, но редко перезаписываются или удаляются (например, фотоальбомы facebook).

Answer 2

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

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

Также настройка mod_wsgi, установка postgres и т. Д. Не представляет особой сложности, и вам пока не нужно беспокоиться о таких вещах, как балансировка нагрузки и избыточность дБ.

Если бы это был я, я бы предпочел долгосрочную уверенность традиционного сервера, а не быструю победу GAE. Однако все зависит от вашего видения приложения.

Answer 3

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

• Ваша схема не выполняет переход к BigTable
• Вы зависите от какой-нибудь библиотеки на C, которая не поддерживается GAE
• У вас есть несколько длительных запросов, которые превышают пороговые значения, налагаемые GAE

Answer 4

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

Можно ли обойтись без объединений? Я не знаю, так как я не знаю ваше приложение - я сам фанат SQL, но для достаточно простых нужд я не нашел его слишком трудным для адаптации. На мой взгляд, основное ограничение нереляционных БД заключается в том, что они нигде не так хороши, как реляционные для «специальных» запросов ... обычно вам приходится писать много процедурного кода вместо одного или двух хороших SELECT или двух. :-(. Но это скорее проблема «интеллектуального анализа данных позже», чем связанная с обслуживанием вашего веб-приложения - вероятно, ее лучше всего решить путем регулярной массовой загрузки данных из онлайн-хранилища веб-приложения в установку «хранилища данных». во всяком случае, даже если такое хранилище было реляционным в первую очередь; -).

Answer 5

Все, что мне нужно сделать, это преобразовать модели в API-интерфейс GAE.

Извините, вы полностью ошибаетесь.

Вам также необходимо переписать весь код views, который использует ORM. Нет никаких объединений. Поэтому вам приходится иметь дело с большим количеством процедурного кода и писать его, а не изящный SQL, который предоставляет U все, что вы хотите.

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

И затем, Гвидо сказал, что Django 1.1 будет включен в будущую версию Appengine. Я надеюсь, что у них будет стандартная система преобразования ORM в BigTable.

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

Answer 6

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

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