Devo utilizzare BLOB o tabelle per archiviare dati di grandi dimensioni?

3

problema

Attualmente stiamo studiando una soluzione per migliorare le prestazioni di un'applicazione web. L'applicazione funziona bene per piccoli progetti, ma affronta problemi di prestazioni nell'interfaccia utente quando si lavora con progetti di grandi dimensioni.

Il caso d'uso è il seguente:

Un utente deve inviare un documento Excel che contiene 10000 elementi pubblicitari. Ogni elemento pubblicitario contiene circa 50 termini e ogni termine può avere uno o più attributi. Il sistema dovrebbe supportare un progetto in grado di gestire 200 utenti che caricano tali documenti. È possibile che contemporaneamente un massimo di 10 utenti sia attivo. Ci possono essere più progetti di questo tipo.

Il database attualmente utilizzato è Oracle. Dobbiamo anche assicurarci che la soluzione scelta funzioni bene con un RDBMS colonnare in memoria.

La funzionalità esistente funziona bene per piccoli progetti che hanno sia un'interfaccia web sia un'interfaccia excel. Ma l'interfaccia utente web presenta problemi di prestazioni con progetti di grandi dimensioni e ci baseremo esclusivamente su un'interfaccia di Excel.

Le operazioni sui dati riguardano upload / importazione, download / esportazione, modifica e report.

Tutte le azioni devono essere transazionali, poiché ci sono altri aggiornamenti all'interno dell'RDBMS che si verificano durante il caricamento. Quindi questo non può essere inserito in un'origine dati non transazionale. Esiste almeno una operazione principale in cui è necessario caricare tutti i dati. Questa operazione può essere eseguita in modo asincrono.

Soluzione esistente

La nostra soluzione esistente che funziona su tomcat e Oracle utilizza tabelle ampie. Questa soluzione funziona bene fino a 1000 elementi pubblicitari e presenta quindi problemi di prestazioni sul server delle applicazioni. I problemi di prestazioni si riferiscono all'idratazione degli oggetti java e causano problemi di memoria sul server delle applicazioni. Questo perché la tabella estesa ha un numero elevato di colonne Null e gli oggetti Java creati sono grandi a causa di un numero elevato di campi vuoti.

Opzioni

Per gestire un numero maggiore di elementi pubblicitari è necessario ridurre l'ingombro di memoria della soluzione esistente. Stiamo cercando di decidere tra i seguenti approcci:

  1. BLOB
  2. Stretta tabella
  3. Oggetto Java ridisegnato (nuovo)

Soluzione BLOB

Un modo per evitare i valori nulli consiste nel trasformare il documento excel in un formato di valore chiave conciso che può essere compresso e archiviato nel database come BLOB per utente. Il vantaggio di questo approccio è:

  1. Utilizza molto meno spazio nel DB.

Gli svantaggi sono:

  1. Siamo limitati a ciò che possiamo fare, dal momento che ci sono alcune operazioni che dovrà elaborare i dati tra tutti gli utenti.
  2. Una piccola modifica causerà la riscrittura dell'intero BLOB e quindi il log di redo la crescita.
  3. Sarà difficile riadattare l'interfaccia utente esistente a questo modello in futuro
  4. Gestisci un nuovo modello per progetti di grandi dimensioni

Stretta tabella

Questo approccio risolve i valori nulli disponendo di alcuni campi con una riga per ogni termine. Il numero di colonne Null è ridotto drasticamente. Gli oggetti java idratati da queste righe non hanno campi vuoti e possono essere di piccole dimensioni. Quindi il problema della memoria è alleviato.   I vantaggi sono:

  1. Una tabella stretta è adatta per un approccio colonnare in memoria
  2. Mantiene aperta la possibilità di rielaborare l'interfaccia utente per lavorare contro la nuova struttura della tabella

Gli svantaggi sono:

  1. Aumenta l'ordine di grandezza del numero di righe. Un singolo progetto finirà per avere 10000x50x200 righe, cioè 100 milioni di righe.
  2. Mantieni un nuovo modello poiché l'interfaccia utente non verrà toccata e verrà disattivata dal vecchio modello.

Classe java riprogettata

Inizialmente non avevo considerato questo approccio, ma sembra una buona opzione. Utilizziamo il modello dati esistente, ma rinnoviamo la nostra classe java supportata da una mappa. Solo i campi compilati sono contenuti in questa mappa. Questo evita di avere una classe con un gran numero di campi e quindi riduce l'ingombro della memoria per un oggetto scarsamente popolato.

