2014-09-03 2 views
1

Я пытаюсь реализовать deries таймера, чтобы хранить простые счетчики, используя redis (и php, но язык не должен быть релевантным, я думаю). Так что я реализовал свои ключи REDIS следующим образом (упрощенно):redis timeseries data и timezones

someprefix: YYYY-MM-DD: somecounter

Теперь, когда я хочу, чтобы получить диапазон данных для определенного интервала я просто получить все ключи для конкретного диапазона, и все это работает нормально. (ГГГГ-ММ-ДД - это дата в формате UTC)

Теперь я хочу реализовать возможность получения данных в соответствии с некоторым часовым поясом X. Мой вопрос: есть ли способ использовать эту ключевую схему для этого с помощью любой степени точности?

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

Было бы более целесообразным использовать временные метки unix вместо форматированной даты на клавишах redis? Например, если позже я решил хранить данные с меньшей точностью, скажем, в час или за каждые 10 минут, что было бы более гибким ключевым форматом?

Надеюсь, что я смог правильно объяснить свою проблему, но, пожалуйста, не стесняйтесь просить о каких-либо разъяснениях.

Благодаря

ответ

1

всегда хорошо идти с эпохой (UNIX метки времени), когда вам приходится иметь дело с часовым поясом.

Я бы предложил использовать временные метки для создания Ключей. Например событие произошло на метке времени 1409800502515 (Чты, 4 сентября 2014 3:15:02 GMT), вы могли бы ведро его на уровне часа или на уровне дня, как это

Hour bucket = 1409800502515 - (1409800502515 % (60 * 60)) = 1409800500000 
Day bucket = 1409800502515 - (1409800502515 % (24 * 60 * 60)) = 1409800464000 

и каркасные ключи как

someprefix:1409800500000:somecounter OR 
someprefix:1409800464000:somecounter 

Например, для вычисления просмотров страниц в час, найти подходящий почасовой ведро и увеличить счетчик

mypage.html:1409800464000:page_views INCR 10 
+0

Спасибо за ответ John, но в качестве примера рассмотрим следующий сценарий: Клиент, который находится в другом часовом поясе (например, UTC +1), выполняет запрос данных с 2014-09-02 по 2014-09- 06. Моя система преобразует даты, которые клиент предоставил в UTC, поэтому после конвертации у меня есть 2014-09-01 23:00:00 до 2014-09-05 23:00:00, и я получу все данные на 1-й день, когда на самом деле мне понадобится только 1 час с того дня. Итак, мой вопрос: создает ли время ведро в день действительно полезно в этом случае? И даже если я только ведро в час, есть часовые пояса с смещениями 15 и 30 м. – dev

0

Во-первых, я не знаю, как вы делаете «получить все ключи для конкретного звенел e, и все работает нормально », но если вы используете KEYS someprefix: * обратите внимание, что это не рекомендуется для производства. Подумайте об использовании команды SCAN, доступной из v2.8.

Во-вторых, вы можете рассмотреть возможность использования упорядоченного набора для подсчета. Итак, после вашего соглашения, у вас будет ключ с именем someprefix:somecounter, который вы будете ZADDing для членов с эпохой в качестве их оценки. Используйте имя эпохи и счетчика как уникальное имя участника (например, «1409800500000: 1», где 1409800500000 - это эпоха, а 1 - значение счетчика).

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

+0

Привет, Итамар. Прямо сейчас, я сохраняю разные дни на разных ключах, как я сказал на начальном посту. И нет, не используя команду keys. Я просто перебираю все ключи в запрошенном интервале, поэтому, если клиент запрашивает данные с 2014-09-01 по 2014-09-05, я просто использую цикл в коде, чтобы получить все ключи для этих дат и создать массив, который выглядит как «day => counter», который, в свою очередь, используется для заполнения графа. Важная проблема заключается в том, как сохранить даты в redis, чтобы я мог быстро выполнить изменение часового пояса на нем и вернуть соответствующий диапазон в tz клиента. – dev