Domanda

Stiamo lavorando su un progetto che sarà caratterizzato da statistiche in tempo reale di alcune azioni (ad esempio scatti). Su ogni clic, saremo registrare informazioni come la data, età e sesso (questi provengono da Facebook), posizione, ecc.

Stiamo discutendo circa il posto migliore per conservare queste informazioni e utilizzarle per statistiche in tempo reale. Ci mostrerà statistiche aggregate:., Ad esempio, il numero di clic, numero di click fatta da maschio / femmina, numero di clic diviso per fasce d'età (ad esempio 18-24, 24-30 ...)

Dal momento che sul sito che stiamo usando MongoDB ovunque, il mio collega pensato che dovremmo conservare le statistiche all'interno di esso pure. Io, invece, preferisco un database basato su SQL per questo compito, come MySQL (o forse Drizzle), perché credo SQL è meglio quando fa operazioni come aggregazione dei dati. Anche se c'è il sovraccarico di analisi del SQL, credo che MySQL / Drizzle potrebbe in realtà essere più veloce di database non-SQL qui. E inserti non sono troppo lento, quando si utilizza query INSERT DELAYED.

Si prega di notare che non abbiamo bisogno di eseguire ENTRA o Raccogliere i dati da più tabelle / collezioni. Così, non ci importa se il database è diverso. Tuttavia, si preoccupano di scalabilità e affidabilità. Stiamo costruendo qualcosa che (si spera) diventare molto grande, e abbiamo progettato ogni singola riga di codice con scalabilità in mente.

Cosa ne pensi di questo? C'è qualche motivo per preferire MongoDB su MySQL / Drizzle per questo? O è indifferente? Quale saresti usare, se ci fossi?

Grazie, Alessandro

È stato utile?

Soluzione

Quindi BuddyMedia sta usando una parte di questo. Il Gilt Groupe ha fatto qualcosa di piuttosto fresco con Hummingbird (node.js + MongoDB).

Dopo aver lavorato per un grande inserzionista on-line nello spazio Social Media, posso attestare che la segnalazione in tempo reale è davvero un dolore. Cercando di "roll-up" 500M impressioni al giorno è già una sfida, ma cercando di farlo in tempo reale ha funzionato, ma è effettuato alcune limitazioni significative. (Come in realtà è stato in ritardo di 5 minuti:)

Francamente, questo tipo di problema è uno dei motivi per cui ho iniziato ad usare MongoDB. E non sono l'unico. La gente sta usando MongoDB per tutti i tipi di analisi in tempo reale: , centralizzato di registrazione , nonché le notifiche alle dashboard.

La vera chiave quando si fa questo tipo di segnalazione è quello di capire che la struttura dei dati è completamente diverso con MongoDB, si sta andando ad evitare le query "aggregazione", in modo che le query e le tabelle di uscita stanno per essere diverso. C'è un po 'più di codifica lavori sul lato client.

Qui è la chiave che può puntare nella giusta direzione per fare questo con MongoDB. Date un'occhiata al seguente struttura dei dati:

{
  date: "20110430",
  gender: "M",
  age: 1, // 1 is probably a bucket
  impression_hour: [ 100, 50, ...], // 24 of these
  impression_minute: [ 2, 5, 19, 8, ... ], // 1440 of these
  clicks_hour: [ 10, 2, ... ],
  ...
}

Ci sono ovviamente alcune modifiche qui, gli indici appropriati, forse mushing dati + + genere di età in un _id. Ma questo è il tipo di struttura di base di click analytics con MongoDB. E 'davvero facile da aggiornare impressione e click { $inc : { clicks_hour.0 : 1 } }. Si arriva a aggiornare l'intero documento atomico. Ed è in realtà piuttosto naturale per riferire in merito. Hai già il tuo una matrice contenente i tuoi orarie o di livello minuti di punti di dati.

Si spera che è punti nella direzione giusta.

Altri suggerimenti

MongoDB è grande per questo genere di cose e sarà certamente più veloce di MySQL sarà, anche se non sottovalutare quanto potente MySQL può essere -. Molte aziende hanno costruito strumenti di analisi con esso

Date un'occhiata a questa presentazione di Patrick Stokes di BuddyMedia su come hanno usato MongoDB per il loro sistema analitico.

http://www.slideshare.net/pstokes2/social-analytics- con-MongoDB

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top