Il vantaggio

  1. Risolve il problema della memoria dell'applicazione con il minimo impatto di tutte e 3 le opzioni
  2. Utilizza il modello dati esistente

Inconvenienti

  1. Non elimina le colonne vuote nel DB. Ma penso che possiamo vivere con questo per ora.
  2. Potrebbe non essere il miglior formato per un RDBMS in-memoria colonnare

Domanda

What is the best approach to take?

Aggiorna Mentre stavo chiarendo la descrizione, una potenziale terza opzione (Classe java ridisegnata) mi ha illuminato. Quindi ho intenzione di indagare ulteriormente come sembra promettente senza impatto del modello. Fammi sapere se questa non è una buona opzione in base al caso d'uso e se noti problemi con esso.

    
posta codedabbler 21.05.2015 - 01:25
fonte

5 risposte

4

The challenge is how should this information be stored efficiently in an RDBMS?

La domanda dovrebbe essere perché queste informazioni dovrebbero essere memorizzate in un RDBMS?

Che cosa hai intenzione di fare con esso una volta lì?

Se tutto ciò che devi fare è "salvare" un foglio di lavoro nel database e poi estrarlo nuovamente, quindi ti suggerirei di sprecare il tuo tempo. È un file; mettilo in un file system a cui appartiene e da dove puoi [molto più] facilmente recuperarlo.

Tuttavia ...

Se vuoi interrogare i dati "caricati" e "tagliarli e tagliarli", disegnando riepiloghi tra i dati caricati da molti utenti, allora il database è decisamente la strada da percorrere.

OK, le righe 100M sono molto ma con indicizzazione corretta (e partizionamento, se ne hai l'opzione), il tuo database lo gestirà.

    
risposta data 21.05.2015 - 13:18
fonte
2

Sì, la grande domanda è cosa vuoi fare con questi documenti Excel quando sono nel DB. Puoi memorizzarli come BLOB abbastanza volentieri, ma puoi anche archiviarli come file sul filesystem, e quest'ultimo ti consente di manipolare i documenti in vari modi (ad esempio, eseguendo il codice per cambiarli).

Se li stai solo archiviando per il recupero successivo, quindi memorizzali come BLOB. È possibile memorizzare ulteriori metadati relativi ai contenuti insieme al blob e questo è l'approccio che userei se fosse necessario eseguire query sui documenti.

Si noti che SQL Server 2012 ha la capacità di indicizzare i file archiviati in " filetables " che sono file / DB ibridi in modo da ottenere il vantaggio di entrambi.

    
risposta data 21.05.2015 - 16:50
fonte
0

Forse considera un approccio ibrido. Recupero e archiviazione di documenti è l'ambito dei database incentrati sui documenti o "NoSQL". Forse memorizza i fogli di calcolo effettivi in (ad esempio) Cassandra e conserva i tuoi metadati (e le copie di tutti i dati di lavoro, se ti interessa solo un sottoinsieme dei dati nel foglio di calcolo) in Oracle.

Per quanto riguarda la pressione della memoria in Tomcat, dai un'occhiata al modello di design Flyweight. Sostanzialmente ti consiglia di non creare oggetti per ogni bit di dati; invece, istanzia un oggetto solo quando hai bisogno dei dati. Ad esempio, invece di creare un oggetto con 10K righe composto da 50 elementi, crea solo il numero di righe necessario per l'operazione corrente, allo stesso modo degli oggetti. Ciò richiederà il mantenimento dei dati di supporto in una forma grezza (il foglio di calcolo di Excel) e solo l'istanziazione dei singoli valori quando richiesto.

    
risposta data 21.05.2015 - 17:59
fonte
0

Dipende da cosa intendi fare con il contenuto dei file.

Se hai bisogno di fare domande basate sul contenuto dei fogli (e sono abbastanza sicuro che dovrai farlo), penso davvero che dovresti prendere in considerazione la soluzione da tavolo. Penso che ci siano alcuni modi per migliorare i tuoi problemi di performance (inserimento batch ...).

    
risposta data 21.05.2015 - 18:11
fonte
0

Mentre stavo chiarendo la descrizione, una potenziale terza opzione (Classe java ridisegnata) mi ha illuminato. Quindi ho intenzione di indagare ulteriormente come sembra promettente senza impatto del modello. Fammi sapere se questa non è una buona opzione in base al caso d'uso e se noti problemi con esso.

    
risposta data 22.05.2015 - 00:21
fonte

Leggi altre domande sui tag