Оценка количества результатов в Google App Engine Query - PullRequest
4 голосов
/ 04 января 2012

Я пытаюсь оценить общее количество результатов для запросов ядра приложения, которые будут возвращать большое количество результатов.

Чтобы сделать это, я назначил случайное число с плавающей точкой от 0 до 1 для каждого объекта. Затем я выполнил запрос, для которого я хотел оценить итоговые результаты, со следующими тремя настройками:

 * I ordered by the random numbers that I had assigned in ascending order
 * I set the offset to 1000
 * I fetched only one entity

Затем я включил случайное значение сущностей, которое я назначил для этой цели, в следующее уравнение для оценки общих результатов (так как я использовал 1000 в качестве смещения выше, значение OFFSET в этом случае будет 1000):

1 / RANDOM * OFFSET

Идея состоит в том, что, поскольку каждому объекту назначено случайное число, и я сортирую по этому случайному числу, назначение случайного числа объекта должно быть пропорционально началу и концу результатов относительно его смещения (в этот случай 1000).

Проблема, с которой я сталкиваюсь, заключается в том, что полученные результаты дают мне низкие оценки. И оценки тем ниже, чем меньше смещение. Я ожидал, что чем меньше смещение, которое я использовал, тем менее точной должна быть оценка, но я думал, что предел погрешности будет как выше, так и ниже фактического числа результатов.

Ниже приведена таблица, демонстрирующая, о чем я говорю. Как вы можете видеть, прогнозы становятся более последовательными (точными) с увеличением смещения от 1000 до 5000. Но тогда предсказания, как и следовало ожидать, следуют полиному из 4 частей. (y = -5E-15x4 + 7E-10x3 - 3E-05x2 + 0,3781x + 51608).

Я здесь ошибаюсь, или стандартный генератор случайных чисел python не распределяет числа достаточно равномерно для этой цели?

Спасибо!

enter image description here

Edit:

Оказывается, эта проблема из-за моей ошибки. В другой части программы я собирал объекты с начала серии, выполнял операцию, а затем переназначал случайное число. Это привело к более плотному распределению случайных чисел к концу.

Я немного больше углубился в эту концепцию, устранил проблему и попробовал еще раз для другого запроса (поэтому число результатов отличается от приведенного выше). Я обнаружил, что эта идея может быть использована для оценки общих результатов для запроса. Следует отметить, что «ошибка» очень похожа на близкие смещения. Когда я делал точную диаграмму в Excel, я ожидал, что точность прогнозов при каждом смещении будет «облачной». Это означает, что смещения в самом начале будут производить более большое, менее плотное облако, которое будет сходиться к очень крошечной, плотной емкости вокруг фактического значения, когда смещения становятся больше. Это не то, что произошло, как вы можете видеть ниже в корзине того, как далеко были предсказания на каждом смещении. Там, где я думал, что будет облако точек, есть линия.

enter image description here

Это график максимума после каждого смещения. Например, максимальная ошибка для любого смещения после 10000 была менее 1%:

enter image description here

Ответы [ 3 ]

2 голосов
/ 04 января 2012

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

Если у вас есть стандартный запрос, это довольно просто - просто используйте sharded counter при создании сущностей.Вы можете получить это с помощью задания уменьшения карты, чтобы получить начальный счет.

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

Если диапазон возможных запросов бесконечен, вы можете подумать об агрегировании счетчиков или более творческом их использовании.

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

1 голос
/ 04 января 2012

Немного подумав:

  1. Вы пробовали API статистики Datastore?Это может обеспечить быстрые и точные результаты, если вы не будете часто обновлять набор объектов.http://code.google.com/appengine/docs/python/datastore/stats.html

    [EDIT1.]

  2. Я сделал некоторые математические вещи, я думаю, что метод оценки, который вы здесь определили, можно перефразировать как проблему «Статистика по заказам»,http://en.wikipedia.org/wiki/Order_statistic#The_order_statistics_of_the_uniform_distribution

Например:

Если фактическое число сущностей равно 60000, вопрос равен «какова вероятность того, что ваша 1000-я [2000-я, 3000-я, ....]выборка попадает в интервал [l, u], поэтому оценочное общее число объектов, основанное на этой выборке, будет иметь допустимую ошибку до 60000. "

Если допустимая ошибка составляет 5%, интервал [l, u] будет [0.015873015873015872, 0.017543859649122806] Я думаю, что вероятность не будет очень большой.

1 голос
/ 04 января 2012

Это напрямую не связано с аспектом вычислений вашего вопроса, но подойдет ли вам атрибут count объекта запроса? Или вы пробовали это, и оно не подходит? Согласно документам, это только немного быстрее, чем извлечение всех данных, но с положительной стороны это даст вам фактическое количество результатов.

http://code.google.com/appengine/docs/python/datastore/queryclass.html#Query_count

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...