News: Carbonado: Relational Persistence Abstraction
Carbonado is a new relational persistence abstraction layer, capable of binding to different storage technologies. Whether you use JDBC or a BDB, an application written using Carbonado doesn't know the difference. On the surface, it may appear that Carbonado is just another ORM, thus competing with Hibernate, JDO and EJB. One feature which makes Carbonado special is the ability to issue queries without translating to SQL. Using Carbonado against a BDB offers high performance by skipping all the translation layers offered by other solutions. In order to query against a BDB, Carbonado adds support for indexes and joins. A rule-based query optimizer decides which indexes to use for a given query. For convenience, query objects have a method for printing the execution plan. Carbonado also supports traditional relational concepts such as constraints, triggers and transactions. A common use of Carbonado is to replicate into a BDB, using it as a complete cache. All queries go against the cache, sparing your central RDMS from the load. In fact, if your RDMS is down, all queries from the replicated repository are still fulfilled. Another feature of Carbonado is the ease in which persistent objects are defined and used. Carbonado Storables are not POJOs. They are defined as interfaces or abstract classes and more closely follow the Active Record design pattern. A few annotations are required to complete the definition, but the actual code to implement the Storable is automatically generated at runtime. Carbonado was developed internally at Amazon.com, and now it has been released as an open source project. It was briefly mentioned on TSS a few weeks ago, but I chose not to announce until the site was ready and a release was available. Although Carbonado is fast and stable, it is far from a finished project. Part of the motivation in releasing it as an open source project is to get community support. Likewise, it would be a shame to see such a useful project be confined and proprietary.
- Posted by: Brian O'Neill
- Posted on: October 31 2006 05:28 EST
- Curious by peter lin on October 31 2006 11:36 EST
- Re: Carbonado: Relational Persistence Abstraction by Erwin Bolwidt on October 31 2006 12:56 EST
- Sounds good by Raould Traore on January 10 2008 18:36 EST
I'm curious, what kind of "rule-based" query optimizer does it use? peter lin
I'm not sure what you mean by "kind". In general, query optimizers are defined as rule-based or cost-based. A cost-based optimizer creates a query plan based on estimating the time it will take. To do this, it gathers statistics on the data. A rule-based optimizer, like the one used in Carbonado, creates a query plan based on heuristics. It is often easier to implement, but it can be dead wrong compared to a cost-based optimizer. As such, it often uses elements of the user's query for hints. For example, the order of the filter terms can make a difference. With a good set of indexes, however, there's often not a big difference between the two approaches.
What type of application would benefit in your opinion from the approach taken by Carbonado versus existing solutions like Hibernate/JDO? To be honest, reading the description, this sounds like a very technically cool project but with limited practical use. What is the advantage of having to implement a specific interface for your objects instead of standard JavaBeans? And as much as BDB is nice and simple, why would you want to use it for business data? It doesn't integrate well with your corporate data infrastructure, does it? And how many administrators would know how to fix a broken BDB database? Is the performance so much better than other solutions that it is worth it? Erwin Bolwidt
Some of the benefits were outlined in this thread a few weeks ago, although for BDB DPL: http://www.theserverside.com/news/thread.tss?thread_id=42529 Performance is often much faster by skipping all the layers. I'm working on a PolePosition benchmark, and the results look pretty good. Although Storables implement a specific interface, all the property access methods still follow JavaBean conventions. You can also have a common interface defining these properties, if you'd like to share between POJO based solutions. As for BDBs, they are very useful for both large caches and canonical storage. They are also substantially easier to maintain than a traditional RDBMs. No need for a DBA. Replication into a BDB, from a RDBMs is a good strategy as well. You offload work from a shared resource, and if something goes horribly wrong, you can resync the data into the BDB.
Some of the benefits were outlined in this thread a few weeks ago, although for BDB DPL: http://www.theserverside.com/news/thread.tss?thread_id=42529I'm an Oracle employee on the Berkeley DB Java Edition development team and I posted the article mentioned above. We see most of our Berkeley DB users choosing Berkeley DB either for performance or simplicity (ease of development, deployment, maintenance) as Brian mentions. But one thing that has always been missing is an API that allows the developer to easily switch between BDB and an SQL database, or to replicate data between the two. Carbonado fills that need and does a very good job of it. Prior to Carbonado, if a developer wanted the ability to very easily switch between BDB and an SQL DB he/she would have to implement a persistence abstraction of their own. Now Carbonado can be used as that abstraction. Carbonado has other interesting features of course. I am biased toward the one I mentioned, of course, being part of the Berkeley DB team. Another thing that is personally interesting to me about Carbonado is the usability of the API. It does not conform to a standard (JPA or JDO) as already mentioned, and this is what is interesting. Often APIs designed by small groups, outside of any standards body or committee, have more usable designs because they aren't as constrained. In my opinion the design of Carbonado has benefited from this factor and is easier to use than JPA or JDO. Mark
Much like C# lit a fire under Java, and Rails light a fire under... Java, I think this kind of new thinking is nothing but good, even if the project itself falters (which I sincerely hope it does not) - kicking db4o and Hibernate upside the head, and making us all stop and think about what else could be done is a huge community service. Kudos and thanks to the folks who put this out there for the world to see.