Rapporti "OEM incorporato" vs "Sviluppato internamente"

-1

Stiamo sviluppando un prodotto SaaS con il quale vogliamo offrire ai nostri clienti la possibilità di produrre report in tempo reale (ovvero gli utenti dovrebbero essere in grado di ottenere risposte in pochi secondi). I dati "grezzi" (cioè non specificamente materializzati per la segnalazione) sono in MongoDB ei nostri client front-end possono essere nativi per dispositivi mobili e Web. La domanda è come otteniamo la funzionalità tra queste componenti che è quella di incorporare nelle nostre applicazioni un rapporto visivo generato dai dati MongoDB. Come lo vediamo, ci sono due opzioni in generale:

  1. Prenditi cura di tutto lo stack sviluppando "in house" e utilizzando le librerie per livelli specifici (ad esempio generazione dell'interfaccia utente, consumo di dati, ecc.)
  2. Utilizza servizi di reporting incorporabili OEM che possono essere forniti da terze parti come specificato qui . Come nota a margine, pensiamo che il termine "analytics" sia un superamento di ciò che vogliamo, ecco perché uso qui il termine "Reports". Tuttavia, tutti i prodotti utilizzano il termine "analytics"

Abbiamo bisogno di aiuto per scegliere tra gli approcci. Più in particolare:

  • Quanto è comune la seconda opzione? Soprattutto con Document DB come MongoDB?
  • Quali sono i criteri che possono aiutare a prendere una decisione qui? IOW, quali sono le condizioni in cui l'opzione (1) può essere considerata come preferita su (2) e viceversa?
posta Elad 06.12.2016 - 13:07
fonte

1 risposta

0

La risposta dipende in realtà dalle esigenze della tua applicazione e non esiste una soluzione per proiettili d'argento qui.

Esempio: se i tuoi report contengono molti dati aggregativi, ad esempio, probabilmente usando mongo sarebbe una sfida, sebbene abbiano un framework di aggregazione, ma a seconda delle dimensioni dei dati non sarà in grado di procedere entro secondi o due .

Un altro aspetto è quanto molti / quanto frequenti saranno generati i rapporti. Poiché mongo viene utilizzato come livello di persistenza principale, l'aggiunta di una quantità significativa di flussi di generazione di report (in genere questo si traduce in molte query "pesanti") può rallentare i flussi aziendali principali semplicemente perché monog lavorerà di più.

Per questo ci sono soluzioni NoSQL dedicate, a seconda delle tue esigenze / budget puoi scegliere le soluzioni Casandra o Vertica.

D'altra parte, se hai qualcosa di abbastanza semplice puoi iniziare con OEM e vedere se questo è adatto alle tue esigenze, e poi se riconosci che non è abbastanza buono, usa la tua soluzione.

Spero che questo aiuti

    
risposta data 25.12.2016 - 07:56
fonte