Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
What happened to object databases?
At 2:15 AM on Jul 21, 2007, Gregory Pierce
wrote:
Fresh Jobs for Developers Post a job opportunity
So, are there people out there really using object databases? If so, how are you finding their integration with Java, the performance, and the tools around them? Are the open source implementations worth anything?
40 replies so far (
Post your own)
Re: What happened to object databases?
This is something I have also wondered, but I know they are being used in some industries, particularly telecom (or so I've heard). I also know of a big insurance application built in Smalltalk with a Gemstone database.I would say that the reasons they haven't spread are legacy, cost and fear. There was also an issue about slowness earlier, which supposedly is gone these days. You basically need to regenerate the whole database when you change the schema, but above-mentioned insurance application said that was no problem.
Haven't tried any myself yet.
I wonder, though, if XML databases might not be just the thing, rather than object databases. I've started tinkering a bit with eXist and I like it.
On the other hand, Oracle obviously thought it was worth buying the Berkeley OODB for Java...
Currently engaged in Weffo web architecture outline and the Flying Saucer xhtml and xml+css renderer
Re: What happened to object databases?
I worked heavily with object databases in a commercial context for around 5 years. I stopped using them on business systems about 8 years ago, and instead started using an RDBMS with some sort of ORM layer. This, for me, was the right decision for the class of systems I architect in commercial settings... I even killed the use of an object db on a large system, and moved it to relational.Basically, the problem with object dbs boils down to one of lack of data independence. Business logic is encoded in the object schema, in the form of navigation paths.
Let me explain: most object dbs work using single-direction object links, much like java references. Going in the right way using these links is usually blisteringly fast. Going the wrong way is usually very slow. So, the object model is created with the links for the navigation paths required by the business logic. The trouble is that if you want to report on the data or perform ad-hoc queries, the schema will constrain you.
Relational databases feature data independence, where ad-hoc queries and post-deployment optimisation can easily occur. By definition, a foreign key can be used to navigate in both directions between the two tables involved.
So, for most systems I've designed in the last 8 years, I've used an RDBMS with an appropriate mapping layer. I used toplink for around 5 years, and found it quite good. Hibernate is better, and it's free.
The arguments are summarised in the following forum:
http://www.infoq.com/news/2007/06/orm-obms-debate
Contains some interesting points of view from people like Gavin King, myself and others. I think it also shows the level of misunderstanding most people have of object databases.
On the +ve side, object dbs can be extremely performant when used correctly. I use an object db for a complex case tool I work on, and it works superbly. The graphs get complex, and I wouldn't consider an RDBMS could do the job with the same level of performance. I've also successfully deployed large commercial telecoms and financial apps using Versant.
I've found JDO to be a very solid ODBMS interface. (I haven't used it for relational). I'm sad that it seems to have been pushed aside by a level of political interference and ignorance. JDO is far superior to the old versant native interface, for instance. The lifecycle of objects is sensible and well thought out. My favourite Java ODBMS is objectdb (www.objectdb.com). It is superb, and I've had 10gb databases running with it in client-server mode with brilliant performance. Fantastic software. (I have no connection with the objectdb company apart from being a very satisfied user).
Other people like db4o (www.db4o.com). It doesn't support JDO, but you can use JPOX with it to do that. I don't particularly like the db4o native interface, but people have had good success in the embedded area with it. It's very resource efficient and has a GPL version.
So, for me the bottom line is that object dbs are good for certain domains (cad, case, complex graphs), where speed is paramount (e.g. exchange trading) or for embedded environments (resource efficient in embedded mode). For storing business data, however, an RDBMS is preferred due to the flexibility of reporting and data queries. I've never found the dual schema problem of RDBMS to be a real problem in a commercial app -- in reality the closeness of the object model and the schema in an ODBMS causes more problems than it solves, particularly for complex schema evolution.
Cheers,
Andrew
p.s. it really is "horses for courses" though. In the last project I architected, we used a high speed vector database (www.kx.com) for storing tb of financial data. Works much better for this domain than an object db or a relational db would, as it is optimised for this domain... (It's not really a full relational db, even though they claim this...)
Re: What happened to object databases?
I am a novice to ODBMS so please take the following with a grain of salt. I'd also love to hear your feedback on some of my questions.I tried DB4O a few years ago and the thing that turned me off was:
1) Lack of clustering support. It could very well be that you have no need for this sort of thing (think SVN vs ClearCase) but I didn't know for sure and didn't want to take a chance.
2) It was primarily geared for embedded use, whereas I was looking for a solid client-server database.
3) I was very uncomfortable running on DB4O given the state of the source-code in the GPL version. It was a total mess. The company seems reluctant to enhance the database specifically for this reason: it is very painful to modify the code. I ran into quite a few serious bugs and it took a few weeks for them to get resolved. Granted most people didn't run into these bugs but this didn't help my confidence in the software.
4) It wasn't immediately clear how one goes from a RDBMS to a ODBMS. Andrew brought up a good point about the lack of back-references in the schema. But Andrew, couldn't you just add these back-references to the schema seeing as you need them?
5) It isn't clear how to lock objects without killing performance. Hibernate has a concept of optimistic-locking which means that it does not lock the table it is modifying and if it detects a collision at commit this it replays the transaction. It isn't clear to me whether locking an object in a ODBMS means that my entire system grinds to a halt.
6) The community size is a lot smaller than for RDBMS and this has a huge cost in my view because when I run into problems it takes much longer to resolve.
I would personally love to move to see ODBMS succeed, unfortunately it seems that no one is targetting the niche I am trying to use them for
I don't think we'll see the success of ODBMS until we have the equivilent of MySQL for ODBMS: an open-source database with a Apache/BSD license that is geared at client-server use in a clustered environment. Just my 2 cents.
Gili
Re: What happened to object databases?
Hiya,> I tried DB4O a few years ago and the thing that
> turned me off was:
I don't want to really defend db4o, as I don't personally like it. It's just my opinion, others do use it successfully... I found its API to be at a far lower level than I am used to in this space.
Anyway, I will try to answer the questions as best I can...
> 1) Lack of clustering support. It could very well be
> that you have no need for this sort of thing (think
> SVN vs ClearCase) but I didn't know for sure and
> didn't want to take a chance.
Not really too sure what you mean by this, it's possibly my ignorance on the way that RDBMS' are used...
> 2) It was primarily geared for embedded use, whereas
> I was looking for a solid client-server database.
Versant and Objectdb both offer robust client-server modes. if you need client-server, I wouldn't use db4o, as I think it is targetted at the embedded space which generally doesn't want the client-server overhead.
> 3) I was very uncomfortable running on DB4O given the
> state of the source-code in the GPL version. It was a
> total mess. The company seems reluctant to enhance
> the database specifically for this reason: it is very
> painful to modify the code. I ran into quite a few
> serious bugs and it took a few weeks for them to get
> resolved. Granted most people didn't run into these
> bugs but this didn't help my confidence in the
> software.
I've not looked at the code. Doesn't sound too good though, from what you've said. I've evaluated the performance against others for a consulting project and wasn't impressed.
> 4) It wasn't immediately clear how one goes from a
> RDBMS to a ODBMS. Andrew brought up a good point
> about the lack of back-references in the schema. But
> Andrew, couldn't you just add these back-references
> to the schema seeing as you need them?
Versant supports bi-links, which are effectively back-references. this works, but you can't put them everywhere or you end up with a complete tangle of dependencies. part of the trouble is that the ODBMs must mirror what the objects do. If the objects have a back reference the object schema can have one. If they don't, then the object schema can't have one. Imagine however having to maintain those back-links in your object model!
I believe db4o has concocted a clever scheme where they stream out from their db into an RDBMS, giving a sort of "best of both worlds approach". Caveat: I've never used it.
I've been stung by the back-references issue on a financial project. It worked great for transaction processing, but when they went to make the GUI, it was a complete mess because the links required for the GUI logic and reporting were completely different to those required for the tp logic. Adding them in after the fact is difficult to impossible for a large-ish db.
> 5) It isn't clear how to lock objects without killing
> performance. Hibernate has a concept of
> optimistic-locking which means that it does not lock
> the table it is modifying and if it detects a
> collision at commit this it replays the transaction.
> It isn't clear to me whether locking an object in a
> ODBMS means that my entire system grinds to a halt.
I think your experience with db4o has probably coloured your view, but the facilities offered by db4o are not the norm here. Most client-server dbs (versant, objectdb etc) have a choice between optimistic and pessimistic locking (it's an option in jdo1.0, not sure about 2.0). In addition, objects in these systems are locked automagically as you read or write them. Usually works seamlessly. Not quite as flexible a locking model as oracle, but close to SQL server for instance.
I used optimistic locking heavily with objectdb, and catch any optimistic exceptions and retry the transactions. This is the same approach I'd use on an RDBMS.
> 6) The community size is a lot smaller than for RDBMS
> and this has a huge cost in my view because when I
> run into problems it takes much longer to resolve.
This is true, which is why I liked the JDO spec. Many vendors, many products, one spec. In theory
> I would personally love to move to see ODBMS succeed,
> unfortunately it seems that no one is targetting the
> niche I am trying to use them for
> see the DB4O authors clean up their source-code for
> starters. I can't see anyone in the open-source
> community wanting to work with that code otherwise.
again, I haven't looked at the DB4o source code, so I can't comment. I was put off by the GPL license as I mostly write commercial software.
could you perhaps write some more about the niche your are using them for? maybe myself or others could make recommendations?
> I don't think we'll see the success of ODBMS until we
> have the equivilent of MySQL for ODBMS: an
> open-source database with a Apache/BSD license that
> is geared at client-server use in a clustered
> environment. Just my 2 cents.
Yeah, it's a fair point. Even if we get this (think objectdb open sourced etc), I think that there are fundamental problems that people will run into. However, ODBMs' definitely have their place, I believe, and a lot of uninformed opinion passes for expertise in this space. In this respect, maybe I am no different
Cheers,
Andrew
p.s. the above represents only my opinions, I know that some people will get quite worked up by some of the answers I have given. For the record, I have no employment links with db4o, objectdb or versant. I have used the latter in the past on many commercial projects. I've also purchased a license for objectdb for my own work in the past and have been extremely impressed by it. The purchase was based on evaluation of the market alternatives at the time.
Re: What happened to object databases?
> What happened to object databases?Um, DB Admins? Also better ORMs.
Re: What happened to object databases?
Hello,When you store informations in database, isn't only for ONE application but for the enterprise.
How reporting tools like "Crystal Report", can read datas in the Object Database ?
Does my "Toad tools" or DBVisualizer can see information in the database ?
Does DB Administrator can tune or admin the database whith their tools ?
How non Java application can read data in the object database ?
The good performances are not sufficient to swith to a system different of relationnal database.
Vincent D.
Re: What happened to object databases?
> How reporting tools like "Crystal Report", can read> datas in the Object Database ?
> Does my "Toad tools" or DBVisualizer can see
> information in the database ?
> Does DB Administrator can tune or admin the database
> whith their tools ?
> How non Java application can read data in the object
> database ?
Some of these I think are symptoms of immaturity and lack of tool support rather than intrinsic problems of an ODBMS.
There are (or rather were) reporting tools for object databases. We evaluated a few. Versant and others also have browsers and management consoles similar in spirit to toad. And Versant provides many language bindings to the same db, and an ODBC driver.
The reporting issue, though, is troublesome though for an object database, primarily due to the lack of data independence (see my previous posts). Also, the lack of a standard DDL-like management language for the ODBMS space makes it difficult to find administrators.
Andrew
Re: What happened to object databases?
IMHO ODBMS didn't fail for technical reasons but mostly because of the lack of an ecosystem around them (lack of skills, tools, etc.).They also failed because they primarily emerged exactly at the time where RDBMS where starting to consolidate their positions within large organizations (late 80's).
They also failed because they did their IPO too early (in the 95's) and they wasted their money before the internet bubble, so they totally missed it.
Maybe, RDBMS vendors spread a lot of misinformation about ODBMS. There is no theorical reason why an ODBMS would be slower or less mature than any other DB. This is just a question of implementation.
I have seem many benchmarks where Versant outperformed other major RDBMS. Some ODBMS can be faster than RDBMS, when there is a complex business model, with complex transactions. One reason could be because navigating a reference could be done in a most efficient way than performing a query between 2 tables through a FK.
Please note than internally Oracle provides some equivalent functions where they can use navigation between "pointers". In some cases, maybe Versant was faster just because it had less costly features (security...)
From the storage point of view RDBMS and ODBMS can be quite similar. An object "reference" is nothing else than a foreign key, an OID is nothing else than a PK.
An ODBMS could be a neutral storage system with an object-oriented interface built on top of it. Exactly like SQL is just a relational interface on top of a storage. This object-oriented interface can be as open and independent from applications as SQL. XML could be another interface, as GData or Atom as well.
Now my point is the following one: Yes, the storage is critical (it certainly has to be robust...) but the data access layer is, at least, as critical.
That's why JDO is so important. ORM is now well-perceived, but that notion of MAPPING must be extended to any data source. You can even define a mapping between an ODBMS schema and a given business model, so that you'll get the independence you expect. That is far from being stupid. RDBMS brougth some independence between database schemas and application models. Mapping now brings that independence to a much wider level.
Once data has been stored somewhere customers will rarely pay to move it somewhere else. ODBMS vendors missed that. Legacy is so important.
What is really fundamental is to be able to select the best storage technology (or use the one that is already in place) with the easiest interface for a given project.
For one project, an object-oriented interface will be the best, then use JPA or JDO on top of the storage. For another project a non-object oriented interface will be better, then use, XML or SDO (service data objects) or whatever else suitable.
There are already technologies on the market to do that.
Just my 2 cents.
Eric.
Re: What happened to object databases?
Well there is already an open source product out there that deals with multiple datasources and data source formats - http://www.metamatrix.com/, something recently acquired by RedHat and open sourced.Re: What happened to object databases?
On the topic of Reporting Tools, why can't they use the DB-native query language instead of actually adding backlinks into your object schema? Sure it will be slower but reporting occurs far less often.Are you saying the problem is that you've essentially got the same data with different object models on top of it? One for your application, another for reporting software, another for ...?
My guess would be that if you've only got two types of object models and one of them is rarely used (i.e. reporting) then you're fine. Alternatively maybe what you need to do is redesign your object model so your reporting and application model share and manipulate the same underlying data (State design pattern)? I suspect there is a object-oriented solution to most of these problems but there are no formal guidelines like there are for RDBMS which make it obvious how to proceed. We need a Design Patterns like book for ODBMS
Re: What happened to object databases?
AFAIK metmatrix is rather an EII approach than a persistence/mapping interface, or maybe I'm missing something?Re: What happened to object databases?
> On the topic of Reporting Tools, why can't they use> the DB-native query language instead of actually
> adding backlinks into your object schema? Sure it
> will be slower but reporting occurs far less often.
ODBMS do have query languages... but it is not SQL.
As reporting tools are mostly based on SQL it is not a solution.
Some ODBMS (like Versant and others) used to provide an additional SQL layer, but it was somewhat limited in functionalities. Conversely, it would be nice to have reporting tools being able to access something different from relational models. But then it would require to connect to various DB models, this is where a unified interface to all data providers would be helpful.
Eric.
Re: What happened to object databases?
I don't know about the rest of you, but my favorite query language so far is "native queries" by DB4O. It feels the most natural. Are there any downsides to this approach? Does anyone dislike it for any particular reason?Re: What happened to object databases?
native queries are nice, but require the "back end" to interpret the bytecodesthe problem is that as soon as you want to go against the links, you will end up doing effectively a "full table scan" or the equivalent in an ODBMS. i.e. looking through all objects of a given type to find out which one has a particular reference. Versant/SQL used to work this way, and it got very, very slow.
Andrew