esperienze con db4o?

Question

Attualmente sto provando db4o (la versione Java) e quello che vedo mi piace molto.Ma non posso fare a meno di chiedermi come si comporta in un vero ambiente live (web).Qualcuno ha qualche esperienza (buona o cattiva) da condividere sull'esecuzione di db4o?

Answer 1

Eseguiamo la versione DB40 .NET in un grande progetto client/server.

La nostra esperienza è che puoi potenzialmente ottenere prestazioni molto migliori rispetto ai tipici database relazionali.

Tuttavia, devi davvero modificare i tuoi oggetti per ottenere questo tipo di prestazioni.Ad esempio, se hai un elenco contenente molti oggetti, l'attivazione di questi elenchi in DB4O è lenta.Esistono diversi modi per aggirare questo problema, ad esempio invertendo la relazione.

Un altro dolore è l'attivazione.Quando si recupera o si elimina un oggetto da DB4O, per impostazione predefinita verrà attivato l'intero albero degli oggetti.Ad esempio, caricando un Foo verrà caricato Foo.Bar.Baz.Bat, ecc. finché non rimarrà più nulla da caricare.Anche se questo è utile dal punto di vista della programmazione, le prestazioni rallenteranno maggiormente la nidificazione degli oggetti.Per migliorare le prestazioni, puoi dire a DB4O quanti livelli di profondità attivare.Questa operazione richiede molto tempo se hai molti oggetti.

Un'altra area problematica era la ricerca di testo.La ricerca del testo di DB4O è molto, molto più lenta dell'indicizzazione del testo completo SQL.(Te lo diranno apertamente sul loro sito.) La buona notizia è che è facile impostare un motore di ricerca testuale su DB4O.Nel nostro progetto, abbiamo collegato Lucene.NET per indicizzare i campi di testo che desideriamo.

Alcune API sembrano non funzionare, come le API GetField utili per applicare gli aggiornamenti del database.(Ad esempio, hai rinominato una proprietà e desideri aggiornare gli oggetti esistenti nel database, devi utilizzare queste API di "riflessione" per trovare gli oggetti nel database.Altre API, come l'attributo [Index], non funzionano nella versione stabile 6.4 ed è necessario invece specificare gli indici utilizzando Configure().Index("someField"), che non è fortemente tipizzato.

Abbiamo assistito al peggioramento delle prestazioni quanto più grande è il database.Al momento disponiamo di un database da 1 GB e le cose sono ancora veloci, ma non così veloci come quando abbiamo iniziato con un piccolo database.

Abbiamo riscontrato un altro problema per cui Db4O.GetByID chiuderà il database se l'ID non esiste più nel database.

Abbiamo scoperto che la sintassi delle query native (la sintassi per le query più naturale e integrata nel linguaggio) è molto, molto più lenta delle query SODA meno semplici.Quindi invece di digitare:

// C# syntax for "Find all MyFoos with Bar == 23".
// (Note the Java syntax is more verbose using the Predicate class.)
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23);

Invece di quel bel codice di query, devi fare una brutta query SODA basata su stringhe e non fortemente tipizzata.

Per gli utenti .NET è stato recentemente introdotto un provider LINQ-to-DB4O, che fornisce la migliore sintassi finora disponibile.Tuttavia, è ancora da vedere se le prestazioni saranno all'altezza delle brutte query SODA.

Il supporto DB4O è stato decente:abbiamo parlato con loro al telefono diverse volte e abbiamo ricevuto informazioni utili.I forum degli utenti sono quasi inutili, tuttavia quasi tutte le domande rimangono senza risposta.Il loro bug tracker JIRA riceve molta attenzione, quindi se hai un bug fastidioso, archivialo su JIRA e spesso verrà risolto.(Abbiamo avuto 2 bug che sono stati risolti e un altro che è stato corretto in modo inadeguato.)

Se tutto questo non vi ha spaventato, lasciatemi dire che siamo molto soddisfatti di DB4O, nonostante i problemi che abbiamo riscontrato.Le prestazioni che abbiamo ottenuto hanno spazzato via alcuni framework O/RM che abbiamo provato.Lo consiglio.

aggiornamento luglio 2015 Tieni presente che questa risposta è stata scritta nel 2008.Anche se apprezzo i voti positivi, il mondo è cambiato da allora e queste informazioni potrebbero non essere affidabili come lo erano quando sono state scritte.

Answer 2

La maggior parte delle query native può e viene convertita in modo efficiente in query SODA dietro le quinte, quindi ciò non dovrebbe fare la differenza.L'uso di NQ è ovviamente preferibile poiché rimani nell'ambito del linguaggio fortemente tipizzato.Se hai problemi a far sì che NQ utilizzi gli indici, non esitare a pubblicare il tuo problema su forum db4o e proveremo ad aiutarti.

Goran

Answer 3

Il problema principale che ho riscontrato è la segnalazione.Semplicemente non sembra esserci alcun modo per eseguire report efficienti su un'origine dati db4o.

Answer 4

Judah, sembra che tu non stia utilizzando l'attivazione trasparente, che è una caratteristica dell'ultima versione di produzione (7.4)?Forse se specificassi la versione che stai utilizzando potrebbero esserci altri problemi che ora sono risolti nell'ultima versione?