Just for comparison, I swapped out this table for the leveldb java port. In that case the 30G of byte arrays becomes 30G + change, which is about what I would expect for the db overhead. The read performance of leveldb was not much different than h2 for this data (it's mostly limited by disk seeks... will do an ssd test next), but the nearly 3X increase in data size in h2 is problematic for data at this scale.
On Friday, October 11, 2013 9:15:48 AM UTC-7, Brian Craft wrote: > > I'm storing a bunch of 400 byte varbinary objects in a table like so: > > CREATE CACHED TABLE PUBLIC.SCORES( > ID INT DEFAULT (NEXT VALUE FOR > PUBLIC.SYSTEM_SEQUENCE_0D2CC30B_0ED7_4EB5_A0D4_6448B031FC02) NOT NULL > NULL_TO_DEFAULT SEQUENCE > PUBLIC.SYSTEM_SEQUENCE_0D2CC30B_0ED7_4EB5_A0D4_6448B031FC02 SELECTIVITY 100, > EXPSCORES VARBINARY(400) NOT NULL SELECTIVITY 67 > ) > > There are 84440461 rows, so a bit over 30G of data. In h2 this becomes > over 90G on disk. Doing a dump/restore with SCRIPT/RUNSCRIPT, it becomes > over 100G (I was hoping it would shrink, by reducing fragmentation). > > I did expect some size cost for putting it in a sql database, but this is > fairly huge. What would be causing this, and are there any settings that > would affect it? > -- 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.
