Hi, I'm currently evaluating databases for a project that will involve storing 40GB of a database in-memory and a further 800GB on-disk, the 40GB in-memory is a duplicate of the first 40GB of the 800GB on-disk.
My question is scaling the table size, I see partitioning is not yet supported on H2. The schema is flat(I really only need 1 table) but the in-memory will grow to ~200M rows and the on-disk to ~4B rows. The rows are timestamped and all queries will revolve around returning records between 2 timestamps so there is no problem in breaking this query up into many queries of time chunks and then aggregating the results. Can someone with some good H2 experience who has had to scale to very large row sizes comment on the best approach for this? I was thinking I could just create a new table every 1 million rows(or some other arbitrary number that results in predictable good performance) but this becomes a little bit of a pain to manage with wrapping once the databases hit their limits and I need to purge the last table and push the new table, it could be done though. Updates will be upwards of 1k/s(still not entirely sure though what this will hit but 1k/s is a fair start). Thanks. -- 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.
