We need to solve this. IMO this is not an edge case scenario at all. I would say every MT scenario will require cross tenant analytics ... in our platform architecture tenants are meant to be close to each other as in they run the same software on top; thus cross tenant analytics are always natural.
What is an edge case is using DAS in an MT scenario. If someone wants full per tenant isolation in an MT scenario they can simple run DAS deployments per tenant. Or for groups of tenants. We too will have to do that for deployments that have lots of tenants as the load will be too much otherwise. IMO we should change to single data tables for all tenants. Sanjiva. On Fri, Apr 1, 2016 at 7:39 AM, Srinath Perera <[email protected]> wrote: > Use case come from IoT and APIM, and may be others. And it will be a > common use case due to our cloud. > > On Thu, Mar 31, 2016 at 3:55 PM, Anjana Fernando <[email protected]> wrote: > >> Hi Srinath, >> >> I'm not sure if this is something we would have to "fix". It was a clear >> design decision we took in order to isolate the tenant data, in order for >> others not to access other tenant's data. So also in Spark virtual tables, >> it will directly map to their own analytics tables. If we allow, maybe the >> super tenant, to access other tenant's data, it can be seen as a security >> threat. The idea should be, no single tenant should have any special access >> to other tenant's data. >> >> So setting aside the physical representation (which has other >> complications, like adding another index for tenantId and so on, which >> should be supported by all data sources), if we are to do this, we need a >> special view for super tenant tables in Spark virtual tables, in order for >> them to have access to the "tenantId" property of that table. And in other >> tenant's tables, we need to hide this, and not let them use it of course. >> This looks like bit of a hack to implement a specific scenario we have. >> >> So this requirement as I know mainly came from APIM analytics, where its >> in-built analytics publishes all tenant's data to super tenant's tables and >> the data is processed from there. So if we are doing this, this data is >> only used internally, and cannot be shown to each respective tenants for >> their own analytics. If each tenant needs to do their own analytics, they >> should configure to get data for their tenant space, and write their own >> analytics scripts. This may at the end mean, some type of data duplication, >> but it should happen, because two different users are doing their different >> processing. And IMO, we should not try to share any possible common data >> they may have and hack the system. >> > > Yes results need to go to super tenant space. > > >> >> At the end, the point is, we should not take lightly what we try to >> achieve in having multi-tenancy, and compromise its fundamentals. At the >> moment, the idea should be, each tenant would have their own data, its own >> analytics scripts, and if you need to scale accordingly, have separate >> hardware for those tenants. And running separate queries for different >> tenants does not necessarily make it very slow, since the data load will be >> divided between the tenants, and only extra processing would be possible >> ramp up times for query executions. >> > > Multi-tenancy always have to tradeoff with isolation vs. efficency. > However, we need to find a way to do APIM and IoT cloud use cases. > > >> >> Cheers, >> Anjana. >> >> On Thu, Mar 31, 2016 at 11:45 AM, Srinath Perera <[email protected]> >> wrote: >> >>> Hi Anjana, >>> >>> Currently we keep different Hbase/ RDBMS table per tenant. In >>> multi-tenant, environment, this is very expensive as we will have to run a >>> query per tenant. >>> >>> How can we fix this? e.g. if we keep tenant as field in the table, that >>> let us do a "group by". >>> >>> --Srinath >>> >>> -- >>> ============================ >>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>> Site: http://home.apache.org/~hemapani/ >>> Photos: http://www.flickr.com/photos/hemapani/ >>> Phone: 0772360902 >>> >> >> >> >> -- >> *Anjana Fernando* >> Senior Technical Lead >> WSO2 Inc. | http://wso2.com >> lean . enterprise . middleware >> > > > > -- > ============================ > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://home.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > -- Sanjiva Weerawarana, Ph.D. Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
