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:
- BLOB
- Stretta tabella
- 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 è:
- Utilizza molto meno spazio nel DB.
Gli svantaggi sono:
- Siamo limitati a ciò che possiamo fare, dal momento che ci sono alcune operazioni che dovrà elaborare i dati tra tutti gli utenti.
- Una piccola modifica causerà la riscrittura dell'intero BLOB e quindi il log di redo la crescita.
- Sarà difficile riadattare l'interfaccia utente esistente a questo modello in futuro
- 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:
- Una tabella stretta è adatta per un approccio colonnare in memoria
- Mantiene aperta la possibilità di rielaborare l'interfaccia utente per lavorare contro la nuova struttura della tabella
Gli svantaggi sono:
- Aumenta l'ordine di grandezza del numero di righe. Un singolo progetto finirà per avere 10000x50x200 righe, cioè 100 milioni di righe.
- 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
- Risolve il problema della memoria dell'applicazione con il minimo impatto di tutte e 3 le opzioni
- Utilizza il modello dati esistente
Inconvenienti
- Non elimina le colonne vuote nel DB. Ma penso che possiamo vivere con questo per ora.
- 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.