2014-09-03 6 views
1

J'essaye d'implémenter un timeseries db pour stocker des compteurs simples en utilisant redis (et php, mais le langage ne devrait pas être pertinent je pense). Donc, j'ai mis mes clés de redis comme suit (simplifié):redis timeseries données et fuseaux horaires

someprefix: AAAA-MM-JJ: somecounter

Maintenant, quand je veux obtenir une série de données pour un intervalle spécifique que je reçois juste toutes les clés pour la gamme spécifique et tout fonctionne bien. (YYYY-MM-DD est la date que UTC)

Maintenant je veux mettre en application la capacité d'obtenir des données selon un certain fuseau horaire X. Ma question est: est-il possible que ce schéma de clé puisse être utilisé pour cela avec un degré de précision?

Je suppose que non, puisqu'il n'y a pas d'information de temps du tout, donc je devrai aussi ajouter au moins les heures et les minutes à la clé pour que la conversion de fuseau horaire fonctionne correctement. Je devrais probablement enregistrer les informations dans des intervalles de temps plus courts sinon, lors de la conversion des fuseaux horaires, je finirais par obtenir toutes les données pour un jour différent alors que la différence de fuseau horaire ne devrait pas dépasser 13h. ?

Serait-il plus approprié d'utiliser simplement des horodatages unix au lieu de la date formatée sur les clés redis? Par exemple, si je décide par la suite de stocker des données avec une plus petite précision, disons par heure ou par tranche de 10 minutes, quel serait un format de clé plus flexible?

J'espère avoir été en mesure d'expliquer correctement mon problème, mais n'hésitez pas à demander des éclaircissements.

Merci

Répondre

1

toujours bon d'aller avec époque (horodatage UNIX) lorsque vous avez à traiter avec le fuseau horaire.

Je suggérerais de timbrer timestamps pour encadrer les clés. Par exemple, un événement a eu lieu à l'horodatage 1409800502515 (Jeu, 4 septembre 2014 03:15:02 GMT), vous pourriez seau ce soit au niveau de l'heure ou le niveau de jour comme celui-

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

et les touches cadre comme

someprefix:1409800500000:somecounter OR 
someprefix:1409800464000:somecounter 

par exemple, pour le calcul des pages vues par heure, trouver le seau horaire approprié et incrémenter le compteur

mypage.html:1409800464000:page_views INCR 10 
+0

Merci pour la réponse John, mais à titre d'exemple, considérons le scénario suivant: Un client qui est sur un fuseau horaire différent (disons UTC +1), fait une demande de données de 2014-09-02 à 2014-09- 06 Mon système va convertir les dates que le client a fourni à l'UTC, donc après la conversion, j'ai 2014-09-01 23:00:00 à 2014-09-05 23:00:00 et je finirai par obtenir toutes les données pour le jour 1 quand en réalité je n'aurais besoin que d'une heure de ce jour. Donc ma question est: est-ce que la création d'un seau de temps par jour est vraiment utile dans ce cas? Et même si je ne fais que seau par heure, il y a des fuseaux horaires avec des décalages de 15 et 30m. – dev

0

tout d'abord, je ne sais pas comment vous faites « obtenir toutes les clés du rang spécifique e et tout cela fonctionne bien "mais si vous utilisez des clés un peu de préfixe: * notez que ce n'est pas une pratique recommandée pour la production. Envisagez d'utiliser la commande SCAN disponible à partir de la version 2.8.

Deuxièmement, vous pourriez envisager d'utiliser un ensemble ordonné pour le comptage. Ainsi, à la suite de votre convention, vous aurez une clé appelée someprefix:somecounter que vous aurez ZADDing aux membres avec l'époque comme score. Utilisez l'époque et la lecture du compteur comme un nom de membre unique (par exemple '1409800500000: 1' où 1409800500000 est l'époque et 1 est la valeur du compteur).

Notez que vous pouvez mesurer des résolutions temporelles d'années en microsecondes - tout dépend de la quantité de div appliquée à l'époque d'origine avant de définir le score.

+0

Bonjour Itamar. En ce moment, j'économise différents jours sur différentes clés comme je l'ai indiqué sur le post initial. Et non, n'utilisant pas la commande keys. Je parcours simplement toutes les clés dans l'intervalle demandé, donc si un client demande des données de 2014-09-01 à 2014-09-05, j'utilise simplement une boucle dans le code pour obtenir toutes les clés pour ces dates et créer un tableau qui ressemble à quelque chose comme "jour => compteur" qui à son tour est utilisé pour remplir un graphique. La question importante est de savoir comment stocker les dates dans redis afin que je puisse rapidement effectuer la conversion de fuseau horaire et retourner la gamme pertinente dans le tz du client. – dev

Questions connexes