Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Вы google translate'ом переводили?
+1!
Еще не понятно как вот эта длинная тяга будет двигаться, когда маховик (большое колесо) повернется на 90гр по часовой :D отломится об корпус наверное. Эх гугл гугл…
Еще не понятно как вот эта длинная тяга будет двигаться, когда маховик (большое колесо) повернется на 90гр по часовой :D отломится об корпус наверное. Эх гугл гугл…
Чо вы расстраиваетесь? Может это передний фасад робота: глазки и носик, нижняя челюсть потеряна. Или проекция уплощена, там за шестернями китайцы сидят и еще зубчатых колес сотня. Смеситель для горячей и… желтой воды.
Эх, не люблю символизм и не могу сказать что-то плохо об App Engine, но логотип как-бы намекает…
И вот вам штраф за низкую загрузку процессора!
Главное, чтобы осталась возможность мелкие приложения держать у них бесплатно.
Пощелкал на калькуляторе, цены стали дороже, но незначительно. Не вижу повода для паники.
Имхо, GAE — это всё еще экзотика, и нужно уметь его готовить. Если ваше приложение регулярно срывает все квоты, есть повод пересмотреть не только его код, но и всю архитектуру.
Имхо, GAE — это всё еще экзотика, и нужно уметь его готовить. Если ваше приложение регулярно срывает все квоты, есть повод пересмотреть не только его код, но и всю архитектуру.
Для моего приложения прогноз — в 30 раз подорожание. Это с учетом скидки 50% до 20 ноября. После — по моим расчетам в 50 раз. Так все-таки делать очень плохо.
В селе паника:
Вот что хотел написать-то:
«Сегодня plusfeed.appspot.com прислал письмо, что в связи с повышением цен на GoogleApps они закрываются.»
«Сегодня plusfeed.appspot.com прислал письмо, что в связи с повышением цен на GoogleApps они закрываются.»
Спасибо за перевод.
Только я не понял — нужно количество индексов уменьшить или их размер? Одно другому, как бы, противорчечит.
Только я не понял — нужно количество индексов уменьшить или их размер? Одно другому, как бы, противорчечит.
Размер одного отдельно взятого индекса целиком и полностью контролируется гуглом и у приложения нет возможности влиять на него. Здесь речь о том, что каждый индекс занимает дополнительное место.
Хранилище AE работает только по ключам, и индексы, по сути, являются костылём. Грубо говоря, индексы на одну модель — это отдельный объект в datastore со списком ключей объектов. Когда приложение делает запрос, сначала запрашивается по своему ключу объект индекса со списком ключей всех нужных записей, а потом все эти объекты берутся по ключам. Поэтому запросы только ключей выполняются заметно быстрее.
Например, если есть модель с 5-ю индексируемыми полями, то AE будет автоматически создавать 5 списков ключей, плюс индексы для сложных запросов, прописанные в index.yaml. И всё это хозяйство будет занимать место на диске. Причём этого места может требоваться очень дофига. У меня было не взлетевшее на старом прайсе небольшое приложение для сбора статистики — порядка 250К записей, в которых было около 12 индексируемых значений и не было сложных индексов. На 200Мб данных приходилось 800Мб индексов.
Оптимизация довольно простая — прописывать indexed=False где это возможно и не делать лишних сложных индексов. Могу показать на примере хабраподобных комментарев. Для RSS необходимо цеплять 20 последних комментариев топика, а для отображения на сайте нужно брать все в порядке возрастания. Можно вместо 2-х индексов (по возрастанию и убыванию времени комментария) пользоваться только индексом по убыванию — так как для отображения берутся все комментарии, можно взять их из datastore по убыванию, вознользовавшись «индексом для RSS» и просто развернуть массив в коде приложения.
Хранилище AE работает только по ключам, и индексы, по сути, являются костылём. Грубо говоря, индексы на одну модель — это отдельный объект в datastore со списком ключей объектов. Когда приложение делает запрос, сначала запрашивается по своему ключу объект индекса со списком ключей всех нужных записей, а потом все эти объекты берутся по ключам. Поэтому запросы только ключей выполняются заметно быстрее.
Например, если есть модель с 5-ю индексируемыми полями, то AE будет автоматически создавать 5 списков ключей, плюс индексы для сложных запросов, прописанные в index.yaml. И всё это хозяйство будет занимать место на диске. Причём этого места может требоваться очень дофига. У меня было не взлетевшее на старом прайсе небольшое приложение для сбора статистики — порядка 250К записей, в которых было около 12 индексируемых значений и не было сложных индексов. На 200Мб данных приходилось 800Мб индексов.
Оптимизация довольно простая — прописывать indexed=False где это возможно и не делать лишних сложных индексов. Могу показать на примере хабраподобных комментарев. Для RSS необходимо цеплять 20 последних комментариев топика, а для отображения на сайте нужно брать все в порядке возрастания. Можно вместо 2-х индексов (по возрастанию и убыванию времени комментария) пользоваться только индексом по убыванию — так как для отображения берутся все комментарии, можно взять их из datastore по убыванию, вознользовавшись «индексом для RSS» и просто развернуть массив в коде приложения.
Совершенно верно.
Получение по ключам или имени ключей — гораздо быстрее.
Я иногда пользуюсь таким способом — формирую имя ключа из нескольких параметров, например, key_name = foo + "|" + bar + "|" + baz
И когда нужно получить объект с полями foo = «a», bar = «b», baz= «c», формирую имя ключа и получаю через get_by_key_name.
Получение по ключам или имени ключей — гораздо быстрее.
Я иногда пользуюсь таким способом — формирую имя ключа из нескольких параметров, например, key_name = foo + "|" + bar + "|" + baz
И когда нужно получить объект с полями foo = «a», bar = «b», baz= «c», формирую имя ключа и получаю через get_by_key_name.
Я всё же немного о другом говорил — не о получении объектов по ключам, а о получении ключей по запросам. Это использование keys_only в model.all() или начало GqlQuery с "
Это может быть полезно, когда значения остальных параметров объектов не имеют значения. Например, когда надо удалить истекшие сессии:
При использовании keys_only=True функция fetch вернёт не список объектов, а список их ключей. Datastore отработает быстрее за счёт того, что не надо получать все объекты, а приложению надо будет переваривать меньший объём данных.
SELECT __key__ FROM model".Это может быть полезно, когда значения остальных параметров объектов не имеют значения. Например, когда надо удалить истекшие сессии:
db.delete(sessions_model.all(keys_only=True).filter('last_activity <', datetime.datetime.now() - expiration_time).fetch(400))При использовании keys_only=True функция fetch вернёт не список объектов, а список их ключей. Datastore отработает быстрее за счёт того, что не надо получать все объекты, а приложению надо будет переваривать меньший объём данных.
Если не секрет — чем занимается приложение? Что-то из разряда постоянно запущенных сервисов? Какие цифры могут быть, если «закрутить гайки» в настройках планировщика?
В некоторых случаях есть даже выгода — теперь можно спокойно грузить datastore задёшево. Если раньше 25К записей в день потребляли все 6,5 бесплатных часов CPU, то теперь большими пакетами можно насовать в разы больше. Соответственно, удалять большие объёмы теперь тоже дёшево и весело.
Но есть и большой перерасход для постоянно включенных экономных приложений. Теперь и мини-скрипт, занимающий менее 10Мб памяти и потребляющий минуты CPU в день будет считаться по времени работы инстансов по максимальной планке. То есть стоимость выполнения кода, оптимального для прошлого прайса, возрастает на порядки.
Плюс отвратные пограничные моменты. Надо отправить 101 email за день — плати $9 в месяц, надо 1.01 Гб места — плати $9 в месяц, и так далее. С blobstore вообще неведомая фигня — сейчас он работает только при включенном биллинге, а что будет потом не знает никто. Может быть, и за возможность закачки файлов придётся платить те же $9 в месяц.
Не паника, конечно. Но осадочек остаётся…
Но есть и большой перерасход для постоянно включенных экономных приложений. Теперь и мини-скрипт, занимающий менее 10Мб памяти и потребляющий минуты CPU в день будет считаться по времени работы инстансов по максимальной планке. То есть стоимость выполнения кода, оптимального для прошлого прайса, возрастает на порядки.
Плюс отвратные пограничные моменты. Надо отправить 101 email за день — плати $9 в месяц, надо 1.01 Гб места — плати $9 в месяц, и так далее. С blobstore вообще неведомая фигня — сейчас он работает только при включенном биллинге, а что будет потом не знает никто. Может быть, и за возможность закачки файлов придётся платить те же $9 в месяц.
Не паника, конечно. Но осадочек остаётся…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация под новый прайс