You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@doris.apache.org by 晖 <82...@qq.com.INVALID> on 2022/02/18 06:43:36 UTC
回复： Re: Doris 限制并发查询量
1. 该代码对于查询性能是完全没有影响的，因为是异步的同步查询数量信息，每次都在本地进行判断。而且查询数量本身是一个很小的数据，所以对于元数据的影响也是微乎其微的。bdbje仅用作FE之间同步信息之用，对于持久化确实没有强需求。
2. 对于原有逻辑也没有任何改变，仅多了一次判断，默认情况下不会察觉到有这个Feature的添加。
3. 关于用户手册在PR里已经有了，设计文档我在评论里补充一下，对于使用场景，报表类场景确实不需要，分析型场景对于QPS的限制需求个人感觉还是比较普遍
4. 类似限制连接数这种关于完全做成FE local的方案，无法对整个Doris系统的查询做限制，所以没有被采用
------------------ 原始邮件 ------------------
发件人: "dev" <wangbo13131@gmail.com>;
发送时间: 2022年2月18日(星期五) 中午1:18
收件人: "dev"<dev@doris.apache.org>;
主题: Re: Re: Doris 限制并发查询量
>>
首先qps是一个性能指标，在相当一部分场景下，qps高可能表示的是这个查询的延迟非常低，而不是可能达到集群瓶颈的标志，如我们的业务几百qps和几千qps也是有的，连接数也不高，主要都是低延迟查询
很有价值的建议。
和kv数据库不同的是，qps并不能完全反馈系统的负载情况，因为不同sql的写法差异很大，而kv系统的请求相对简单且类似。
对于sql数据库通过限制qps来保护系统的做法，我个人理解可能只是适用于极端场景，比如用户代码bug导致无限制往数据库提交sql，就我们内部场景而言，大部分场景下可能用不到；
总之系统保护是一个比较综合性的大型系统工程，qps只是一个方面。
我比较同意的是如果确定要搞的话，最好不要对原有逻辑造成影响，包括性能和代码复杂度
——————————————————————————————————————————————
>> First of all, qps is a performance indicator. In quite a few scenarios,
high qps may indicate that the latency of the query is very low, rather
than a sign that the cluster bottleneck may be reached
Very valuable suggestion.
Different from the kv database, qps cannot fully feedback the load of the
system, because the writing method of different sql is very different, and
the request of the kv system is relatively simple and similar.
For the SQL database to protect the system by restricting qps, I personally
understand that it may only be suitable for extreme scenarios, such as user
code bugs that lead to unlimited submission of SQL to the database, as far
as our internal scenarios are concerned, it may not be used in most
scenarios;
In short, system protection is a relatively comprehensive large-scale
system engineering, and qps is only one aspect.
What I agree with is that if you decide to do it, it is best not to affect
the original logic, including performance and code complexity.
王博 Wang Bo
蔡聪辉 <caiconghui2013@163.com> 于2022年2月18日周五 12:54写道：
>
> 感谢田晖提出的这个feature，不过有两个点想提出来讨论下。首先qps是一个性能指标，在相当一部分场景下，qps高可能表示的是这个查询的延迟非常低，而不是可能达到集群瓶颈的标志，如我们的业务几百qps和几千qps也是有的，连接数也不高，主要都是低延迟查询。
>
> 另外是否可以考虑使用同是运行的sql在某个时刻不得超过多少比较好？
>
>
> 第二，我觉得限制的原则就是和C++类似，需要尽量做到零开销，即你不用的东西，你就不需要付出代价，我比较关注的是增加这个特性之后如果没使用的话，对我们原来的查询或元数据性能影响多大。
>
>
> ——————————————————————————————————————————————
> Thanks Tian Hui for this feature, but there are two points I want to
> discuss.
> First of all, qps is a performance indicator. In quite a few scenarios,
> high qps may indicate that the latency of the query is very low, rather
> than a sign that the cluster bottleneck may be reached. For example, there
> are hundreds of qps and thousands of qps in our business. The number of
> connections is not high, mainly low-latency queries.
> In addition, can it be considered that it is better to use the sql running
> at the same time not to exceed a certain amount?
>
>
> Second, I think the principle of restriction is similar to that of C++. We
> need to try to achieve zero overhead: You don’t need to pay for things you
> don’t need. How big is the impact on query or meta management performance.
>
>
>
>
> 在 2022-02-18 12:39:31，"王博" <wangbo13131@gmail.com> 写道：
> >你好，田晖同学，感谢你的建议；
> >我理解你是想通过限制运行中的sql最大数量来对doris集群保护，qps确实算是集群保护的一个方面，也值得去做。
> >不过我还有几个问题想了解下：
> >1 我不是很理解当前查询数量要被持久化的原因，我理解只需要把最大运行中的sql数量保存下就可以了
> >2 其次，这个最大qps的限制放到fe也是可以的，可以参考doris最大连接数的实现
> >
> >最后，期望能够补充一个比较完整的设计文档，具体包含问题背景，方案设计以及用户手册
> >
> >王博 Wang Bo
>
> >------------------------------------------------------------------------------------------------------------------
> >Hello, Tian Hui, thank you for your suggestion;
> >I understand that you want to protect the Doris cluster by limiting the
> >maximum number of running SQLs. QPS is indeed an aspect of cluster
> >protection, and it is worth doing.
> >However, I still have a few questions to ask:
> >1 I don't quite understand the reason why the current number of queries
> >should be persisted. I think that I only need to save the maximum number
> of
> >running sqls.
> >2 Secondly, this maximum qps limit can also be placed in fe, you can refer
> >to the implementation of the maximum number of connections in doris.
> >Finally, it is expected to be able to supplement a relatively complete
> >design document, including the problem background, scheme design and user
> >manual.
> >
> >王博 Wang Bo
> >
> >晖 <827677355@qq.com.invalid> 于2022年2月18日周五 12:07写道：
> >
> >> 大家好，我是小米的田晖，由于 Doris 在小米公司内部得到了广泛的使用，对于集群稳定性有了更高的要求。通过对 Doris
> >> 服务相关指标的监控，我们认为有必要通过限制并发查询量来保护 Doris
> >>
> 集群。为了做到系统级别的限制，我认为通过同步各FE节点查询量来限制并发是当前最合适的方案，并基于bdbje同步查询数量信息实现了一版代码，PR地址：
> >> https://github.com/apache/incubator-doris/pull/7474
> >>
> >>
> >> 关于此PR目前有两点不同看法：
> >> 1. 是否应该基于bdbje同步查询数量
> >> &nbsp; &nbsp; &nbsp;
> >>
> 有观点认为各FE当前执行的查询数量是一个无状态信息，不应该被bdbje保存。但是其实当前查询数量也可以看作是一个变化比较频繁的状态信息，同时Doris目前也没有其他信息同步机制，所以我认为使用dbdje保存并同步也无不可。
> >> 2. 是否应该将此限制做到数据库系统内部
> >> &nbsp; &nbsp; &nbsp;
> >> 该观点认为有类似负载均衡器之类的外部模块可以做到相同的QPS限制。但是由于MySQL通信协议是基于传输层网络协议的，所以主流的Nginx和LVS
> >>
> 都没有相关的QPS限制功能，并且外部模块也不具备识别SQL类型的功能，我们这里只希望限制查询SQL，所以我认为将此限制做到数据库系统内部是合适的。
> >>
> >>
> >> 大家对于这个Feature是什么看法呢？请多多指教～
>
Re:回复： Re: Doris 限制并发查询量
Posted by 蔡聪辉 <ca...@163.com>.
两个额外的建议
1.建议做成可配置的，默认关闭，这样子可以做到不带来额外开销如果不需要的话
2.系统层面的全局的限制似乎不太友好，是否可以考虑用户层面的限制。其实我们限制住了每个用户的行为就保护了系统，现在貌似如果先有用户占用了所有的配额，那么其他用户就用不了了？如果其他用户用不了，那跟系统不可用貌似没有区别
---------------------------------------------------------------------------
Two additional suggestions
1. It is recommended to make it configurable and closed by default, so that it can be done without additional overhead if it is not needed
2. The global restrictions at the system level do not seem very friendly. Can user-level restrictions be considered? In fact, we protect the system by limiting the behavior of each user. Now it seems that if the first user occupies all the quota, then other users can't use it? If other users can't use it, it doesn't seem to be different from the system being unavailable.
在 2022-02-18 14:43:36，"晖" <82...@qq.com.INVALID> 写道：
>1. 该代码对于查询性能是完全没有影响的，因为是异步的同步查询数量信息，每次都在本地进行判断。而且查询数量本身是一个很小的数据，所以对于元数据的影响也是微乎其微的。bdbje仅用作FE之间同步信息之用，对于持久化确实没有强需求。
>2. 对于原有逻辑也没有任何改变，仅多了一次判断，默认情况下不会察觉到有这个Feature的添加。
>3. 关于用户手册在PR里已经有了，设计文档我在评论里补充一下，对于使用场景，报表类场景确实不需要，分析型场景对于QPS的限制需求个人感觉还是比较普遍
>4. 类似限制连接数这种关于完全做成FE local的方案，无法对整个Doris系统的查询做限制，所以没有被采用
>
>
>------------------ 原始邮件 ------------------
>发件人: "dev" <wangbo13131@gmail.com>;
>发送时间: 2022年2月18日(星期五) 中午1:18
>收件人: "dev"<dev@doris.apache.org>;
>
>主题: Re: Re: Doris 限制并发查询量
>
>
>
>>>
>首先qps是一个性能指标，在相当一部分场景下，qps高可能表示的是这个查询的延迟非常低，而不是可能达到集群瓶颈的标志，如我们的业务几百qps和几千qps也是有的，连接数也不高，主要都是低延迟查询
>
>很有价值的建议。
>和kv数据库不同的是，qps并不能完全反馈系统的负载情况，因为不同sql的写法差异很大，而kv系统的请求相对简单且类似。
>对于sql数据库通过限制qps来保护系统的做法，我个人理解可能只是适用于极端场景，比如用户代码bug导致无限制往数据库提交sql，就我们内部场景而言，大部分场景下可能用不到；
>总之系统保护是一个比较综合性的大型系统工程，qps只是一个方面。
>我比较同意的是如果确定要搞的话，最好不要对原有逻辑造成影响，包括性能和代码复杂度
>
>——————————————————————————————————————————————
>>> First of all, qps is a performance indicator. In quite a few scenarios,
>high qps may indicate that the latency of the query is very low, rather
>than a sign that the cluster bottleneck may be reached
>
>Very valuable suggestion.
>Different from the kv database, qps cannot fully feedback the load of the
>system, because the writing method of different sql is very different, and
>the request of the kv system is relatively simple and similar.
>For the SQL database to protect the system by restricting qps, I personally
>understand that it may only be suitable for extreme scenarios, such as user
>code bugs that lead to unlimited submission of SQL to the database, as far
>as our internal scenarios are concerned, it may not be used in most
>scenarios;
>In short, system protection is a relatively comprehensive large-scale
>system engineering, and qps is only one aspect.
>What I agree with is that if you decide to do it, it is best not to affect
>the original logic, including performance and code complexity.
>
>
>王博 Wang Bo
>
>蔡聪辉 <caiconghui2013@163.com> 于2022年2月18日周五 12:54写道：
>
>>
>> 感谢田晖提出的这个feature，不过有两个点想提出来讨论下。首先qps是一个性能指标，在相当一部分场景下，qps高可能表示的是这个查询的延迟非常低，而不是可能达到集群瓶颈的标志，如我们的业务几百qps和几千qps也是有的，连接数也不高，主要都是低延迟查询。
>>
>> 另外是否可以考虑使用同是运行的sql在某个时刻不得超过多少比较好？
>>
>>
>> 第二，我觉得限制的原则就是和C++类似，需要尽量做到零开销，即你不用的东西，你就不需要付出代价，我比较关注的是增加这个特性之后如果没使用的话，对我们原来的查询或元数据性能影响多大。
>>
>>
>> ——————————————————————————————————————————————
>> Thanks Tian Hui for this feature, but there are two points I want to
>> discuss.
>> First of all, qps is a performance indicator. In quite a few scenarios,
>> high qps may indicate that the latency of the query is very low, rather
>> than a sign that the cluster bottleneck may be reached. For example, there
>> are hundreds of qps and thousands of qps in our business. The number of
>> connections is not high, mainly low-latency queries.
>> In addition, can it be considered that it is better to use the sql running
>> at the same time not to exceed a certain amount?
>>
>>
>> Second, I think the principle of restriction is similar to that of C++. We
>> need to try to achieve zero overhead: You don’t need to pay for things you
>> don’t need. How big is the impact on query or meta management performance.
>>
>>
>>
>>
>> 在 2022-02-18 12:39:31，"王博" <wangbo13131@gmail.com> 写道：
>> >你好，田晖同学，感谢你的建议；
>> >我理解你是想通过限制运行中的sql最大数量来对doris集群保护，qps确实算是集群保护的一个方面，也值得去做。
>> >不过我还有几个问题想了解下：
>> >1 我不是很理解当前查询数量要被持久化的原因，我理解只需要把最大运行中的sql数量保存下就可以了
>> >2 其次，这个最大qps的限制放到fe也是可以的，可以参考doris最大连接数的实现
>> >
>> >最后，期望能够补充一个比较完整的设计文档，具体包含问题背景，方案设计以及用户手册
>> >
>> >王博 Wang Bo
>>
>> >------------------------------------------------------------------------------------------------------------------
>> >Hello, Tian Hui, thank you for your suggestion;
>> >I understand that you want to protect the Doris cluster by limiting the
>> >maximum number of running SQLs. QPS is indeed an aspect of cluster
>> >protection, and it is worth doing.
>> >However, I still have a few questions to ask:
>> >1 I don't quite understand the reason why the current number of queries
>> >should be persisted. I think that I only need to save the maximum number
>> of
>> >running sqls.
>> >2 Secondly, this maximum qps limit can also be placed in fe, you can refer
>> >to the implementation of the maximum number of connections in doris.
>> >Finally, it is expected to be able to supplement a relatively complete
>> >design document, including the problem background, scheme design and user
>> >manual.
>> >
>> >王博 Wang Bo
>> >
>> >晖 <827677355@qq.com.invalid> 于2022年2月18日周五 12:07写道：
>> >
>> >> 大家好，我是小米的田晖，由于 Doris 在小米公司内部得到了广泛的使用，对于集群稳定性有了更高的要求。通过对 Doris
>> >> 服务相关指标的监控，我们认为有必要通过限制并发查询量来保护 Doris
>> >>
>> 集群。为了做到系统级别的限制，我认为通过同步各FE节点查询量来限制并发是当前最合适的方案，并基于bdbje同步查询数量信息实现了一版代码，PR地址：
>> >> https://github.com/apache/incubator-doris/pull/7474
>> >>
>> >>
>> >> 关于此PR目前有两点不同看法：
>> >> 1. 是否应该基于bdbje同步查询数量
>> >> &nbsp; &nbsp; &nbsp;
>> >>
>> 有观点认为各FE当前执行的查询数量是一个无状态信息，不应该被bdbje保存。但是其实当前查询数量也可以看作是一个变化比较频繁的状态信息，同时Doris目前也没有其他信息同步机制，所以我认为使用dbdje保存并同步也无不可。
>> >> 2. 是否应该将此限制做到数据库系统内部
>> >> &nbsp; &nbsp; &nbsp;
>> >> 该观点认为有类似负载均衡器之类的外部模块可以做到相同的QPS限制。但是由于MySQL通信协议是基于传输层网络协议的，所以主流的Nginx和LVS
>> >>
>> 都没有相关的QPS限制功能，并且外部模块也不具备识别SQL类型的功能，我们这里只希望限制查询SQL，所以我认为将此限制做到数据库系统内部是合适的。
>> >>
>> >>
>> >> 大家对于这个Feature是什么看法呢？请多多指教～
>>