It is a little bit difficult to explain if you aren't already pretty
familiar with Calcite, but I've used Calcite for multi-tenant before.
What you do is hold open the single root CalciteConnection, and then create
a sub-schema per tenant
Then, you scope the current statement to a sub-schema based on the tenant
name
So the schema layout might look something like this:
CalciteConnection
|
.getSchema()
|
SchemaPlus (rootSchema)
/ \
tenant-1-postgres-1 tenant-2-mysql-1
You can "navigate" or "fix" the current schema to the "tenant-X" schema
using ".getSubSchema()" or JDBC ".setSchema()" on the Driver calls
Then you can encode the tenant ID in IE, a JWT header claim, and decode it
serverside, force it to be set prior to any statement being run, and the
result is that SQL is securely scoped per-tenant.
I hope this helps and is understandable?
Let me know if not.
On Fri, Oct 21, 2022 at 5:51 AM Ruben Q L <[email protected]> wrote:
> > If you wanted to, you could write a merge sort algorithm that uses sort
> runs on disk. But that’s not in Calcite currently.
> Just to complete this info, there is a ticket logged for that feature [1],
> but AFAIK there is nobody working on it at the moment.
>
> [1] https://issues.apache.org/jira/browse/CALCITE-4193
>
>
> On Thu, Oct 20, 2022 at 9:01 PM Julian Hyde <[email protected]>
> wrote:
>
> > First, remember that the Calcite "interface Schema" is quite low level.
> It
> > is basically a namespace that contains a set of tables and a set of
> > sub-schemas. You can, and probably should, make it immutable.
> >
> > A Schema instance doesn’t know its own name or path. That allows you to
> > “mount” it (as you would mount a filesystem) under several paths.
> >
> > This gives you a clue for how you could serve multiple tenants, each
> > possibly seeing the same schema and tables (or possibly seeing different
> > subsets). Just set a different root schema for each tenant’s connection.
> I
> > believe that’s analogous to how a container like Docker works.
> >
> > Calcite does not, by default, write anything to disk. The built-in
> > adapters read from foreign wrappers (e.g. connecting to another JDBC
> > database or Cassandra or MongoDB or CSV files) but then process data in
> > memory.
> >
> > If you wanted to, you could write a merge sort algorithm that uses sort
> > runs on disk. But that’s not in Calcite currently.
> >
> > Julian
> >
> >
> > > On Oct 19, 2022, at 8:19 PM, JiaTao Tao <[email protected]> wrote:
> > >
> > > In fact, you can change calcite to use like HMS to manager schema
> > >
> > > Regards!
> > >
> > > Aron Tao
> > >
> > >
> > > Mike Albritton <[email protected]> 于2022年10月20日周四 07:16写道：
> > >
> > >> Hi all,
> > >>
> > >>
> > >> I am considering using Calcite in a multi-tenant application that can
> > run
> > >> queries from different customers in the same process and have a few
> > >> questions for those familiar with the code about this approach.
> > >>
> > >>
> > >> Specifically, I would like to know if metadata is completely separated
> > >> per-schema that is loaded or if it is ever shared between schemas?
> > Also, I
> > >> read in the docs somewhere that Calcite manages memory for cross
> schema
> > >> joins which seemed to suggest it may persist data to disk temporarily.
> > Is
> > >> this the case or is there somewhere I can learn more about how data
> > >> persistence works? Are there any other concerns that I should have
> when
> > >> running Calcite in a multi-tenant application?
> > >>
> > >>
> > >> Finally, if you or someone you know may be interested in a short term
> > >> contract to assist with a Calcite POC, let me know.
> > >>
> > >>
> > >> Regards,
> > >>
> > >> Mike
> > >>
> >
> >
>
