Как стать автором
Обновить

Комментарии 61

Сыроват, конечно, сервис. Но задумка очень интересная!
ммм... не стоит пренебрежительно относиться - в таком случае все решения гугла сыроваты, ибо функционала у них ровно столько, сколько нужно. Ничего лишнего просто нет. И это не универсальный сервис, под него необходимо разрабатывать или адаптировать.

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

PS: наркотой не пользуюсь, мне хватает и гугла и остальных )
>>This is a PREVIEW RELEASE of Google App Engine--for now, applications are restricted to the free account limits. ...
Думаю перевод не нужен
но все равно, со времени публикации материала уже успели не смотря на эту надпись добавить изрядно функционала - серверную работу с изображениями и memcached для кеширования
НЛО прилетело и опубликовало эту надпись здесь
даже лучше - можешь подгружать любые Python библиотеки, то есть не только yaml - а все что пожелаешь ;)
НЛО прилетело и опубликовало эту надпись здесь
Да, существует The Development Web Server, но как видно из документации он лишь "emulates the App Engine services such as the datastore". То есть локально утрачиваются все возможности среды, используемые в уже рабочем готовом приложении. Имелось ввиду "запустить код со всеми достоинствами, которые предоставляет решение от Google".
НЛО прилетело и опубликовало эту надпись здесь
Согласен. Автоматическая масштабируемость - есть то, ради чего (в большинстве случаев) используется GAE. Если у разработчика все отлично локально, зачем ему данный продукт? Как показывает практика, уже давно рабочее приложение тестируется непосредственно на сервере (особенно в случае мелких поправок). Это связано с ленью и отсутствием желания поднимать всю базу данных у себя. А так часто глючит именно в "этой статье" и с таким расположением звёзд :)
кстати говоря, GAE дает отличную возможность тестировать на "staging" сервере. Это когда у вас два GAE приложения. Одно такое все платное (в смысле, не помещающееся в бесплатные квоты) и открытое для других пользователей. А другое такое бесплатное, закрытое и куда сначала вливается версия и тестится на, например, кусочке snapshot-а основной базы недельной давности или просто на тестовой базе.

Не вижу никаких проблем, чтобы научить GAE показывать кнопочку в staging приложении: "скопироваться на production приложение"
И ещё в том питоне отсутствует возможность писать на файловую систему и использовать любые сетевые возможности (кроме запросов HTTP-страниц с удалённого сервера). (link)
не в "том питоне" - ибо звучит как прям нет в природе такого :) - а в API.

о ФС - вполне логично, раз строим распределенную систему - хранилище должно быть тоже распределенным. Зачем писать еще и ФС, если уже все вопросы решены на уровне базы? Да и гугл сам использует bigtable для хранения файлов, не жалуются.

и о сетевых возможностях - они полностью исчерпывающие для веб приложений. То есть, есть ВСЕ необходимые :) Или проблема в том, что нельзя написать распределенного спам бота?

право - аргументы не понятны, звучат больше как жалобы
В «том питоне» — точно не знаю, но, думается, что там немного видоизменённый питон.

Вообще я ни разу не жалуюсь, просто в топике с критическими заметками про App Engine хотелось бы дополнить картину, тем более, что указанные мной ограничения важны для моего проекта.
язык Python в GAE полный, стандартная библиотека урезана просто :)
а разве гугл не gfs использует? по-крайней мере bigtable построен на основе gfs точно.
в gfs удобно хранить только большие файлы, т.к. размер кластера там вроде 64 Мб. Т.е. даже текстовый документ на 2 Кб будет там занимать 64 Мб. А вот уже внутри bigtable вполне удобно хранить небольшие записи
НЛО прилетело и опубликовало эту надпись здесь
Пока не знаю, чего бы я хотел писать туда :) Вероятно, без этого нельзя сделать загрузку файлов на сервер через web-интерфейс?
храните файлы в БД. Какие проблемы? BigTable нормально относится к большому количеству данных. Даже хорошо, т.к. для этого она и сделана
загрузку файлов можно делать прямо в базу... опять проблема не понятна, почему без файлов нельзя сделать подгрузку? - явно ошибочное мнение.
в большинстве случаев жалобы "нет возможности писать в ФС", как я понимаю, относятся к переносу на GAE готового кода, который хочет по каким-то причинам писать в ФС. Тут можно только посоветовать впредь писать так, чтобы файловое хранилище легко заменялось чем-то другим
чего-то я нигде не встретил, как у них работать с сессиями? встроенного механизма нет (или есть?), а джанговские не работают.
храните состояние в DataStore, ключ храните в cookie.
НЛО прилетело и опубликовало эту надпись здесь
каким образом?
Буду Вам крайне признателен, уважаемый автор замечательной статьи, если Вы будете так любезны и немного обьясните, как можно более простым языком, что Вы понимаете под:

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

