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