Zipped sql script is smaller than the H2 database zipped. The
performance difference will be tiny on a database that small. I'd
definitely stick with the script/runscript. I do a similar thing, but
with databases of several hundreds of megabytes. In my case I do use the
BACKUP command, but I am importing on embedded devices, so the
performance (and memory hit) is quite significant if I was to use
script/runscript. For my long term backups I use script/runscript and
zip it. The resulting file is much smaller than the backup zipped.
Hope that makes sense, my brain is not working after new years :)
On 2/01/2014 12:10 AM, Christoph Läubrich wrote:
As always with performance you should profile that, but I assume that
the parsing of the script creates overhead, you also has to transfer
more data.
Maybe you can also create a disk-based DB and use the disk file
directly. If you think I/O performance matter for you small db, you
can e.g. use the shm device on linux to directly operate in-memory.
This also would reduce your overall memory footprint.
About CFX: shouldn multipart do the trick?
http://cxf.apache.org/docs/jax-rs-multiparts.html
Beside this, for testing purpose, you can always start with a base64
or otherwhise encoded String of binarry data, even if this doubles the
datasize it should be even less than a text based scripted DB.
Am 01.01.2014 16:38, schrieb Rob Oaks:
Is this what you are suggesting:
1.
Using H2 in IMDB mode, create the sub-database (defined above)
and populate it using queries against the parent database (SQL
Server). NOTE: While I could use H2 in persistent mode,
performance would certainly suffer.
2.
Use *BACKUP TO 'subdb.zip'* to create a ZIP backup of the
database (does *BACKUP TO* work in IMDB mode?).
3.
Send *subdb.zip* to ActiveMQ (via Web Service).
If this is indeed the approach you are suggesting, note that the only
difference between your suggestion and mine from the H2 perspective,
is that I am using *SCRIPT* to serialize the entire sub-database as a
string (no direct disk I/O), while you are using *BACKUP TO* to save
the sub-database as a ZIP.
Considering the small size of the sub-database (less than 100K) is
*BACKUP TO *significantly more efficient than *SCRIPT*? This is an
important question because, while this could certainly be changed,
the current messaging subsystem—built on top of CXF (in JAX-RS mode)
and ActiveMQ—does not support /attachments/ (CXF’s terminology), so
there’s some incentive to stay with string-based messaging.
String-based messaging is also a bit easier from a debugging
perspective (since I can directly log and inspect the message).
I am intrigued by your suggestion, and certainly want to do the best
thing architecturally, but I still need to be convinced that the
benefits are substantial.
Thanks so much for your perspective.
On Wednesday, January 1, 2014 7:49:23 AM UTC-5, Christoph Läubrich
wrote:
What is the point of converting the DB to a String? Why not
transfer the DB file itself to the other side? ActiveMQ can
handle binary messages to as well as webservices so this seems
overcomplicated.
Am 01.01.2014 02:24, schrieb Rob Oaks:
I am not yet an H2 user, but I�m thinking H2 IMDB may be an
excellent solution in the following context:
�
*
Populate an H2 IMDB from the results of a set of queries
against a conventional database (typically SQL Server) on
the */on-premise server/*. Note that the amount of data
generated will never be more than about a 100 Kb.
*
Programmatically use H2�s SCRIPT command to create a
string representation of the entire database.
*
Send that string via Web Service to our cloud server , which
sends that string to a message queue (ActiveMQ).
*
Our platform retrieves the string and uses H2�S RUNSCRIPT
command to recreate the H2 IMDB on our cloud server.
*
Execute queries against the H2 IMDB.
--
You received this message because you are subscribed to the Google
Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
