1

I've got a Java application that needs to deal with 10s to 100s of gigabytes of data. Any DBMS needs to be embedded. We currently have a db4o solution that is slow, brittle and complicated. I will allow that many of our wounds have been self-inflicted.

Let's posit that this current db4o implementation is unsalvageable. Would people recommend continuing with db4o (and just be more careful in its use)? Or are there other embedded DBs that you can positively recommend?

Thanks for your feedback.

user888379
  • 1,343
  • 12
  • 30
  • There are a whole bunch of embedded DBs. There are substantially fewer OODBs, which is what db4o is. Do you need an OODB? – Dave Newton Jan 15 '12 at 20:29
  • I'm attracted by the impedance matching concept, but it's more of "nice to have" than a "must have." Reliability and performance weigh more heavily in the scales. – user888379 Jan 15 '12 at 23:31
  • Well, it'll be tough to make any great recommendations w/o knowing what kind of performance characteristics you're looking for, how the data is used, etc--I'd recommend doing some benchmarks and seeing what works for your particular use case. – Dave Newton Jan 15 '12 at 23:41
  • Fair enough. My situation is that in profiling my application, I find that the CPU hotspots are dominated by db4o queries. In normal use, the DB can essentially be read-only. The application is a simulation, and the stored data represents various physical attributes - the organization of the data needn't be especially complex, but datasets can get to be arbitrarily large. I'm confident that our use of db4o could be greatly improved, but that this will require a great deal of work - comparable to starting from scratch. I'm just interested in seeing what viable alternatives might exist. – user888379 Jan 16 '12 at 02:17
  • I suppose that you're using indexes in your db4o queries, right? – German Jan 21 '12 at 20:46
  • Apparently not. Thanks for the helpful question! – user888379 Jan 23 '12 at 14:45

1 Answers1

3

Well db4o isn't made for 10s and 100s of Gigabytes. The absolute maximum for a db4o database is 256 GB when setting the block-size to the allowed maximum. However I would expect that the performance breaks down earlier.

What kind of data do you store? What's the shape of your data? What are your performance characteristics? Without that it's hard to recommend a fitting database.

Anyway, in the Java-Space I made good experience with the H2 database. It is a great relational database. But I cannot tell if your stuff is suited for a relational database.

I also heard many good things about Neo4J, a graph database. Personally I haven-t used it yet, but when your data is more graph oriented, I would look into that.

Gamlor
  • 12,978
  • 7
  • 43
  • 70
  • Thanks for the information. I'm learning this stuff as we speak, hence the unspecific questions. I'm trying to be fair to db4o, and not let my current dissatisfaction with our implementation unduly poison my mind against it. However, I'd be more comfortable knowing about some alternatives. – user888379 Jan 16 '12 at 22:04