[xwiki-users] why hsqdb rather than h2?
Just checking out the new 2.0 enterprise XWiki, great job! I'm just wondering why you are using hsqldb in the standalone version rather than h2 (http://www.h2database.com/html/main.html). H2 is in pretty much every way an improved version over hsql and I've been very impressed with its speed. Have you considered switching over and if you decided against it, I'd be interested in hearing the reasons. If you haven't considered it yet, I'll open an issue for it. Kalle
Kalle Korhonen wrote:
Just checking out the new 2.0 enterprise XWiki, great job! I'm just wondering why you are using hsqldb in the standalone version rather than h2 (http://www.h2database.com/html/main.html). H2 is in pretty much every way an improved version over hsql and I've been very impressed with its speed. Have you considered switching over and if you decided against it, I'd be interested in hearing the reasons. If you haven't considered it yet, I'll open an issue for it.
This is the first time I hear about it. Looking a bit on its site, I think that this is a good candidate for replacing hsql as the default database (Derby is the other one). There is only one problem I can see with it: choosing the right hibernate dialect. On the H2 documentation, they warn that the official H2Dialect is buggy (how?), but that the hsql dialect can be used. Somebody will have to test it and see if there are any problems, and if any speed improvement is noticeable. Please feel free to open an issue, patches welcome :) -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
Kalle Korhonen wrote:
Just checking out the new 2.0 enterprise XWiki, great job! I'm just wondering why you are using hsqldb in the standalone version rather than h2 (http://www.h2database.com/html/main.html). H2 is in pretty much every way an improved version over hsql and I've been very impressed with its speed. Have you considered switching over and if you decided against it, I'd be interested in hearing the reasons. If you haven't considered it yet, I'll open an issue for it.
This is the first time I hear about it. Looking a bit on its site, I think that this is a good candidate for replacing hsql as the default database (Derby is the other one). There is only one problem I can see with it: choosing the right hibernate dialect. On the H2 documentation, they warn that the official H2Dialect is buggy (how?), but that the hsql dialect can be used.
Somebody will have to test it and see if there are any problems, and if any speed improvement is noticeable.
Please feel free to open an issue, patches welcome :)
One nice feature I spotted: native support for clustering. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Sat, Sep 26, 2009 at 9:11 PM, Sergiu Dumitriu <[email protected]> wrote:
This is the first time I hear about it. Looking a bit on its site, I think that this is a good candidate for replacing hsql as the default database (Derby is the other one). There is only one problem I can see with it: choosing the right hibernate dialect. On the H2 documentation, they warn that the official H2Dialect is buggy (how?), but that the hsql dialect can be used.
Ok. There are a few open issues still on Hibernate's side, but I think the warning is kind of old. Though on H2's site they say it works with hsql dialect as well, I wouldn't use it - that gives more problems than solves. I've been using H2Dialect intensively and it has worked in my application that contains some fairly complex queries without any problems. They claim H2 performs much better than either hsql or Derby in most situations and I can assert the claim - I had verified it with my db tests (mostly related to write and transaction performance) running against all three databases, and my results were similar to what they mention at http://www.h2database.com/html/performance.html. Kalle
On Sat, Sep 26, 2009 at 9:20 PM, Sergiu Dumitriu <[email protected]> wrote:
One nice feature I spotted: native support for clustering.
IMHO, given the many things Xwiki plans to do, and limited time and resources, I don't think this would be worth a lot of effort unless it had some bigger payoff. Seems like anybody wanting better performance would just move to mysql and not use a java database at all. However, in addition to the clustering scenario, one area where a different "native" database might be useful would be for supporting Xwiki on "cloud" platforms like google app engine. Last time this was brought up http://lists.xwiki.org/pipermail/users/2009-July/016817.html the issue was Hibernate itself
On Wed, Jul 22, 2009 at 12:07 PM, Ludovic Dubost <ludovic at xwiki.org> wrote:
I have a prototype of XWIki partially working with some changes on app engine http://xwiki1.appspot.com/bin/view/Main/
I've made all the servlet / jvm part work as well as the cache subsystem. The main missing piece is a real storage with support for querying.
Ludovic -- thanks for the reply. That looks quite promising. I guess the "real storage" issue is caused by this limitation:
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app...
You cannot currently use Hibernate directly. The differences between the App Engine datastore and SQL were too great to get the standard Hibernate up and running under App Engine. App Engine does support JDO and JPA, so you may be able to convert your Hibernate code to use one of these ORM interfaces.
Also, with attachments stored in the db, large documents, or lots of documents, what happens to memory size and performance with respect to "large result sets": http://www.h2database.com/html/performance.html states Version 1.1.114 (2009-06-01) was used for the test. For simpler operations,
the performance of H2 is about the same as for HSQLDB. For more complex queries, the query optimizer is very important. However H2 is not very fast in every case, certain kind of queries may still be slow. One situation where is H2 is slow is large result sets, because they are buffered to disk if more than a certain number of records are returned. The advantage of buffering is, there is no limit on the result set size. The open/close time is almost fixed, because of the file locking protocol: the engine waits some time after opening a database to ensure the database files are not opened by another process.
-- Niels http://nielsmayer.com
Sergiu Dumitriu schrieb:
There is only one problem I can see with it: choosing the right hibernate dialect. On the H2 documentation, they warn that the official H2Dialect is buggy (how?), but that the hsql dialect can be used.
The H2Dialect is still broken; if you try to use it, you'll get exceptions when Hibernate tries to create the tables. Just use the HSQL dialect. All in all, it should be at most half an hour for someone who knows XWiki to replace one with the other. The major advantage of H2 over HSQL is not speed but H2 is under development while HSQL is pretty much dead. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://darkviews.blogspot.com/ http://www.pdark.de/
On Sun, Sep 27, 2009 at 2:39 AM, Aaron Digulla <[email protected]> wrote:
The H2Dialect is still broken; if you try to use it, you'll get exceptions when Hibernate tries to create the tables. Just use the HSQL dialect.
Table creation has worked for me with H2Dialect with latest Hibernate ok.
All in all, it should be at most half an hour for someone who knows XWiki to replace one with the other. The major advantage of H2 over HSQL is not speed but H2 is under development while HSQL is pretty much dead.
Agree, but I've had several cases where H2 has turned out to be way faster (DATEDIFF for example). Yes, it's easy to replace. H2 should be just seen as version two of hsqldb (as the name implies) rather than a completely different database though it's not completely backwards compatible (but you can still use e.g. hsql dialect with h2). Kalle
participants (4)
-
Aaron Digulla -
Kalle Korhonen -
Niels Mayer -
Sergiu Dumitriu