2012-05-10 20 views
19

Mi piace l'esperienza utente del cubismo e vorrei utilizzarlo su un back-end che abbiamo.Utilizzo di altre origini dati per cubism.js

Ho letto i documenti API e alcuni del codice, la maggior parte di questo sembra essere estratto. Come posso iniziare ad usare esattamente altre fonti di dati?

Ho un archivio dati di circa 6k singole macchine con precisione di 5 minuti su circa 100 statistiche.

Vorrei interrogare alcune app Web con un identificatore specifico per quella macchina e quindi eseguire il rendering di un dashboard simile al cubismo tramite l'interrogazione di un archivio dati specifico di mongo.

Scrivere la webapp o l'interrogazione su mongo non è un problema.

Il problema è più in linea con il fatto che il cubismo sembra richiedere l'interrogazione su qualsiasi archivio dati che si utilizza per ogni singolo punto dati (ad esempio si hanno 100 statistiche in una finestra di una settimana ... costose).

C'è un altro modo in cui posso sfruttare questo strumento per esaminare i dati che vengono caricati utilizzando qualcosa di simile al codice qui sotto?

var data = []; 
d3.json("/initial", function(json) { data.concat(json); }); 
d3.json("/update", function(json) { data.push(json); }); 

risposta

19

Cubismo si prende cura di inizializzazione e di aggiornamento per voi: la richiesta iniziale è la finestra visibile completo (iniziano a fermarsi, tipicamente 1.440 punti di dati), mentre le richieste successive sono solo per alcune metriche più recenti (7 Dati punti).

Dai uno sguardo allo context.metric per come implementare una nuova fonte di dati. Il più semplice implementazione possibile è come questo:

var foo = context.metric(function(start, stop, step, callback) { 
    d3.json("/data", function(data) { 
    if (!data) return callback(new Error("unable to load data")); 
    callback(null, data); 
    }); 
}); 

Si potrebbe estendere questo per cambiare l'URL "/ dati" a seconda dei casi, passando in avvio, arresto e tempi di passo, e qualsiasi altra cosa che si desidera utilizzare per identificare un metrica. Ad esempio, sia Cube che Graphite utilizzano un'espressione metrica come parametro di query aggiuntivo.

+0

solo assicurandosi, questo è inteso per ogni nuova metrica. Quindi ogni client collegato a questo farà x query al database per x metriche. Non c'è un modo semplice, usando ridurre questo usando il cubismo? ad esempio chiamare un grafico e avere una funzione di accesso? –

+1

Certo, potresti scrivere un'implementazione metrica alternativa che recupera più metriche in un batch, ma in genere non ne vale la pena. I nostri dashboard spesso fanno centinaia di richieste simultanee a Graphite (che vengono parzialmente serializzate dal browser, dal momento che non generano più di 4 o 8 richieste simultanee per host) e non ci sono problemi di prestazioni. Per unire le richieste simultanee, inserire più richieste in una coda e utilizzare un timeout per creare una richiesta combinata. – mbostock

+0

Solo per eseguirlo da qualcun altro che ha esperienza in quest'area, dimmi se pensi che ne valga la pena: ho circa 500 GB di dati su n macchine. Il db è indicizzato da timestamp, un id macchina e la combinazione dei due. Per fare una query (questo è MongoDB) ci vogliono circa 12 secondi per ottenere una lista ordinata di 1440 risultati per 1 macchina. Quindi x * 12 secondi = tempo di caricamento dove x è il numero di metriche. –

Problemi correlati