Database grafico che mantiene relazioni storiche

4

Sto iniziando la modellazione del seguente problema:

Ho molti clienti (milioni) che interagiscono in una rete formando un grafico. Alla massima granularità del mio problema aziendale, ogni realizzazioni ha 3 attributi.

Nello scenario peggiore "realistico", i nodi compongono una mesh univoca, con relazioni con ~ 100 altri nodi, ma con un aggravante: queste relazioni saranno spesso bidirezionali e dovrebbero anche essere suddivisi in base ai diversi valori possibili di uno dei 3 attributi (ovvero, la regione in cui opera il cliente). Questo mi porta al seguente dimensionamento:

2 directions * 6 regions * 100 nodes = 1200 edges per node

Diventa peggio. Uno dei requisiti è che questo database dovrebbe contenere una cronologia mensile degli ultimi 5 anni, nel caso in cui l'utente desideri rivedere un punteggio passato di uno qualsiasi dei nodi, il che significa che devo anche considerare 1 entrata al mese per nodo , dandomi il seguente dimensionamento:

2 directions * 6 regions * 100 nodes * 60 months = 72000 edges per node

Siamo propensi a utilizzare un database grafico per risolvere questo problema, ma la domanda è: è possibile farlo anche con le attuali tecnologie grafiche disponibili?

    
posta Henrique Barcelos 28.06.2016 - 16:19
fonte

2 risposte

2

Una volta ho risolto il problema della cronologia di un database semplicemente facendo copie di esso.

Ho fatto una copia del database ogni notte per una settimana. Ogni settimana per un mese. Ogni mese per un anno. E mantenuto i backup di ogni anno. Ha fatto tutto con una semplice sceneggiatura. Risolve il problema della cronologia, manteneva le dimensioni ragionevoli e manteneva pulito il database. Ovviamente questo comporta dei limiti, ma è un modo semplice per risolvere il requisito della cronologia considerandolo prima di sovradimensionare qualcosa di cui non hai veramente bisogno.

Il bello dell'approccio copy-the-DB, oltre a non essere enorme (66 volte + 1 all'anno), è che tutto è ancora collegato a ciò a cui era collegato quando aveva quel valore. Gli svantaggi sono: è lossy (i valori transitori possono essere persi) ed è isolato (non è possibile eseguire query che si uniscono al presente e al passato). Ci sono altri approcci ,

    
risposta data 28.06.2016 - 17:34
fonte
2

Il tuo problema dei dati storici è in effetti abbastanza comune: i dati relativi al business sono spesso correlati al tempo.

Approccio Snaphsot

Un modo per gestirlo è quello di scattare istantanee. È la soluzione proposta da @CandleOrange. Ma sembra anche essere la tua ipotesi: nel tuo dimensionamento ti aspetti di avere un evento diverso per ciascuna combinazione per ogni mese (completamente equivalente all'approccio istantaneo). Ma pensi di tenerlo nel database.

Ad esempio, un pacchetto software business leader gestisce le cifre di vendita in questo modo: per ogni mese, riassume le vendite di quel mese, per ogni combinazione di categoria di clienti, gruppo di prodotti e area geografica. In questo modo può produrre cifre di vendita in base ai criteri e per un determinato periodo di tempo, senza dover leggere milioni e milioni di transazioni sottostanti.

In effetti, qui non c'è differenza tra dati e dati storici. Dal punto di vista del business, il mese è parte integrante dei dati gestiti. Ed è frequente confrontare i dati di vendita di un anno rispetto all'anno precedente, ma anche di un mese al mese precedente o del primo trimestre di quest'anno con il primo trimestre dei 2 ultimi anni.

Data dell'approccio di validità (controllo delle versioni dipendente dal tempo)

Ma l'approccio dell'istantanea non sempre si adatta alle necessità. Molto spesso i dati possono dipendere dal tempo. Ad esempio, il venditore X può essere responsabile di una regione dal 1 ° marzo al 18 agosto e per un'altra regione dal 19 agosto ad oggi. Quindi quale regione si tiene per lui per agosto? Nessuno è più esatto dell'altro.

Per le relazioni grafiche è peggio. Perché ci sono aspetti dipendenti dal tempo in ogni dato e in ogni relazione. Facciamo un esempio: il manager A è responsabile del dipartimento X dal 20 gennaio al 20 settembre. Il dipendente B è assegnato al dipartimento X dall'anno scorso al 22 gennaio e il dipendente C viene assegnato a quel dipartimento da quando è entrato nell'azienda e si trova qui. Quindi chi gestisce il Manager A? Dipende completamente dalla data.

Ora, qual è la dimensione del database se si confronta l'approccio dipendente dal tempo e l'istantanea? Per l'istantanea devi clonare ogni valore rilevante ogni mese. Quindi per le 3 persone e 1 reparto del nostro esempio, avrai 36 record in un anno. E tu non sei ancora in grado di mantenere la piena verità. Per l'approccio dipendente dal tempo, hai i tuoi dati grezzi 3 record e hai solo dati aggiuntivi quando si verifica una modifica, quindi sei record in generale.

Il controllo delle versioni dei dati dipendente dal tempo rappresenta quindi molto accuratamente il mondo reale e lo spazio risparmiato. Ma rende la progettazione delle query molto più complessa.

Per evitare un incubo completo di query, è possibile lavorare per impostazione predefinita con la versione corrente di ciascun oggetto (ad esempio la validità finale è vuota) e creare cloni a tempo limitato (set di date di validità iniziale e finale) ogni volta che si modificano dati importanti. Dovresti quindi accedere a questi cloni e alle loro date di validità solo per la coppia di query dipendenti dal tempo che lo richiedono.

Supporto per sistemi di database

Per la maggior parte dei sistemi di database, devi prenderti cura degli aspetti dipendenti dal tempo. La dipendenza temporale degli elementi di dati deve essere identificata dall'inizio e si tratta di un lavoro di progettazione caso per caso.

Ma come già detto: è una sfida comune. Quindi fortunatamente c'è un po 'di supporto in giro:

risposta data 01.07.2016 - 01:02
fonte

Leggi altre domande sui tag