Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
Сыроват, конечно, сервис. Но задумка очень интересная!
ммм... не стоит пренебрежительно относиться - в таком случае все решения гугла сыроваты, ибо функционала у них ровно столько, сколько нужно. Ничего лишнего просто нет. И это не универсальный сервис, под него необходимо разрабатывать или адаптировать.
Зато решены уже все проблемы дальше самого движка сайта ) никаких мыслей по поводу серверной части, оно того стоит для проектов больше среднего.
Зато решены уже все проблемы дальше самого движка сайта ) никаких мыслей по поводу серверной части, оно того стоит для проектов больше среднего.
>>This is a PREVIEW RELEASE of Google App Engine--for now, applications are restricted to the free account limits. ...
Думаю перевод не нужен
Думаю перевод не нужен
> Есть только один способ запустить код - это загрузить его на сервер.
не понял, а как же Development Web Server, который предприимчивые товарищи даже успели запустить на Amazon EC2?
не понял, а как же Development Web Server, который предприимчивые товарищи даже успели запустить на Amazon EC2?
Да, существует The Development Web Server, но как видно из документации он лишь "emulates the App Engine services such as the datastore". То есть локально утрачиваются все возможности среды, используемые в уже рабочем готовом приложении. Имелось ввиду "запустить код со всеми достоинствами, которые предоставляет решение от Google".
достоинство - это автоматическая масштабируемость. чтобы ощутить это достоинство, вам придётся сначала закупить достаточное число серверов :)
в остальном DWS - практически то же самое что работает в продакшне.
в остальном DWS - практически то же самое что работает в продакшне.
Согласен. Автоматическая масштабируемость - есть то, ради чего (в большинстве случаев) используется GAE. Если у разработчика все отлично локально, зачем ему данный продукт? Как показывает практика, уже давно рабочее приложение тестируется непосредственно на сервере (особенно в случае мелких поправок). Это связано с ленью и отсутствием желания поднимать всю базу данных у себя. А так часто глючит именно в "этой статье" и с таким расположением звёзд :)
кстати говоря, GAE дает отличную возможность тестировать на "staging" сервере. Это когда у вас два GAE приложения. Одно такое все платное (в смысле, не помещающееся в бесплатные квоты) и открытое для других пользователей. А другое такое бесплатное, закрытое и куда сначала вливается версия и тестится на, например, кусочке snapshot-а основной базы недельной давности или просто на тестовой базе.
Не вижу никаких проблем, чтобы научить GAE показывать кнопочку в staging приложении: "скопироваться на production приложение"
Не вижу никаких проблем, чтобы научить GAE показывать кнопочку в staging приложении: "скопироваться на production приложение"
не в "том питоне" - ибо звучит как прям нет в природе такого :) - а в API.
о ФС - вполне логично, раз строим распределенную систему - хранилище должно быть тоже распределенным. Зачем писать еще и ФС, если уже все вопросы решены на уровне базы? Да и гугл сам использует bigtable для хранения файлов, не жалуются.
и о сетевых возможностях - они полностью исчерпывающие для веб приложений. То есть, есть ВСЕ необходимые :) Или проблема в том, что нельзя написать распределенного спам бота?
право - аргументы не понятны, звучат больше как жалобы
о ФС - вполне логично, раз строим распределенную систему - хранилище должно быть тоже распределенным. Зачем писать еще и ФС, если уже все вопросы решены на уровне базы? Да и гугл сам использует bigtable для хранения файлов, не жалуются.
и о сетевых возможностях - они полностью исчерпывающие для веб приложений. То есть, есть ВСЕ необходимые :) Или проблема в том, что нельзя написать распределенного спам бота?
право - аргументы не понятны, звучат больше как жалобы
> отсутствует возможность писать на файловую систему
а можно поинтересоваться, что бы вы туда хотели писать?
про сетевые возможности более-менее понятно, но это нереально с точки зрения безопасности.
а можно поинтересоваться, что бы вы туда хотели писать?
про сетевые возможности более-менее понятно, но это нереально с точки зрения безопасности.
в большинстве случаев жалобы "нет возможности писать в ФС", как я понимаю, относятся к переносу на GAE готового кода, который хочет по каким-то причинам писать в ФС. Тут можно только посоветовать впредь писать так, чтобы файловое хранилище легко заменялось чем-то другим
чего-то я нигде не встретил, как у них работать с сессиями? встроенного механизма нет (или есть?), а джанговские не работают.
Буду Вам крайне признателен, уважаемый автор замечательной статьи, если Вы будете так любезны и немного обьясните, как можно более простым языком, что Вы понимаете под:
"масштабируемая среда для высоко-нагруженных приложений, которые работают с большими наборами данных. Именно в такой ситуации она будет вам полезна, хотя вы и можете ее использовать, как угодно. Нужно понимать, как позиционируется продукт и как правильно необходимо его использовать."
Или просто примеры для чего подходит а для чего нет. Заранее благодарен.
"масштабируемая среда для высоко-нагруженных приложений, которые работают с большими наборами данных. Именно в такой ситуации она будет вам полезна, хотя вы и можете ее использовать, как угодно. Нужно понимать, как позиционируется продукт и как правильно необходимо его использовать."
Или просто примеры для чего подходит а для чего нет. Заранее благодарен.
не автор статьи, но попробую пояснить. База данных, используемая в GAE, относительно медленная для запросов, которые затрагивают сразу много записей. Зато она умеет достаточно быстро вытаскивать конкретные записи и скорость практически не падает при увеличении размера базы до терабайт.
Стандартные реляционные БД, вроде того же MySQL, позволяют достаточно быстро считать сложные запросы, в которых есть JOIN-ы или агрегаты вроде SUM(), COUNT() или MAX(). Но при увеличении размеров базы до неприличного, начинаются пляски с бубном.
Поэтому, если база маленькая - GAE менее быстр. Если большая - очень удобен и быстр по сравнению со стандартными базами.
То же самое про количество пользователей: если их мало, проще иметь сервер поближе к ним (например, сервер в Москве). Если их очень дофига, GAE позволяет не думать, где бы поставить 10-10000 компов и где нанять людей, которые будут бегать и обслуживать их. И тут уже не сильно переживаешь, что приложение хостится где-нибудь в Европе и это добавляет немножко к latency.
Стандартные реляционные БД, вроде того же MySQL, позволяют достаточно быстро считать сложные запросы, в которых есть JOIN-ы или агрегаты вроде SUM(), COUNT() или MAX(). Но при увеличении размеров базы до неприличного, начинаются пляски с бубном.
Поэтому, если база маленькая - GAE менее быстр. Если большая - очень удобен и быстр по сравнению со стандартными базами.
То же самое про количество пользователей: если их мало, проще иметь сервер поближе к ним (например, сервер в Москве). Если их очень дофига, GAE позволяет не думать, где бы поставить 10-10000 компов и где нанять людей, которые будут бегать и обслуживать их. И тут уже не сильно переживаешь, что приложение хостится где-нибудь в Европе и это добавляет немножко к latency.
Если уж идти за совсем простыми примерами: bash.org.ru выиграет от размещения на GAE. Т.к. сложной работы с БД не содержит, зато куча пользователей и куча dos атак. GAE позволяет бороться с dos-ами. Как самый простой способ - просто отвечая на все запросы. Чуть сложнее - не очень тяжело показывать капчу наиболее активным ip-ам (не знаю, есть ли что-то там встроенное, но стороннее довольно быстро сделают)
Если же приводить примеры, для чего не подходит/не удобно, так это либо сервера mmorpg (которые хранят свое состояние в памяти), либо meebo, который требует tcp-ip соединений.
Теперь я понял:
(если размеры базы > неприличного) and (пользователей > дофига) = Google App Engine :)
Но все равно спасибо.
(если размеры базы > неприличного) and (пользователей > дофига) = Google App Engine :)
Но все равно спасибо.
спасибо от автора статьи за труд :)
>- завязка на Google Accounts
Это не совсем так. GAP даёт апи для работы с аккаунтами, но у разработчика остаётся выбор - можно использовать хоть OpenID.
Вы еще забыли упомянуть об ограничении в 500Мб на диске и 5 млн посетителей в месяц.
Кроме того результаты запросов ограничены 1 000 элементов.
А заказчики между тем ведутся :)
Это не совсем так. GAP даёт апи для работы с аккаунтами, но у разработчика остаётся выбор - можно использовать хоть OpenID.
Вы еще забыли упомянуть об ограничении в 500Мб на диске и 5 млн посетителей в месяц.
Кроме того результаты запросов ограничены 1 000 элементов.
А заказчики между тем ведутся :)
ну. Это же ограничения тестового периода. После его завершения, эти квоты будут для бесплатного аккаунта, а все что выше - будет оплачиваться. Чем это плохо-то?
о гуглакаунтах - я думаю подмечено верно,
лимиты посетителей/объемов - только для бесплатных тестовых аккаунтов, как бы упоминать про них в продакшине не имеет смысла. Ожидаем просто цены ниже Amazon S3/EC2 систем
лимиты посетителей/объемов - только для бесплатных тестовых аккаунтов, как бы упоминать про них в продакшине не имеет смысла. Ожидаем просто цены ниже Amazon S3/EC2 систем
Лимит на возвращаемый QuerySet в 1000 элементов остается, и я забыл в предыдущем комменте - существовует еще таймаут на выполнение запросов к БД.
Цитирую доки:
Some features impose limits unrelated to quotas to protect the stability of the system. For example, when an application is called to serve a web request, it must issue a response within a few seconds. If the application takes too long, the process is terminated and the server returns an error code to the user. The request timeout is dynamic, and may be shortened if a request handler reaches its timeout frequently to conserve resources.
Another example of a service limit is the number of results returned by a query. A query can return at most 1,000 results. Queries that would return more results only return the maximum.
http://code.google.com/appengine/docs/wh…
Цитирую доки:
Some features impose limits unrelated to quotas to protect the stability of the system. For example, when an application is called to serve a web request, it must issue a response within a few seconds. If the application takes too long, the process is terminated and the server returns an error code to the user. The request timeout is dynamic, and may be shortened if a request handler reaches its timeout frequently to conserve resources.
Another example of a service limit is the number of results returned by a query. A query can return at most 1,000 results. Queries that would return more results only return the maximum.
http://code.google.com/appengine/docs/wh…
вы имеете ввиду экспорт гугловых аккаунтов через OpenID-сервер (как здесь http://openid-provider.appspot.com/) ?
боюсь что попытка реализовать pure python Imaging Library и заставить её работать на GAE упрётся в ограничение по времени на один запрос для большинства реальных применений. Разве что капчи делать.
И, кстати, я один расстроился что они в GAE не включили озможность пользоваться их map_reduce? (-:
И, кстати, я один расстроился что они в GAE не включили озможность пользоваться их map_reduce? (-:
Объясните мне кто-нибуть, там вообще нет JOIN-ов?
Из официальной документации я не понял как можно выбрать, к примеру топ-10 всех книг где автор - русский.
Из официальной документации я не понял как можно выбрать, к примеру топ-10 всех книг где автор - русский.
именно так. для решения такой задачи предлагают либо фильтры, либо выгребти всё и потом фильтровать в цикле:
http://groups.google.com/group/google-ap…
и
http://groups.google.com/group/google-ap…
т.е. например:
books = Book.all()
for book in books:
if book.author.country == russia:
#la-la-la
как я это понял. Хотя опять же вопрос - эта выборка вернет только первую 1000 книг, а что дальше?
http://groups.google.com/group/google-ap…
и
http://groups.google.com/group/google-ap…
т.е. например:
books = Book.all()
for book in books:
if book.author.country == russia:
#la-la-la
как я это понял. Хотя опять же вопрос - эта выборка вернет только первую 1000 книг, а что дальше?
http://code.google.com/appengine/docs/da…
проблем с выборкой всех книг не проблема - есть смещения в GQL:
проблем с выборкой всех книг не проблема - есть смещения в GQL:
[LIMIT [<offset>,]<count>]
[OFFSET <offset>]
Спасибо за ссылки.
Я там нашёл такой варриант:
но так и не понял, работает ли он или нет )
И, потом, полноценной заменой JOIN-а это не назовёшь
Странно всё это...
Я там нашёл такой варриант:
SELECT * FROM Person, Contact WHERE Contact.PersonID = Person.ID
но так и не понял, работает ли он или нет )
И, потом, полноценной заменой JOIN-а это не назовёшь
Странно всё это...
это вроде неявный JOIN,
и там вроде говорят что оно работать не будет.
так что - х.з. :)
и там вроде говорят что оно работать не будет.
так что - х.з. :)
а что такое JOIN? )
CROSS JOIN - это и есть FROM Person, Contact
INNER JOIN - это и есть FROM Person, Contact WHERE Contact.PersonID = Person.ID
нет OUTER JOIN-ов, но они не так часты в использовании даже, и OUTER выбирает одну из таблиц полностью - то есть уже не так страшно вынести пост-обработку на клиент, поток данных не упадет
CROSS JOIN - это и есть FROM Person, Contact
INNER JOIN - это и есть FROM Person, Contact WHERE Contact.PersonID = Person.ID
нет OUTER JOIN-ов, но они не так часты в использовании даже, и OUTER выбирает одну из таблиц полностью - то есть уже не так страшно вынести пост-обработку на клиент, поток данных не упадет
сижу жду инвайта, читаю пока группы и пишу мегакиллерсервис (привет, 
Vox
VoxЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Google App Engine: достоинства и недостатки