1.
??bdbje??FE
2.
??Featu
I've had some private conversations with Tian Hui.
Currently there are two issues in Tianhui's current implementation in PR that I
am more concerned about：
1. one is using bdbje to process and store this information.
This itself is a stateless information. And bdbje is more for processin
>>
首先qps是一个性能指标，在相当一部分场景下，qps高可能表示的是这个查询的延迟非常低，而不是可能达到集群瓶颈的标志，如我们的业务几百qps和几千qps也是有的，连接数也不高，主要都是低延迟查询
很有价值的建议。
和kv数据库不同的是，qps并不能完全反馈系统的负载情况，因为不同sql的写法差异很大，而kv系统的请求相对简单且类似。
对于sql数据库通过限制qps来保护系统的做法，我个人理解可能只是适用于极端场景，比如用户代码bug导致无限制往数据库提交sql，就我们内部场景而言，大部分场景下可能用不到；
总之系统保护是一个比较综合性的大型系统工程，qps只是一个方面。
我比较同意的
感谢田晖提出的这个feature，不过有两个点想提出来讨论下。首先qps是一个性能指标，在相当一部分场景下，qps高可能表示的是这个查询的延迟非常低，而不是可能达到集群瓶颈的标志，如我们的业务几百qps和几千qps也是有的，连接数也不高，主要都是低延迟查询。
另外是否可以考虑使用同是运行的sql在某个时刻不得超过多少比较好？
第二，我觉得限制的原则就是和C++类似，需要尽量做到零开销，即你不用的东西，你就不需要付出代价，我比较关注的是增加这个特性之后如果没使用的话，对我们原来的查询或元数据性能影响多大。
你好，田晖同学，感谢你的建议；
我理解你是想通过限制运行中的sql最大数量来对doris集群保护，qps确实算是集群保护的一个方面，也值得去做。
不过我还有几个问题想了解下：
1 我不是很理解当前查询数量要被持久化的原因，我理解只需要把最大运行中的sql数量保存下就可以了
2 其次，这个最大qps的限制放到fe也是可以的，可以参考doris最大连接数的实现
最后，期望能够补充一个比较完整的设计文档，具体包含问题背景，方案设计以及用户手册
王博 Wang Bo
-
Doris
Doris
?? Doris
??FE??bdbje??
Hi Willem:
Actually, the doris-flink-connector does not need a "binary release".
So we decided to make a source release with a maven onvenience binaries.
And for the binary release process, we may do it for the Doris main repo[1],
like Doris(incubating) 1.0.0
We will start the doris-flink-connec
