Nous utilisons actuellement une table récapitulative qui graque des informations pour nos utilisateurs sur une base horaire de l'UTC. Le problème que nous rencontrons est que ce tableau devient trop volumineux et ralentit notre système immensément. Nous avons fait toutes les techniques de réglage recommandées pour PostgreSQL et nous vivons toujours de la lenteur.
Notre idée était de commencer à agréger la journée plutôt qu'à heure, mais le problème est que nous permettons à nos clients de changer le fuseau horaire, ce qui recalcule les données de ce jour.
Est-ce que quelqu'un connaît-il un moyen de stocker le résumé quotidien mais respecte toujours les chiffres et les totaux lorsqu'ils changent des trimestres?
4 Réponses :
Résumez les données des tables avec une colonne TimeOffset et un champ "jour" (une date) qui est le jour de cette ligne de résumé particulière. Index sur (timeoffset, jour, autres champs pertinents), regroupés si possible (probablement postgRessql contient des index clusters?) Et tout devrait être bien.
Ainsi, au lieu de 24 lignes par jour, une journée produirait une ligne ... Times 24 fuseaux horaires. Je ne peux pas voir un gain substantiel ici.
J'y ai pensé, mais je dois ensuite conserver 24 tables de synthèse qui augmenteront également la possibilité d'une différence de déclaration entre les fuseaux horaires.
@MPelletier - La différence est que vous n'avez pas besoin de regrouper les 24 lignes pendant une journée pour produire une silhouette quotidienne - vous retirez la ligne de résumé pour cette période de temps / jour, donc vous faites 1/24 de la travail - avec une indexation appropriée bien sûr.
@RUSS - Vous n'avez pas de tableaux récapitulatifs - juste celui-ci, mais avec une colonne TimeOffset qui indique le nombre d'heures de GMT, et la colonne Day indique la journée pour ce délai de compensation de temps. Vous auriez 24 lignes pour les offsets 24 fois (ou plus ou moins si vous avez besoin de plus ou moins de fuseaux horaires).
La table horaire a déjà plus de 10 millions de lignes, c'est pourquoi je crois que la performance est dégradante. Pas nécessairement dans le nombre de lignes qu'il doit s'aggraver, mais la quantité totale qu'il doit filtrer. Les indices se développent trop gros, je crois.
En outre, mon index en cluster est sur deux autres colonnes importantes et avec Postgres, vous n'obtenez-vous que un par table.
@Russ Bradberry: Pouvez-vous trouver la postgre avec des vues? Dites que vous indexez la journée, y a-t-il un gain pour une vue spécifique au fuseau horaire? Ou l'inverse: une requête imbriquée pendant des jours (indexées) dans une requête pour le fuseau horaire?
@WILL A, cela peut être viable avec une solution Columinar DB. Ive regarda dans un couple et il s'agit d'une surcharge initiale importante, elle peut s'avérer une bonne solution.
@Russ - Je ne pense pas que vous ayez besoin de vous soucier de votre indice en cluster existant - si vous ajoutez du temps de timeoffset et de la journée au début de cet index, vous en récolterez toujours le bénéfice de celui-ci et n'aura besoin que de Numérisez via les lignes appropriées - c'est l'approche «24 Tables» dans une table plus facile à maintenir. :) sera intéressé à entendre comment cela se passe.
Je suppose que vous avez traversé toutes les considérations de partitionnement, telles que la partition de l'utilisateur.
Je peux voir plusieurs solutions à votre problème, en fonction du modèle d'utilisation.
Données agrégées par jour, par sélection d'utilisateur. En cas de changement de fuseau horaire, recalculer par programme de manière programmée pour ce partenaire. Ceci est plausible si les changements de fuseau horaire sont peu fréquents et si un certain délai de données peut être introduit lorsqu'un utilisateur change de délaizones.
Si vous avez relativement peu de mesures, vous pouvez gérer 24 colonnes pour chaque mesure - chacune décrivant l'agrégat quotidien pour la mesure dans un fuseau horaire différent.
Si les changements de fuseau horaire sont fréquents et qu'il existe de nombreuses mesures, il semble que 24 tables d'agrégats différentes constitueraient la voie à suivre.
Les changements de fuseau horaire sont en fait relativement peu nombreux. Je pourrais recalculer par programme les mesures en fonction du changement, mais le premier changement aurait un retard important. Nous avons environ 8 mesures, 24 colonnes par mesure ne seraient pas une bonne idée. Je commence à penser que 24 tables sont la voie à suivre. J'ai regardé la solution de @will A et il peut être viable avec un dB colonnaire. Mais pas avec une DB qui se dégrade avec le nombre de lignes.
192 Les colonnes entières ne sont pas trop mauvaises, en fait. Et si vous utilisez un dB colonnaire, je ne pense pas que vous auriez besoin d'un changement de schéma, que ce soit - du moins pas avec le problème susmentionné à l'esprit.
J'ai aussi rencontré ce problème. Je prends cette solution: les données avec type de date utilisent des fuseaux horaires locaux, les autres données avec type DateTime Utiliser UTC TimeZone, car l'index de statistiques est local. Une autre raison est maintenant que nous n'avons que des données locales.
Je suis confronté au même problème. Je pense qu'à l'agrégation de la date et de l'heure (heure d'heure en UTC). Ensuite, vous pouvez récupérer des données en conséquence pour n'importe quel fuseau horaire que vous souhaitez. Malheureusement, cela ne fonctionnera pas si vous devez prendre en charge les fuseaux Timezones où il y a 35/30/15 minute de compensation. Ensuite, vous pouvez regrouper des données de 15 minutes. La solution dépend de la quantité de données à accrue.
Parlons-nous potentiellement tous les fuseaux horaires de la planète?
Strictement parlant pour la modélisation de données, vous perdez le niveau de détail de la fusée de fuseau horaire lorsque vous allez à la granularité de la journée. Mais vous pourrez peut-être regrouper par Timezone, surtout si la réponse à la question de @ Mpelletier est "non".
@MPelletier Nous nous sommes agrégés d'heure en ce moment, nous ne supportant donc que les fuseaux Timezones qui sont "à l'heure"
@bobs Il n'y a pas d'informations sur le fuseau horaire pour la ligne de données, c'est tout en UTC. Le changement vient lorsqu'un utilisateur souhaite voir à quel point ils ont fait à une certaine journée, dans un certain temps.
Pour préciser davantage, s'ils ont effectué une heure de 1 heure par heure (UTC) sur le 1er puis sur les 2e et 3e, ils ont effectué 2 heures par heure toutes les heures (UTC) s'ils considèrent le 2e dans l'Est, il devrait ajouter jusqu'à 20 $, et S'ils changent de fuseau horaire en UTC, il ajoutera jusqu'à 24 $