Получить и перебрать большой набор данных, что в порядке? И почему разница в админ-логе / аппстасе?

Question

При попытке оптимизировать запрос для получения записей магазина в зависимости от местоположения я добавил что-то странное (я думаю), получение большого набора данных занимает ОДНО процессорное время.

В основном у меня> 1000 записей, которыеМне нужно выполнить итерацию, чтобы найти магазины на расстоянии 3000 м от позиции пользователя, и я получил довольно большие цифры в консоли администратора.

Это привело к некоторому тестированию хранилища данных, которое привело к некоторым интересным числам для получения 1000 записей.

У меня есть 6 методов тестирования, которые я запускал отдельно и взял время процессора из консоли администратора и приложений, и это привело к (в производстве):

    r = db.GqlQuery("SELECT __key__ FROM StoreRecords").fetch(1000)
    # appstats: real=120ms cpu=182ms api=845ms
    # admin console: 459ms 1040cpu_ms 845api_cpu_ms

    r = db.GqlQuery("SELECT __key__ FROM StoreRecords").fetch(100)
    # appstats: real=21ms cpu=45ms api=95ms
    # admin console: 322ms 134cpu_ms 95api_cpu_ms

    r = db.GqlQuery("SELECT * FROM StoreRecords").fetch(1000)
    # appstats: real=1208ms cpu=1979ms api=9179ms
    # admin console: 1233ms 10054cpu_ms 9179api_cpu_ms

    r = db.GqlQuery("SELECT * FROM StoreRecords").fetch(100)
    # appstats: real=57ms cpu=82ms api=929ms
    # admin console: 81ms 1006cpu_ms 929api_cpu_ms

    r = model.StoreRecords.all().fetch(1000)
    # appstats: real=869ms cpu=1526ms api=9179ms
    # admin console: 1061ms 9956cpu_ms 9179api_cpu_ms

    r = model.StoreRecords.all().fetch(100)
    # appstats: real=74ms cpu=86ms api=929ms
    # admin console: 97ms 1025cpu_ms 929api_cpu_ms

Здесь я беру толькосамое большее 1000 записей, но нужно будет выбрать все (около 4-5000).

Мои вопросы:

1. Если выборка 1000 записей действительно займет почти 20 (10054cpu_ms + 9179api_cpu_ms) секунд?
2. Почему существуют различия между временем appstas и консоли администратора?Что рассчитывается по моей квоте?

Можно легко обойти это, отправив извлеченные записи в memcache в качестве протобуфа.Но меня интересует интенсивное использование и различия во времени между appstas и консолью администратора.

Бонусный вопрос : Почему при извлечении 1000 записей всегда 9179api_cpu_ms

Answer 1

Почему удивительно, что для извлечения большого количества записей требуется много ресурсов? Это процесс O (n), и вы действительно не должны делать это на основе запроса. Чтобы ответить на ваши вопросы по порядку:

1. Сколько процессорного времени он использует, зависит от характера записей, но этот результат неудивителен. Обратите внимание, что это почти 20 CPU секунд, а не секундных часов. Также обратите внимание, что когда новая модель биллинга будет запущена, с вас будет взиматься плата за операции хранилища данных и часы работы экземпляра, и это именно то, что вы должны оптимизировать.
2. Консоль администратора показывает достоверные цифры, на основе которых выставлен счет. Показатели appstats ниже, поскольку они учитывают только время, потраченное на вызовы API, а не время, потраченное на выполнение вашего собственного кода.

Если ваш набор записей небольшой и довольно статичный, вы должны кэшировать их в памяти экземпляра, а не извлекать их каждый раз или сохранять в memcache. Если они больше и динамичнее, вам следует использовать что-то вроде GeoModel, чтобы вы могли выполнять географические запросы и извлекать только соответствующие записи.

Выборка 1000 записей всегда занимает одинаковое количество процессорного времени API, потому что именно так отражаются затраты на доступ к хранилищу данных - на самом деле это не время. Новая модель исправляет это, разбивая его на отдельные оплачиваемые операции.