[Java] Mi conviene un database ad oggetti?

[Lim]

Salve a tutti.
Dovendo gestire un elevato numero di oggetti nel mio software, mi chiedo se abbia senso utilizzare un database ad oggetti (come ad esempio: db4o) per velocizzare l'esecuzione e per ottimizzarne l'occupazione della memoria.
Premetto che non ho mai lavorato con questo tipo di database.

Il mio problema principale è il dover gestire e manipolare centinaia di migliaia di oggetti che NON vengono mai rimossi, fino alla fine dell'esecuzione del programma (che può durare anche alcune settimane). Tipicamente vengono tutti istanziati dopo l'avvio del programma, anche se non è da escludere la creazione e distruzione di oggetti durante il corso dell'esecuzione stessa, ma la loro vita è comunque limitata.

Mi chiedo se l'archiviazione e la gestione delle interazioni con questi oggetti persistenti possa essere delegata al DB senza occupare svariati GB di RAM (cosa che attualmente accade, saturo tranquillamente 10GB!!!). Immagino che il DB li salvi su disco, sbaglio? Quindi andrei a perdere in prestazioni, ma supererei il limite della memoria. Qualcuno che li conosce bene può confermare le mie ipotesi (speranze?)

Grazie

[starfred]

Ciao, premetto che forse non ho capito bene il problema quindi scrivo come l'ho capito io e semmai mi correggi.
Tu hai un programma che crea all'avvio parecchi oggetti che arrivano ad occupare fino a 10gbyte di ram; tu vorresti utilizzare un database per memorizzare questi oggetti, esatto?

[Lim]

Esatto, grosso modo è così. Ma potrei aver bisogno anche di un numero molto superiore di oggetti.
Ho cercato di documentarmi a riguardo dei DB a oggetti, per ora sembrerebbero essere la soluzione, ma qualcuno ha altri suggerimenti li accolgo volentieri!

Per i DB al momento ho individuato Hibernate e JDBC, che dite? Qualcuno li conosce e me ne consiglia uno piuttosto che l'altro?
Grazie

[ally]

...hibernate e JDBC non sono database...hibernate è un mapper per interfacciarsi allo strato persistente...un ORM per l'esattezza...e jdbc è il connttore...puoi snocciolare un esempio di cio' che devi realmente fare?...non hai modo di semplificare l'array da gestire in modo che punti agli elementi piu' esosi in termini di spazio senza saturare la ram?...

[banryu79]

Dovendo gestire un elevato numero di oggetti nel mio software, mi chiedo se abbia senso utilizzare un database ad oggetti (come ad esempio: db4o) per velocizzare l'esecuzione e per ottimizzarne l'occupazione della memoria.

e

Per i DB al momento ho individuato Hibernate e JDBC, che dite? Qualcuno li conosce e me ne consiglia uno piuttosto che l'altro?

Attenzione perchè tu parli di Database ad Oggetti (Object Oriented Database Management System aka OODMS) ma in effetti, di quello che hai detto, solo db4o rientra in questa categoria.
JDBC non è un database; JDBC è un'API Java che consente l'accesso/comunicazione con database relazionali (Relational Database Management System aka RDMS) da codice java, non c'entra niente quindi con gli OODMS.
Infine, Hybernate è una libreria ORM (Object Relational Mapping), fornisce un framework che avrebbe lo scopo di aiutarti a mappare il tuo dominio applicativo object oriented su quello relazionale di un RDMS (che la tua applicazione usa per la persistenza).

[Lim]

Avete ragione, ovviamente, ma come dicevo mi sto affacciando ora a questo mondo quindi faccio un po' di confusione

Quindi, vediamo se ho capito, posso utilizzare db4o come DB a oggetti e posso utilizzare Hibernate per interfacciarmici? o proprio non c'entra nulla Hibernate? (PS non so se utilizzero db4o, esistono anche altri prodotti che ve la sentite di consigliare? free se possibile)

.non hai modo di semplificare l'array da gestire in modo che punti agli elementi piu' esosi in termini di spazio senza saturare la ram?...

No, stavo tentando l'approccio della semplificazione nei giorni scorsi, ma prima di esporvela faccio una brevissima panoramica sull'applicazione (banryu79 sicuramente se la ricorda, non è la prima volta che ne condivido alcuni degli aspetti + critici nel forum):

