Hi guys,
Here is a suggestion. If a change is identified as a large or controversial
change. It might require an Improvement Proposal(refer to FLIP*1), and a
discussion on the dev mailing list to reach agreement and consensus.
1*
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
Houliang Qi 于2023年4月12日周三 21:30写道：
> A healthy community requires different voices. It is these different
> voices that enable us to strictly review each feature and consider each
> scenario more comprehensively, so that we can better provide users with
> better features.
>
> I am also very grateful to the colleagues who participated in this
> discussion.
>
> If it is still the previous discussion point, I will stick to my previous
> opinion and will not reply again.
>
> If someone brings up a new discussion point, I think it is possible to
> open another discussion.
>
>
>
>
>
> Thanks.
> ---
> Houliang Qi
> BONC, Ltd
>
>
> Replied Message
> | From | Houliang Qi |
> | Date | 04/12/2023 20:08 |
> | To | dev@iotdb.apache.org |
> | Subject | Re: [discuss] consider revert the feature of multi-tenancy |
> Hi,
> I would like to end by stating my point of view. And I don't want to say
> it a second time.
>
> First of all, I agree to change the name of this feature to resource
> control. The reason why I think that both multi-tenancy and
> resource-control are suitable for us is that what we are currently doing is
> to limit the functions of users or databases resources.
>
>
> @Jinrui 2. A true multi-tenant system should also have features such as
> per-tenant configurations, customized tenant roles and permissions, and
> clear separation of tenant data.
> @Jinrui 3. In our case, the lack of configuration file isolation in the
> current implementation means that different tenants may inadvertently
> affect each other's configurations, which goes against the core principle
> of multi-tenancy. The example I raised in last mail is also used to
> illustrate it rather than the function scope definition.
>
>
>
> But I disagree with Jinrui said above:
>
> You can refer to this paper [1]. This document summarizes multi-tenancy
> very well. First of all, it does not mean that multi-tenancy must have the
> ability to configure isolation. For this feature, we do share
> configuration, but our data is logically isolated and can limit some
> resources such as cpu, memory, timeseries, etc. This is also a way to
> realize multi-tenancy. Of course, each tenant can even use a different
> operating system, which is also a way to realize multi-tenancy. Please
> don't limit the way to realize multi-tenancy. There I would like to paste a
> passage from the paper as a conclusion:
>
>
> By sharing infrastructure, middleware, or application among tenants,
> multi-tenancy can be achieved
>
> In a multi-tenant architecture, a single instance of the software is
> deployed on the server functioning on the service provider infrastructure.
> It provides access to multiple tenants at the same time, as describe by
> Karataş et al. [KCD+17]. Abdul et al. [ABG+18]describe several multi-tenant
> data layer models, such as dedicated, isolated, shared, and hybrid. By
> sharing infrastructure, middleware, or application among tenants,
> multi-tenancy can be achieved. Figure 2.2 visualizes the multi-tenancy
> strategies described by Walraven et al. [WLJ14]. However, application-level
> multi-tenancy with a shared everything architecture can lead to cost
> reduction. Chong et al. [CCW06] have outlined several viable database
> patterns, primarily for Microsoft SQL Server, which supports
> application-level multi-tenancy. In a multi-tenant situation, they present
> three major strategies which are: distinct databases, shared databases with
> distinct schemes, and shared databases with shared schemes.
>
> [1] Enabling multi-tenant scalable IoT platforms.
> https://elib.uni-stuttgart.de/bitstream/11682/11024/1/Enabling%20multi-tenant%20scalable%20IoT%20platforms.pdf
>
>
>
>
>
> Thanks,
> ---
> Houliang Qi
> BONC, Ltd
>
>
> Replied Message
> | From | Jinrui 张金瑞<329920...@qq.com.INVALID> |
> | Date | 04/12/2023 19:14 |
> | To | |
> | Subject | Re: [discuss] consider revert the feature of multi-tenancy |
> Hi,
>
> Perhaps I need to emphasize again that regarding the multi-tenancy section
> discussed, the following is my conclusion:
> 1. The implementation of the PR cannot be called multi-tenancy
> 2. Multi-tenancy is not equal to resource control.
>
> The reasons are:
> 1. While resource isolation or control can be used to enable
> multi-tenancy, it's not the only requirement.
> 2. A true multi-tenant system should also have features such as per-tenant
> configurations, customized tenant roles and permissions, and clear
> separation of tenant data.
> 3. In our case, the lack of configuration file isolation in the current
> implementation means that different
