Dear Dario, thx for the help and the patience. I tend to mix up several thoughts into one sentence. so i will try to be sharper with my questions
On Oct 18, 8:20 pm, Dario Fassi <[email protected]> wrote: > Hi, > > El 18/10/10 07:14, HJ escribi�: > > > If I store them (as singles) compressed to a normal > > file then I reach 10Mb and if i store them simply as a concat of texts > > to a file then it results into a size of 20MB. > > I don't understand what do you mean. > Compressing each row individually and written to a file end with 10mb, and > the same text uncompressed ends with 20mb size ? If I take in Java each field (like such a String i should you above) as a String and compress it and write it to a file the resulting file size is around 10Mb for 42000 fields. If I store these fields uncompressed into a text file the result into a text file with a size of 20MB. If I store each single field compressed to a database (even unindexed) the resulting size of the database is 35MB. If I skip the compression step and store 42000 Strings to the H2 database the size of the database grows to around 70MB. So my actual question is: Why is the database so immensely larger then when storing "raw" data as a file? Ok a database always creates a little overhead but it does not double the data. > The other idea of Thomas, that half empty b trees might affect the > > size cant be true since i created a table with an indexed INTEGER > > field. Hence the large text field is only stored aside the indexed > > field. and 42000 INT values dont result into a B tree of 40MB :-). > > You miss understand, talking about binary type overhead Thomas say that row > insertion algorithm on a b-trees "try" to matain 50% of b-tree nodes free > because performance reasons. > > > @Dario: The script idea doesnt help either (Its simply not a doable > > task when users use embedded databases of the size of some gigs) > > I really dont understand the scenario of your use case. > > I say using SCRIP with and init script on connection URL like: > jdbc:h2:file:~/sample;INIT=RUNSCRIPT FROM '~/create.sql'\\;RUNSCRIPT FROM > '~/populate.sql' > as a way to deploy a new data set to clients with minimal size. > > If your populated database have 10GB you can deploy it to clients as a 1.5GB > script that populate your remote database on case of a new data set deploy, > and I can't imagine other way to send such data volume in a more compact form. > > For a 10GB db ,your compressed text file would be about 2.8 Gb, right ? > > > I think that the only thing I can do now is to store the large field > > from my db to a file and single compressed and storing the location to > > the database > > > Another and maybe a little dumb question is, how to activate the > > lobsindatabase option. Is the a connection parameter > > System properties can be set with > (http://www.h2database.com/javadoc/index.html): > > System properties can be set when starting the virtual machine: > > java -Dh2.lobInDatabase=true > > They can be set within the application, but this must be done before loading > any classes of this database (before loading the JDBC driver): > > System.setProperty("lobInDatabase", "true") > So I can do this before Class.forName(org.h2...)? > regards, > Dario regards HJ -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
