Оценка количества результатов в Google App Engine Query

Question

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

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

 
* 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 не распределяет числа, достаточно равномерно для этой цели?

Спасибо!

Edit:

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

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

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

Answer 1

быстрой мысли:

1. Вы пробовали Datastore статистики API? Это может обеспечить быстрые и точные результаты, если вы не будете часто обновлять свои объекты. 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

Например:

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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