Комментарии 20
Замечание: в 1.4.2 уже по-идее будет доступ на запись к blobstore. Эта возможность понадобилась в первую очередь разработчикам MapReduce для реализации Reduce-фазы. Инфа отсюда.
«Специально обученное описание datastore...» — это как?
а как же BigTable?
На основе BigTable сделано хранилище datastore. Здесь Вы можете найти более подробную информацию о нём.
datastore — это и есть bigtable.
а 'fusion tables' — вобще отдельный сервис.
а 'fusion tables' — вобще отдельный сервис.
Кто знает, как эффективно использовать datastore для хранения и доступа геоданных? Вроде ничего сложного, но нельзя сделать запрос с условием неравенства по двум полям, что не позволяет одним запросом сравнить две геоточки.
Есть несколько библиотек позволяющих это делать. Я пишу
code.google.com/p/geotiles/
Там в конце страницы даны ссылки на аналогичные подходы.
code.google.com/p/geotiles/
Там в конце страницы даны ссылки на аналогичные подходы.
Супер, буду постигать алгоритмы geohash и geocell. А по производительности на gae как они?
Количественно сказать не могу, но по ощущениям тех демо, что я видел, вполне сравнимо с другими сервисами.
На собственном опыте могу сказать, что если используются Google Maps и маркеров много (>100-200), то проблема может быть не в сервере (gae и т.п.) а в клиентской части — тогда надо кластеризовать маркеры.
На собственном опыте могу сказать, что если используются Google Maps и маркеров много (>100-200), то проблема может быть не в сервере (gae и т.п.) а в клиентской части — тогда надо кластеризовать маркеры.
В недостатки URLFetch я бы еще записал, что каждый вызов потребляет в среднем почти секунду процессорного времени. Да и максимальный объем может быть ограничен временем запроса — раньше было 10 секунд, но сейчас вроде увеличили немного.
Может быть Вы имеете в виду что запрос выполняется секунду? Процессорное время в таких количествах URLFetch не потребляет. Цифры с работающего приложения — запрос хабраленты, её парсинг с добавлением в очередь отсутствующих хаписей, либо получение записей и занесение в базу в среднем потребляет 418 cpu_ms (из них 249 api_cpu). Время выполнения при этом находится в пределах 0.3..4с.
Классная статья, но очень не хватает графиков реальных тестов. Очень интересно сколько на практике занимает обработка запросов к различного рода хранилищам данных в Google App Engine.
Дополню про URLfetch — квоты на данный ресурс возрастают на порядки при включенным биллинге: до 46 миллионов запросов в сутки.
Спасибо за статью, жалко что ты ее написал не месяц назад, я бывший php кодер решил сделать приложение для контакта для работы с твиттером на gae, после того как закончил разработку и отладил локально я выкатил его и был сильно удивлен когда в моем твиттере стали появляться неведомые записи типа «Приложение прикольное но как оно работает».
я долго разбирался в чем дело, оказалось со своей инерцией мышления даже не удосужился разобраться о времени жизни объектов в gae, я то думал они там живут от реквеста до риспонса и кешировал токен авторизации пользователя для твиттера в памяти внутри объекта который инициализировался по типу Singelton!!! Естественно все пользователи заходили с моего аккаута, потом конечно я заменил кеш на хеш мап —
но был epic fail!!! Еще раз спасибо за статью!
я долго разбирался в чем дело, оказалось со своей инерцией мышления даже не удосужился разобраться о времени жизни объектов в gae, я то думал они там живут от реквеста до риспонса и кешировал токен авторизации пользователя для твиттера в памяти внутри объекта который инициализировался по типу Singelton!!! Естественно все пользователи заходили с моего аккаута, потом конечно я заменил кеш на хеш мап —
но был epic fail!!! Еще раз спасибо за статью!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хранение данных в Google App Engine