implementazione del gestore di query dinamico sui dati storici

Naviga le tue risposte
4

Contesto:

Ho dati storici sulle vendite di proprietà (casa) raccolte da varie fonti in un'origine dati centralizzata / cloud (supponiamo che la raccolta delle informazioni sia gestita da una terza parte)

Pianificazione dello sviluppo di un'applicazione per eseguire query e recuperare dati da questa origine dati centralizzata

Query di esempio:

Semplice : per un determinato codice postale XYZ, qual è il prezzo medio di una casa a 3 letti?

Complesso : qual è il prezzo stimato per una casa in "DD, Some Street, XYZ Post Code" (elaborato dai valori medi dei dati storici filtrati dalle varie caratteristiche della casa: codice postale di casa , no di camere da letto, area totale e altre intuizioni più profonde come tipo di edificio, anno di costruzione, caratteristiche)?

Oltre al prezzo medio, l'applicazione deve supportare altre informazioni sulla proprietà ** massimo, o prezzo minimo..etc e tendenza (grafico) su un attributo di proprietà selezionato per un periodo di tempo **. Quindi, le query non dovrebbero imporre la ricerca basata su una chiave primaria o su alcuni campi fissi

In altre parole, le query possono essere

Qual è il cambiamento del prezzo di una casa a 3 letti (indipendentemente dalla posizione) negli ultimi 30 giorni?

Che tipo di proprietà possiamo ottenere per il prezzo X (indipendentemente dalla località o dal tipo di casa)

La sfida che ho è identificare il dominio (BI / Data Analytical o DB Design o DB Query Interface o DW correlata o qualcos'altro) a cui appartiene questo problema (query dinamica su dati storici), così posso fare ulteriori esplorazioni

I miei risultati fino ad ora

Potrei sbagliarmi su quanto segue, quindi correggimi se la pensi così

Ho letto brevemente su BI / Data Analytics: penso che sia una soluzione pesante per il mio problema e abbia problemi di scalabilità.

Progettazione DB - Come ho capito RDBMS funziona bene se conosci il modello Data in fase di progettazione. Mi aspetto che gli attributi riguardanti la proprietà o l'altra entità (utente) che sto per introdurre, si evolvano rapidamente. quindi la manutenzione sarebbe un problema. Poiché avrò più utenti che eseguono query contemporaneamente, le prestazioni sarebbero un collo di bottiglia

Altre opzioni come il DB grafico ( link ) sembrano essere un po 'complesse (sono buone, ma usano quegli strumenti pensati per scopi generici , fammi pensare come programmazione di assiemi per risolvere il mio problema)

La soluzione correlata a BigData consiste nell'analizzare i dati da più domini non collegati

Quindi, Qualche suggerimento sullo spazio in cui si inserisce questo problema? (Specialmente se hai esperienza di progettazione / implementazione di back-end per l'elenco di proprietà o portali simili)

    
posta user2390183 04.03.2014 - 18:04
fonte

2 risposte

1

Dalla mia esperienza, il tuo problema principale è come consentire all'utente di specificare le query, piuttosto che il modello di dati, e quindi la relazione vecchia scuola potrebbe funzionare bene per te. Ecco perché.

Se stai prelevando dati da molte fonti diverse, finirai per metterli attraverso una sorta di interfaccia. Mentre lo fai, scoprirai un'interfaccia sottostante, il che significa che troverai il modo più appropriato per presentare i dati dalle varie fonti. (L'ho fatto in realtà con circa 12 banche diverse). Alcune delle fonti avranno dati aggiuntivi che non hanno contropartita nelle altre fonti, mentre altri avranno un modo idiosincratico di mostrare qualcosa. Ma alla fine, stabilirai qualcosa che copre la maggior parte dei tuoi casi d'uso. Questo ovviamente presuppone che ci sia un motivo per cui hai bisogno di un insieme misto di fonti.

L'interrogazione è un po 'difficile. Se gli utenti non dovrebbero imparare SQL, dovrai creare qualcosa che li limiti ma permetta la complessità che vuoi fornire.

Per quanto riguarda le prestazioni, non vedo che sia un grosso problema. Le persone alla ricerca di dati sui prezzi delle case stanno leggendo solo alcune righe storiche che non cambieranno, facilmente ridimensionabili in qualsiasi db moderno. Una delle principali complicazioni è se si dovesse provare a compilare i dati mancanti in base a una sorta di modello proxy. Quindi tutte le scommesse sono state annullate e le tue prestazioni dipenderanno dall'efficienza algo.

    
risposta data 03.08.2014 - 22:51
fonte
0

Penso che quello che sarebbe più utile per te sarebbe il Big Data come "dominio" per il problema che stai cercando di risolvere.

Se vuoi che le persone siano in grado di fare cose interessanti con i dati, sul web, allora vorrai un sistema a bassa latenza. Mentre ci sono molti approcci, una cosa che non credo che sarete in grado di evitare è il pre-calcolo di almeno un certo livello di rollup.

Usare qualcosa come Hadoop con Hbase e Pig è un approccio a cui mi sono appassionato di recente ... usando qualcosa come questo hai la possibilità di ricalcolare in modo rapido e relativamente facile le cose mentre raffini i tuoi requisiti dal tuo dati di origine originali. Se vai in questa direzione generale, ti consigliamo di leggere un po 'sulla progettazione efficace delle chiavi di riga in grandi archivi di chiavi / valori (ad es. Hbase, Cassandra).

    
risposta data 06.03.2014 - 15:43
fonte

Leggi altre domande sui tag

Progettazione della struttura dei dati del servizio di archiviazione per i modelli disaccoppiati che condividono gli stessi dati Memorizzazione di dati di grandi dimensioni nella sessione HTTP (applicazione Java)