Или просто примеры для чего подходит а для чего нет. Заранее благодарен.
не автор статьи, но попробую пояснить. База данных, используемая в GAE, относительно медленная для запросов, которые затрагивают сразу много записей. Зато она умеет достаточно быстро вытаскивать конкретные записи и скорость практически не падает при увеличении размера базы до терабайт.

Стандартные реляционные БД, вроде того же MySQL, позволяют достаточно быстро считать сложные запросы, в которых есть JOIN-ы или агрегаты вроде SUM(), COUNT() или MAX(). Но при увеличении размеров базы до неприличного, начинаются пляски с бубном.

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

То же самое про количество пользователей: если их мало, проще иметь сервер поближе к ним (например, сервер в Москве). Если их очень дофига, GAE позволяет не думать, где бы поставить 10-10000 компов и где нанять людей, которые будут бегать и обслуживать их. И тут уже не сильно переживаешь, что приложение хостится где-нибудь в Европе и это добавляет немножко к latency.
Если уж идти за совсем простыми примерами: bash.org.ru выиграет от размещения на GAE. Т.к. сложной работы с БД не содержит, зато куча пользователей и куча dos атак. GAE позволяет бороться с dos-ами. Как самый простой способ - просто отвечая на все запросы. Чуть сложнее - не очень тяжело показывать капчу наиболее активным ip-ам (не знаю, есть ли что-то там встроенное, но стороннее довольно быстро сделают)
вот, мне только так и понять: bash.org...

А вот хабр, например? Lenta.ru ...
на оба пункта - да, лягут. Но, если уж брать конкретно хабр и ленту - надо будет писать с нуля. Поэтому GAE скорее для новых ресурсов, чем существующих.
Спасибо за разьяснения.
Только надо понимать, что я не последняя инстанция и это просто мнение. :)
Если же приводить примеры, для чего не подходит/не удобно, так это либо сервера mmorpg (которые хранят свое состояние в памяти), либо meebo, который требует tcp-ip соединений.
Теперь я понял:
(если размеры базы > неприличного) and (пользователей > дофига) = Google App Engine :)
Но все равно спасибо.
спасибо от автора статьи за труд :)
>- завязка на Google Accounts
Это не совсем так. GAP даёт апи для работы с аккаунтами, но у разработчика остаётся выбор - можно использовать хоть OpenID.
Вы еще забыли упомянуть об ограничении в 500Мб на диске и 5 млн посетителей в месяц.
Кроме того результаты запросов ограничены 1 000 элементов.

А заказчики между тем ведутся :)
ну. Это же ограничения тестового периода. После его завершения, эти квоты будут для бесплатного аккаунта, а все что выше - будет оплачиваться. Чем это плохо-то?
о гуглакаунтах - я думаю подмечено верно,
лимиты посетителей/объемов - только для бесплатных тестовых аккаунтов, как бы упоминать про них в продакшине не имеет смысла. Ожидаем просто цены ниже 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…
вы имеете ввиду экспорт гугловых аккаунтов через OpenID-сервер (как здесь http://openid-provider.appspot.com/) ?
скорее он говорит об импорте. К GAE приложению можно легко прикрутить OpenID аутентификацию. Т.е. люди с OpenID смогут заходить к вам на сайт
именно так, однако никто не ограничивает нас только OpenID,
можно использовать хоть Facebook аккаунты или всё вместе.
Хотя ИМХО - Open Social перспективнее.
НЛО прилетело и опубликовало эту надпись здесь
боюсь что попытка реализовать pure python Imaging Library и заставить её работать на GAE упрётся в ограничение по времени на один запрос для большинства реальных применений. Разве что капчи делать.

И, кстати, я один расстроился что они в GAE не включили озможность пользоваться их map_reduce? (-:
может еще и включат. Т.к. они заявили, что работают над возможностью offline processing и их все очень просят это сделать через mapreduce. Думаю, они посмотрят на это все, и если в данном случае через mapreduce не будет означать через задницу, то будет доступен и mapreduce.
Объясните мне кто-нибуть, там вообще нет JOIN-ов?
Из официальной документации я не понял как можно выбрать, к примеру топ-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://code.google.com/appengine/docs/da…
проблем с выборкой всех книг не проблема - есть смещения в GQL:

[LIMIT [<offset>,]<count>]
[OFFSET <offset>]
это гуд, спасибо :)
Спасибо за ссылки.
Я там нашёл такой варриант:

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 выбирает одну из таблиц полностью - то есть уже не так страшно вынести пост-обработку на клиент, поток данных не упадет
Ну, что такое JOIN, я ещё помню )))
сижу жду инвайта, читаю пока группы и пишу мегакиллерсервис (привет, посмотреть профиль Vox!). группы веселые, мне понравился, например, топик "пожалуйста, не добавляйте поддержку никаких других языков!!!"
А мне вот прислали
я зарегался 8 апреля, в районе 18:00
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории