Структурные данные в приложении engine ndb и ускорении запроса

Question

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

Я могу представить два варианта сущности, но там может быть что-то намного лучше. Первым будет хранить почасовую температуру в индивидуальных свойствах:

class TempData(ndb.Model): 
    region = ndb.StringProperty() 
    date = ndb.DateProperty() 
    00:00 = ndb.FloatProperty() 
    01:00 = ndb.FloatProperty() 
    ... 
    23:00 = ndb.FloatProperty() 

Или я мог бы хранить данные

class TempData(ndb.Model): 
    region = ndb.StringProperty() 
    date = ndb.DateProperty() 
    time = ndb.TimeProperty() 
    temp = ndb.FloatProperty() 

(это может быть лучше, дату и время хранения в качестве одного свойства?)

Я хочу, чтобы иметь возможность запрашивать хранилище данных, чтобы рассчитать общую, максимальную, минимальную и среднюю температуру для любого заданного диапазона дат. В первом варианте я мог бы создать еще 4 свойства для эффективной предварительной обработки и хранения Total, Max и т. Д. Для каждого дня, поэтому, если бы я хотел запросить общую температуру в течение года, мне пришлось бы суммировать 365 значений, а не 8760 ? Я не уверен, как это сделать во втором варианте?

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

Благодаря

Пол

Answer 1

Лично я бы с вариантом первого подхода:

class TempData(ndb.Model): 
    region = ndb.StringProperty() 
    date = ndb.DateProperty() 
    temp = ndb.FloatProperty(repeated=True) 

используя temp список для хранения температуры от часа, чтобы, как вы узнаете о их. Я не думаю, что предварительная обработка per-date добавит что-то многое: чтобы вычислить все в течение года, вам все равно нужно будет избрать 365 объектов, и задержка для этого закроет крошечное количество времени, необходимое для подведения итогов тысячи номеров в любом случае.

В целом, предварительная обработка полезна, если вы хотите легко запросить новые поля, которые вы создаете с помощью такой обработки (например, быстро ответьте на вопрос «, в которых даты в локали X имели среднюю температуру более 20 градусов Цельсия»). Это не похоже на ваш прецедент.

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

Общая идея заключается в том, что минимизация количества объектов для извлечения является одной из самых важных оптимизаций; Разумеется, возможны и другие оптимизации, но они, как правило, играют вторую роль в этом :-).