Il modo migliore per accelerare l'accesso ai dati a due data warehouse?


9

Mi sto imbarcando in un progetto di business intelligence che richiederà astrarre l'accesso a due data warehouse esistenti. Devo progettare un'architettura applicativa per consentire alla business intelligence self-service di unire i dati e fornire un'unica vista sui due magazzini esistenti. Ho escogitato qualcosa del genere:

inserisci qui la descrizione dell'immagine

Sto lottando con il pezzo di virtualizzazione / memorizzazione nella cache e mi chiedo se ci sono modelli di progettazione aziendale per risolvere il mio problema. Un'architettura come questa funzionerebbe per astrarre schemi a stella nei data warehouse? Sto cercando prodotti come Red Hat JBoss Data Virtualization e Red Hat JBoss Data Grid (tra gli altri).

Attualmente non stiamo utilizzando Hibernate e la mia comprensione delle griglie dei dati è che si tratta di archivi di valori-chiave o archivi di oggetti e pertanto non idonei per la memorizzazione nella cache di un modello relazionale. Dovrei anche menzionare che siamo desiderosi di utilizzare i prodotti del fornitore per la parte Dashboard self-service, ma potremmo finire per fare un po 'di costruzione personalizzata in quest'area se i fornitori non possono offrirci tutto ciò che vogliamo.


2
Ho appena trovato questo libro, che potrebbe essere buono per me amazon.com/Data-Virtualization-Business-Intelligence-Systems/dp/…
Mark Allison

2
Non sono sicuro che tu abbia fornito informazioni sufficienti sul tuo progetto per consigliarti sull'architettura.
Vladislav Rastrusny l'

Perché i dati relazionali non possono essere memorizzati nella cache in un archivio valori-chiave come {key: pk, value: the_rest_of_the_row}? Probabilmente vorrai anche memorizzare nella cache i metadati.
9000,

2
Qual è il problema con l'approccio classico?
NoChance,

Risposte:


1

Non c'è una grande quantità di dettagli su ciò che stai cercando di ottenere qui, ma da quello che hai descritto, sembra che potresti fare con un data mart per sottrarre i repository principali ed esporre un sottoinsieme minimo di dati a servire l'applicazione.

Anche se è possibile progettare un livello applicazione decente, è probabile che si verifichino problemi di prestazioni a causa del caricamento su uno (o entrambi) dei database del repository. Il vantaggio dell'approccio mart è che il DB con cui l'applicazione parla è altamente performante. Gli aggiornamenti avvengono sui DB del repository dietro le quinte e vengono inviati su qualunque base riteniate appropriata.

Un ulteriore vantaggio che hai anche un solo fornitore di database da considerare nel tuo livello di applicazione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.