Pull to refresh

Comments 20

Замечание: в 1.4.2 уже по-идее будет доступ на запись к blobstore. Эта возможность понадобилась в первую очередь разработчикам MapReduce для реализации Reduce-фазы. Инфа отсюда.
Постараюсь поддерживать информацию в актуальном состоянии, если дадут возможность записи — исправлю.
ну наконец-то будет нормальный map-reduce!

тот ужас на крыльях ночиjson в датасторе как-то не внушает.
«Специально обученное описание datastore...» — это как?
Это красивое бессмысленное словосочетание, воспринимайте приведённое описание как обычное.
На основе BigTable сделано хранилище datastore. Здесь Вы можете найти более подробную информацию о нём.
datastore — это и есть bigtable.
а 'fusion tables' — вобще отдельный сервис.
Кто знает, как эффективно использовать datastore для хранения и доступа геоданных? Вроде ничего сложного, но нельзя сделать запрос с условием неравенства по двум полям, что не позволяет одним запросом сравнить две геоточки.
Есть несколько библиотек позволяющих это делать. Я пишу

code.google.com/p/geotiles/

Там в конце страницы даны ссылки на аналогичные подходы.
Супер, буду постигать алгоритмы geohash и geocell. А по производительности на gae как они?
Количественно сказать не могу, но по ощущениям тех демо, что я видел, вполне сравнимо с другими сервисами.

На собственном опыте могу сказать, что если используются Google Maps и маркеров много (>100-200), то проблема может быть не в сервере (gae и т.п.) а в клиентской части — тогда надо кластеризовать маркеры.
В недостатки URLFetch я бы еще записал, что каждый вызов потребляет в среднем почти секунду процессорного времени. Да и максимальный объем может быть ограничен временем запроса — раньше было 10 секунд, но сейчас вроде увеличили немного.
Может быть Вы имеете в виду что запрос выполняется секунду? Процессорное время в таких количествах URLFetch не потребляет. Цифры с работающего приложения — запрос хабраленты, её парсинг с добавлением в очередь отсутствующих хаписей, либо получение записей и занесение в базу в среднем потребляет 418 cpu_ms (из них 249 api_cpu). Время выполнения при этом находится в пределах 0.3..4с.
Ой да, наврал ;( У меня просто мониторятся 6 сайтов приложением на appengine, и вот запросы их всех по очереди все вместе съедают секунду cpu. Я просто забыл, что сайтов-то 6, а не один.

Хотя, мне кажется, что 0.2 сек cpu — это тоже странно много для такой элементарной операции.
Классная статья, но очень не хватает графиков реальных тестов. Очень интересно сколько на практике занимает обработка запросов к различного рода хранилищам данных в Google App Engine.
Планирую сравнить первые 3 метода с использованием различных методов сжатия, возможно как-нибудь доберусь до этого и оформлю пост.
Дополню про URLfetch — квоты на данный ресурс возрастают на порядки при включенным биллинге: до 46 миллионов запросов в сутки.
В эти квоты довольно сложно упереться — трафик кончится быстрее. Даже чтоб использовать 657К запросов с выключенным биллингом и не упереться в 1Гб надо, чтоб на запрос уходило менее 1.5Кб трафика — при таких объёмах большинство других способов подойдёт гораздо лучше.
Спасибо за статью, жалко что ты ее написал не месяц назад, я бывший php кодер решил сделать приложение для контакта для работы с твиттером на gae, после того как закончил разработку и отладил локально я выкатил его и был сильно удивлен когда в моем твиттере стали появляться неведомые записи типа «Приложение прикольное но как оно работает».

я долго разбирался в чем дело, оказалось со своей инерцией мышления даже не удосужился разобраться о времени жизни объектов в gae, я то думал они там живут от реквеста до риспонса и кешировал токен авторизации пользователя для твиттера в памяти внутри объекта который инициализировался по типу Singelton!!! Естественно все пользователи заходили с моего аккаута, потом конечно я заменил кеш на хеш мап —

но был epic fail!!! Еще раз спасибо за статью!
Sign up to leave a comment.

Articles