if a table exists for multiple tenants, is it poss...
# general
j
if a table exists for multiple tenants, is it possible to restrict query results to a single tenant?
m
What do you mean by tenant here?
j
we need to segregate client data
well, looking at docs, can I specify multiple tenants when creating a table?
Copy code
"tenants": {
      "broker": "myBrokerTenant", 
      "server": "myServerTenant"
    },
m
A table can only have one tenant for server and one for broker. A tenant can be shared across tables
j
well, dang. So if we need to segregate data by client (tenant) then each table requires a unique name?
m
No it does not
You can have a single table on single tenant and have all clients data on the same table?
j
no -- our clients don't like their data mixed.
m
Then have separate table per client?
j
each client needs their own 'customer' table, as an example
m
Yeah so 1 client - 1 table - 1 tenant if you want to complete separation
Not a scalable mode perhaps
But seems like that is what your customers are asking for
j
no, without multi-tenancy, each client would have their own environment. Each environment would have the same tables.
m
What’s is an environment? Helix cluster? If so, then two helix clusters are completely air gapped and you are fine
j
our hope was to have TenantA on BrokerA and ServerA with table 'Customers'. Then also, TenantB on BrokerB and ServerB with table 'Customers'...
I was using 'environment' in a general sense: a set of servers.
m
It me it sounds like separate tables? If so, why does the name of table need to be same?
Because customers may end up having their own schema as well in future?
Note that you cannot have multiple tables with same name in one cluster
j
because we have 100s of clients. Managing tables Customer_ClientA, Customer_ClientB, Customer_ClientC gets very cumbersome
there's lots of tables for each customer also
m
I think you want same table across all customers but then no two customers can share the same set of brokers/servers?
j
right. Their data needs to be kept separate
m
That is also not scalable if you have 100's of customers. For durability, you will end up having 3 brokers + 3 servers per customer, regardless of what amount of data they have.
One way is to partition the data on customerId. But that will segregate at partition level and not customer level.
Perhaps customers really want is customer level ACL?
If so, that can be built on a mid-tier layer on top of single table in Pinot?
j
our customers are financial companies -- mixing data across those companies isn't an option
m
What you are trying to use the tenant concept in Pinot is not what it is meant for, and doesn't solve your problem.
A table in Pinot can only have one tenant for server and one for broker