考虑引入 ByConity 但是目前还有一些问题

[xingcici]

我们目前用 clickhouse 的场景，主要是时序数据和日志存储。
目前比较头疼的是 clickhouse 的运维。所以考虑往 ByConity 切换就不用管存储层了。
看了一下目前的 ByConity 的资料后主要有以下几个疑问，希望能帮忙解答一下，谢谢！

1. 时序数据查询这块有没有相应的性能数据 ？
2. 冷热数据查询性能的差距有多大 ？
3. 是否支持降采样或者说 continue query ？
4. Worker 是否支持同时配置为读写节点 ？

[Adora627]

我们目前用 clickhouse 的场景，主要是时序数据和日志存储。 目前比较头疼的是 clickhouse 的运维。所以考虑往 ByConity 切换就不用管存储层了。 看了一下目前的 ByConity 的资料后主要有以下几个疑问，希望能帮忙解答一下，谢谢！

1. 时序数据查询这块有没有相应的性能数据 ？
2. 冷热数据查询性能的差距有多大 ？
3. 是否支持降采样或者说 continue query ？
4. Worker 是否支持同时配置为读写节点 ？

1. 有一些用例类似时序数据库的用法，但因为涉及到字节业务所以没有公开性能数据。大致特征如下: 持续产生海量数据,没有波峰波谷；每条数据都带有时间戳；数据不可变,只会一直添加；高效的存储压缩效率；时序唯一性:某一个时刻的某一个指标只会有一条(一组也视为一条)数据。

2. 单表下，热读性能比 clickhouse 损耗10%，冷读损耗更大但业务影响不大，常用数据cache在本地worker的磁盘上；

3. 支持基本降采样；

4. worker 可以配置为读或者写节点，同时读写在一个节点上的部署方式理论可以但不推荐；

[xingcici]

我们目前用 clickhouse 的场景，主要是时序数据和日志存储。 目前比较头疼的是 clickhouse 的运维。所以考虑往 ByConity 切换就不用管存储层了。 看了一下目前的 ByConity 的资料后主要有以下几个疑问，希望能帮忙解答一下，谢谢！

1. 时序数据查询这块有没有相应的性能数据 ？
2. 冷热数据查询性能的差距有多大 ？
3. 是否支持降采样或者说 continue query ？
4. Worker 是否支持同时配置为读写节点 ？

1. 有一些用例类似时序数据库的用法，但因为涉及到字节业务所以没有公开性能数据。大致特征如下: 持续产生海量数据,没有波峰波谷；每条数据都带有时间戳；数据不可变,只会一直添加；高效的存储压缩效率；时序唯一性:某一个时刻的某一个指标只会有一条(一组也视为一条)数据。
2. 单表下，热读性能比 clickhouse 损耗10%，冷读损耗更大但业务影响不大，常用数据cache在本地worker的磁盘上；
3. 支持基本降采样；
4. worker 可以配置为读或者写节点，同时读写在一个节点上的部署方式理论可以但不推荐；

感谢您的回答！
之所以想读写在一个节点上，是因为我们的场景是写多读少。平时保留一部分读 worker 在成本不是很划算。
那么我想问下 ByConity 的动态扩容能力能在动态扩容后，实时把高负载的 worker 上的正在进行的查询计划重新分发到扩容后的低负载 worker 上吗？

[Adora627]

我们目前用 clickhouse 的场景，主要是时序数据和日志存储。 目前比较头疼的是 clickhouse 的运维。所以考虑往 ByConity
感谢您的回答！ 之所以想读写在一个节点上，是因为我们的场景是写多读少。平时保留一部分读 worker 在成本不是很划算。 那么我想问下 ByConity 的动态扩容能力能在动态扩容后，实时把高负载的 worker 上的正在进行的查询计划重新分发到扩容后的低负载 worker 上吗？

Worker被回收后，不太能自动转发查询计划，因为查询计划是从客户端向优化器发查询生成的。因此一般扩容前后的情况是 回收worker后，从客户端重新发起查询，会自动路由到还在进行读的worker上。运维的细节规则也可以根据你们的业务调整。

[xingcici]

我们目前用 clickhouse 的场景，主要是时序数据和日志存储。 目前比较头疼的是 clickhouse 的运维。所以考虑往 ByConity
感谢您的回答！ 之所以想读写在一个节点上，是因为我们的场景是写多读少。平时保留一部分读 worker 在成本不是很划算。 那么我想问下 ByConity 的动态扩容能力能在动态扩容后，实时把高负载的 worker 上的正在进行的查询计划重新分发到扩容后的低负载 worker 上吗？

Worker被回收后，不太能自动转发查询计划，因为查询计划是从客户端向优化器发查询生成的。因此一般扩容前后的情况是 回收worker后，从客户端重新发起查询，会自动路由到还在进行读的worker上。运维的细节规则也可以根据你们的业务调整。

好的 感谢！