2010-08-06 5 views
7

Attualmente stiamo utilizzando una tabella di riepilogo che aggrega le informazioni per i nostri utenti su base oraria in ora UTC. Il problema che stiamo affrontando è che questo tavolo sta diventando troppo grande e rallenta immensamente il nostro sistema. Abbiamo fatto tutte le tecniche di ottimizzazione raccomandate per PostgreSQL e stiamo ancora vivendo la lentezza.Come faccio ad aggregare dati per giorno e rispettare il fuso orario?

La nostra idea era di iniziare l'aggregazione di giorno anziché per ora, ma il problema è che permettiamo ai nostri clienti di cambiare il fuso orario, che ricalcola i dati per quel giorno.

Qualcuno sa di un modo per archiviare il riepilogo giornaliero, ma rispettare comunque i numeri e i totali quando commutano i fusi orari?

+3

Stiamo parlando potenzialmente di tutti i fusi orari sulla Terra? – MPelletier

+1

In senso stretto per la modellazione dei dati, si perde il livello di dettaglio del fuso orario quando si passa alla granularità del giorno. Tuttavia, potresti essere in grado di aggregare per fuso orario, soprattutto se la risposta alla domanda di @ MPelletier è "No". – bobs

+0

@MPelletier ci aggiriamo ora per ora, quindi supportiamo solo fusi orari "all'ora" –

risposta

4

Riepilogare i dati nelle tabelle con una colonna di timeoffset e un campo "giorno" (una data) che è il giorno per quella particolare riga di riepilogo. Indice su (timeoffset, giorno, altri campi rilevanti), se possibile in cluster (presumibilmente PostgresSQL ha indici raggruppati?) E tutto dovrebbe andare bene.

+1

Quindi, invece di 24 linee al giorno, un giorno produrrebbe una linea ... volta 24 fusi orari. Non riesco a vedere un guadagno sostanziale qui. – MPelletier

+0

ho pensato a questo, ma poi devo mantenere 24 tabelle riassuntive che aumenteranno anche la possibilità di una differenza nel rapporto tra fusi orari. –

+2

@MPelletier - la differenza è che non è necessario aggregare le 24 linee per un giorno per produrre una cifra giornaliera - si estrae la riga di riepilogo per quel particolare intervallo di tempo/giorno - quindi stai facendo 1/24 di il lavoro - con indicizzazione corretta, naturalmente. –

0

Suppongo che tu abbia seguito tutte le considerazioni sul partizionamento, come il partizionamento per utente.

Sono in grado di vedere diverse soluzioni al problema, a seconda del modello di utilizzo.

  1. Dati aggregati al giorno, per selezione utente. In caso di modifica del fuso orario, ricalcolare programmaticamente l'aggregato per questo partner. Questo è plausibile se i cambiamenti del fuso orario sono rari e se un certo ritardo nei dati può essere introdotto quando un utente modifica i fusi orari.

  2. Se si dispone di un numero relativamente basso di misure, è possibile mantenere 24 colonne per ciascuna misura, ciascuna delle quali descrive l'aggregato giornaliero per la misura in un fuso orario diverso.

  3. Se i cambiamenti del fuso orario sono frequenti e vi sono numerose misure, sembra che 24 diversi tavoli aggregati siano la soluzione giusta.

+0

i cambiamenti del fuso orario sono, in effetti, relativamente pochi. Potrei ricalcolare programmaticamente le misure in base alla modifica, ma il primo cambiamento avrebbe un ritardo significativo. abbiamo circa 8 misure, 24 colonne per misura non sarebbe una buona idea. inizio a pensare che 24 tavoli siano la strada da percorrere. Ho esaminato la soluzione di @Will A e potrebbe essere valida con un db colonnare. ma non con un db che degrada con il numero di righe. –

+0

192 colonne intere non è male, in realtà. E se userete un DB colonnare, non credo che avrete bisogno di alcun cambiamento dello schema - almeno non con il problema di cui sopra in mente. – shmichael

0

Ho incontrato anche questo problema. Prendo questa soluzione: i dati con tipo di data utilizzano il fuso orario locale, gli altri dati con tipo datetime utilizzano il fuso orario UTC, perché l'indice delle statistiche è locale. Un'altra ragione è che ora abbiamo solo dati locali.