Database seems to be a little large

hi all,

we’re using razuna and the included h2 database. we noticed that razuna.h2.db became quite large, much larger than expected. summed up all tenant’s assets we store about 57 gb in the filesystem, but the database grew up to 114 gb. and it seems that it doesn’t shrink if assets are deleted.
i assume that all assets are stored in the database and the filesystem: why? and if so, why does deleting an asset in the filesystem break the links to the assets?

cheers
lorenz

57gb and your are using H2? H2 is not meant to be used in production.
Please consider switching to MySQL.

hi nitai,

i’ve seen the former discussion about using h2 or not. except for the growth of the database i’m satisfied with h2. and assumed i’d switch to mysql - will the database become smaller? since mysqls innodb grows even if you delete entries?

lorenz

Hi,

I can’t say about the size of the DB. I believe they tend to be about the
same size. We have nothing but good experiences with MySQL, especially on a
dedicated server as you can fine tune the performance a lot. Something
which you can’t do with H2. Furthermore, H2 is using the same Java memory
pool as Razuna, thus influencing the performance of Razuna itself (impacts
when you have a lot of data).

Hope this helps.

hi nitai,

ok, but beyond the size of the database and which one to use: why is obviously every asset stored in the database AND the filesystem?

Assets are NOT stored in the database. The database is being used for the
assets metadata and for all other aspects of Razuna.

114 gigabytes of metadata???

Once again, I advise to move to MySQL. I’m not the developer of H2 and don’t know how they store the data. If you want to keep using H2 you can contact them so see how you can minimize the database. Though, I don’t recommend it as we have seen tremendous performance improvement with MYSQL (I have posted the reason fo this above already).

We have over 5000 customers on our hosted platform and use MySQL. We run a database of 15GB currently. Guess that proves the point…