Sarebbe sbagliato usare un oggetto statico invece di un database?

Question

Questa è essenzialmente una domanda di modelli di progettazione:

Mi aspettavo di interrogare un database per ottenere un elenco di azioni (azioni/securites qualunque) che sono più altamente correlate per un dato stock.

Invece ho pensato che forse dovrei creare un oggetto che ha una HashMap statica e memorizzare i miei dati lì. Quindi "interrogalo" ogni volta che ne ho bisogno.

Ci sarebbe qualcosa di sbagliato in questo approccio, in quanto credo che migliorerebbe significativamente le prestazioni rispetto alle query su un database per gli stessi dati. La quantità di dati è relativamente piccola e non cresce così da non causare problemi. Potrebbero esserci problemi che mi morderanno più tardi?

Answer 1

Userei ancora il database per ragioni di backup, ma sul client utilizzo un caching api come oscache per archiviare i dati sul filesystem locale per un rapido accesso, quindi se il sistema va giù ripristinare la cache dal database e il continua ad usare la cache nel tuo codice

Answer 2

Non c'è niente di sbagliato in questo approccio in generale. Assicurati solo di non accedere direttamente alla tua classe statica, perché allora crei un "bad singleton". (Come una variabile globale)

Invece di introdurre una sorta di meccanismo di registrazione per registrare questa classe su tutti gli oggetti che lo interrogheranno. Allora avrai un "buon singleton" e non ci saranno problemi successivi.

public class MyDataClass { 
    private MyDataClass() { } 
    public static MyDataClass getInstance() { 
     if (instance == null) instance = new MyDataClass(); 
     return instance; 
    } 
    private static MyDataClass instance = null; 
} 

public class MyDataProcessor { 
    public void registerData(MyDataClass data) { 
     this.data = data; 
    } 
    public void process() { 
     assert(data != null); 
     data.getData(...); 
    } 
    private MyDataClass data; 
} 

Naturalmente questo approccio potrebbe avere alcuni problemi dopo tutto su uno strato di architettura quando si tratta di persistenza, la robustezza, ... Forse sarebbe meglio usare un database con un livello di cache, ma che dipende fortemente sulle reali esigenze degli utenti.

Answer 3

Il problema con il tuo approccio non sta avendo una separazione tra codice e dati.

che si traduce in alcuni svantaggi:

• non si può fare i backup
• si deve ricompilare/ridistribuire l'applicazione per modificare i dati

Come non sembrano avere bisogno di un database relazionale per questo, ti suggerisco di utilizzare un database di valori-chiave incorporato come BerkeleyDB, che è anche molto veloce.

Answer 4

I problemi che si otterranno sono se i dati cambiano ed è necessario aggiornare l'hash e ricompilare ogni volta.

Detto questo, conoscete i dati, potete dire quanto vi influenzerà.

Un'opzione potrebbe essere quella di mantenere i dati in un database, ma poi salvarli in una HashMap.

Answer 5

Normalmente ciò che ritorna e morde è l'assunto che qualcosa non cambierà mai. Quindi, se in seguito si ottengono requisiti che implicano l'aggiornamento dei valori, l'aggiunta di nuovi e l'accesso di più client ai dati se si utilizza già un database, si avrà meno lavoro. Invece fare un po 'di cache sul lato client per ottenere il potenziamento delle prestazioni. Solo il mio 2c.

Answer 6

Memorizza i dati in una HashMap se è più semplice.

È quindi possibile serializzare una copia di questo utilizzando XStream. Questo creerà una versione XML dell'oggetto HashMap.

Così l'applicazione può scrivere questo sul disco come richiesto, ed è possibile modificarlo a mano e ricaricarlo nell'applicazione. Ciò significa che hai la tua HashMap e una rappresentazione configurabile sul disco che puoi modificare secondo necessità.

Answer 7

La memorizzazione nella cache statica può funzionare.

Tenete presente che se si dispone di più applicazioni che accedono allo stesso database è necessario un qualche tipo di bus di messaggistica e un distributed cache

Answer 8

Se una cache di sola lettura che non viene aggiornato automaticamente è tutto ciò che serve per la vostra applicazione, quindi non c'è niente di sbagliato in questo approccio.

C'è un avvertimento: se la quantità di dati (inclusi il sovraccarico di oggetti Java e HashMap) diventa troppo grande per essere trattenuta interamente nella RAM, le prestazioni diminuiranno rapidamente e drasticamente (di un fattore di 10.000 o più). I sistemi di database sono progettati per un accesso efficiente ai dati su disco; una HashMap non lo è.

Answer 9

Se si utilizza una cache? Sì, se è molto più veloce e non si desidera aggiornare i dati o non è importante se i dati memorizzati nella cache non sono aggiornati con i dati reali.

È necessario inserire questo accesso dietro un'API e nascondere la memorizzazione nella cache dietro l'astrazione. Quindi puoi giocare con diverse strategie di memorizzazione nella cache, oppure scartare l'idea della cache completamente senza dover riscrivere il resto del codice ogni volta.

Answer 10

La tua idea non è poi così male, tuttavia, preferirei una soluzione di memorizzazione nella cache.

Ignorare le persone che dicono che è necessario ricompilare/ridistribuire ogni volta che i dati cambiano, poiché non credo che capiscano cosa intendi per statico. credono di avere i codici nella tua fonte.

Answer 11

Ancora una volta, a seconda di ciò che si fa, potrebbe andare bene. Finché hai avuto qualche metodo per mantenere ciò che è nella HashMap o simile in caso di manutenzione/spegnimento del server.

Tutto ciò che serve è un metodo di serializzazione. Ho visto che XStream è stato menzionato sopra.

C'è anche una libreria chiamata Prevayler. Questo serializza le modifiche al volo ma ti consente di tenere tutto in memoria. Quindi, anche in caso di interruzione improvvisa dell'alimentazione in cui non si ha il tempo di spegnersi correttamente, questo potrebbe essere di qualche utilità.

Sperimenta con diversi metodi per vedere cosa funziona per te ed estrarre i dettagli da un DAO.