Allora, sto realizzando un simulatore tempo discreto caratterizzato da migliaia (ma anche milioni) di oggetti interagenti.
Ci sono oggetti di tipo A che devono mantenere il riferimento a migliaia di oggetti di tipo B, per invocarne le funzioni. Esistono anche migliaia di oggetti di tipo C che possono interagire con gli oggetti di tipo A attraverso le funzionalità degli oggetti di tipo B.
Quindi ogni volta che C viene in contatto con A, A invoca le funzionalità di uno dei "suoi" oggetti di tipo B. Ovviamente A deve esplorare la sua lista di oggetti B per trovare quello adatto (se c'è). Diciamo che questi sono gli oggetti persistenti più importanti (anche se durante l'esecuzione ne possono nascere e morire degli altri, ma diciamo che fin dai primi istanti della simulazione ne esistono già un numero considerevole che potrebbe non "morire" mai, fino al termine dell'esecuzione stessa).

Nei giorni scorsi ho tentato una semplificazione, inglobando gli oggetti (complessi) B all'interno degli oggetti A, ma non credo che sia un buon approccio, perchè mi sono ritrovato a dover creare non una ma 4 liste (1 ArrayList e 3 Map) per mantenere le funzionalità assolutamente necessarie degli oggetti B. Ogni lista contiene migliaia di elementi di tipo:
- ArrayList<float[]>
- Map<Integer,Oggetto tipo C> (si, C è l'oggetto citato sopra...)
- Map<Integer,Oggetto tipo D> (D è un oggetto che rappresenta lo stato interno del oggetto B che ora non esiste +)
- Map<Integer,Oggetto tipo E> (E è un altro tipo...)

Ho dovuto poi creare una consistente quantità di metodi per la gestione di queste 4 liste (devono essere sempre ben allineate) e quindi ad ogni step temporale è necessario invocarne le funzionalità. Oltre ad essere un approccio meno elegante è anche molto più dispendioso in termini di tempi di esecuzione. Inoltre non sono convinto di aver ottimizzato l'occupazione della memoria in modo determinante (ho anche il dubbio di averla peggiorata in realtà... :P)

Il fatto è che in realtà non conosco il limite superiore nel numero di oggetti da istanziare ad ogni simulazione, oltre ad essere variabile in funzione dell'esecuzione stessa, un domani potrei dover simulare situazioni ancor più complesse, quindi devo trovare una soluzione migliore del "limare" qualche oggetto qui e là...

I DB ad oggetti mi sembrano una soluzione promettente.

[shinya]

Non conosco il dominio del problema, ma forse ti può essere utile un database a grafi, tipo neo4j (di cui mi parlano bene).
http://neo4j.org/
Dacci un'occhio.

[starfred]

Ciao, prima di avventurarti nel mondo dei DB a oggetti credo che bisognerebbe fare un analisi di come il tuo codice utilizzi la memoria. Tu hai detto che usi 10Gbyte di memoria virtuale le domande che ti pongo sono:
Come mai vuoi utilizzare meno memoria virtuale? (Sembra banale ma non lo è)
Hai controllato quanti Page fault genera la tua applicazione?
Quanta ram utilizza la tua applicazione?

Ti faccio un esempio semplice, se usi 10Gbyte di VM(memoria virtuale) e 1 Gbyte di ram e dopo 1 ora che il software ha girato hai generato pochissimi PageFault io credo che sia decisamente inutile modificare il codice.

Libero di esser smentito, ciao

[Lim]

Originariamente inviato da starfred

[...] Tu hai detto che usi 10Gbyte di memoria virtuale le domande che ti pongo sono:
Come mai vuoi utilizzare meno memoria virtuale? (Sembra banale ma non lo è)
Hai controllato quanti Page fault genera la tua applicazione?
Quanta ram utilizza la tua applicazione?

Ho configurato una Virtual Machine con 4 core e 18GB di RAM.
Ho Configurato uno HEAP da circa 16GB in fase di avviamento del simulatore.
Attualmente (dopo una settimana ininterrotta di esecuzione), con il profiler vedo che l'occupazione della memoria ha un grafico a dente di sega, con minimo a 3GB e massimo a 10GB. Il task Manager invece vede sempre intorno ai 10-11GB.
La memoria virtuale allocata da Windows attualmente è intorno ai 2GB.
Non avevo mai considerato i page-faults, immagino che siano gli HardFaults/sec nel Resource Monitor di Windows, giusto? Beh, sono sempre a 0...

Prossimamente dovrò lanciare simulazioni molto più pesanti (milioni di oggetti) e da un rapido calcolo ho concluso che non mi basteranno i 64 GB di RAM totale installata sul server...

[Lim]

Originariamente inviato da shinya

Non conosco il dominio del problema, ma forse ti può essere utile un database a grafi, tipo neo4j (di cui mi parlano bene).
http://neo4j.org/
Dacci un'occhio.

Ho dato un'occhiata a questi graph database. Potrebbero fare al caso mio, ma non riesco, al momento, a decidere quale delle due soluzioni possa essere la scelta migliore. In effetti potrebbero andare bene entrambe.
I graph sembrano essere più veloci, ma dipende dal tipo di interrogazione che si deve fare, altrimenti risultano molto più lenti delle altre tipologie. C'è qualcuno che ne sappia abbastanza su entrambi i tipi di DB?

Premetto che io devo, ad ogni step temporale, leggere le liste di oggetti associate ad un particolare oggetto e verificare se uno degli elementi soddisfa determinati requisiti (andando a valutare i valori di alcuni attributi).
Mi è sembrato di capire che per questo tipo di operazione il graph non sia consigliato??

[ally]

Originariamente inviato da Lim

Premetto che io devo, ad ogni step temporale, leggere le liste di oggetti associate ad un particolare oggetto e verificare se uno degli elementi soddisfa determinati requisiti (andando a valutare i valori di alcuni attributi).
Mi è sembrato di capire che per questo tipo di operazione il graph non sia consigliato??

...qualsiasi database fa al caso tuo...

[Lim]

Originariamente inviato da ally

...qualsiasi database fa al caso tuo...

Mi è anche stato suggerito di utilizzare il SERIALIZE al posto dei DB a oggetti (o a grafi). Che ne pensate? Differenze?

[Floris]

Serialize non fa altro che codificare gli oggetti in modo che possano essere salvati/caricati da file.
Sicuramente, per grandi moli di oggetti, un database è più efficiente nella ricerca/caricamento.
Potresti anche usare serialize per codificare gli oggetti e poi salvarli in un database normale.

Se i page faults sono 0 significa che nessuna pagina richiesta era stata spostata nell'area di paginazione su disco per fare spazio in RAM.
Ovvero la RAM era sufficiente.