Re: [h2] using external(cloud) key-value db as backing store

2021-04-27 Thread Noel Grandin
On Sat, 24 Apr 2021 at 06:52, Alex Ramos wrote: > I've come down to a decision-point with three choices... 1) reimplement > MVStore abstraction, 2) reimplement filesystem abstraction used by MVStore, > or 3) implement pluggable tables, one layer up. > > > MVStore is a "transactional key-value

Re: [h2] using external(cloud) key-value db as backing store

2021-04-25 Thread Andreas Reichel
Hi Alex, thank you for the explanation. On Sat, 2021-04-24 at 11:59 -0700, Alex Ramos wrote: > - But I don't like database servers.    > - So my idea is to move to embedded H2 with cloud backing store and > get rid of the database servers, while keeping SQL, JDBC, > JdbcTemplate, and Hibernate.

Re: [h2] using external(cloud) key-value db as backing store

2021-04-24 Thread Alex Ramos
Hi Andreas, Thanks for asking. I realized I have some unstated goals. Here are my thoughts: On Saturday, April 24, 2021 at 12:22:30 AM UTC-7 and...@manticore-projects.com wrote: > > a) mount the cloud storage per SSHFS and access the normal DB file > This configuration would still retain

Re: [h2] using external(cloud) key-value db as backing store

2021-04-24 Thread Andreas Reichel
Greetings. On Fri, 2021-04-23 at 21:43 -0700, Alex Ramos wrote: > The end-goal is the ability to instantiate an "embedded" h2 that uses > "dumb" (NoSQL) cloud storage to persist the data and index B-Trees, > while retaining the full RDBMS SQL capability of the upper layers. Pardon my dumb

[h2] using external(cloud) key-value db as backing store

2021-04-23 Thread Alex Ramos
Hi All, I'm investigating the possibility of using an external key-value store as the backing store for h2 db. Imagine something like Redis, memcache, or DynamoDB, as an alternative to the current two choices if in-memory vs filesystem storage. The end-goal is the ability to instantiate an