V2EX › RedisMasterNode 的所有回复 › 第 10 页 / 共 46 页

@NikaidoIsAGod 实时的分析会很耗费资源，因为它需要 buffer 一个 trace 的所有 span 一段时间，并且也不确定这个 trace 是否已经完结。servicegraphconnector 如果需要承接数千万的 span 肯定会很困难。不过不管哪种方案，用 connector 分析，还是用持久化的数据异步分析，都各有优劣吧没有说优先用哪种。

2025 年 8 月 4 日

回复了 RedisMasterNode 创建的主题 › 数据库 › VictoriaMetrics 开发者笔记： Traces 的查询性能与优化倾向

@NikaidoIsAGod 在第一个链接中，ClickHouse 收到的请求是由 Jaeger 分了 Batch 的，而 VictoriaTraces 的请求是直接来自于 Client 的并发请求。

2025 年 8 月 4 日

回复了 RedisMasterNode 创建的主题 › 数据库 › VictoriaMetrics 开发者笔记： Traces 的查询性能与优化倾向

@NikaidoIsAGod See:
1. https://jiekun.dev/posts/dev-note-distributed-tracing-with-victorialogs/#4-data-ingestion-%E6%80%A7%E8%83%BD
2. https://snapshots.raintank.io/dashboard/snapshot/j4g2kxHXxpOnXe8ogCyGeBCH7WgMCvPn

PS: VictoriaTraces 不是 ClickHouse ，没有物化视图的说法，也不是像 ClickHouse 那样的“数据库”。VictoriaTraces 只是一个专门设计接收和存储 OTLP Traces 数据的 Backend ，并且提供查询接口。
PPS：上面的数据写入在 VictoriaTraces 里还没有进行过优化，还有很大的提升空间。

2025 年 8 月 4 日

回复了 RedisMasterNode 创建的主题 › 数据库 › VictoriaMetrics 开发者笔记： Traces 的查询性能与优化倾向

@Nanosk 是滴，不过如文中所说，不同产品设计的 ClickHouse 的 schema 不同，所以在不同场景里的查询性能也不同，取决于产品希望往什么方向优化。

Signoz 的博客介绍的 schema 是： https://signoz.io/docs/userguide/writing-clickhouse-traces-query/
这也是配合 Signoz 里所需要的图表来设计的，具体性能相互比较一下也无妨 :) 如果后面有时间的话

2025 年 8 月 4 日

回复了 RedisMasterNode 创建的主题 › 数据库 › VictoriaMetrics 开发者笔记： Traces 的查询性能与优化倾向

> 这个可以查询展示关系图吗
@qW7bo2FbzbC0 如果说的是 Trace 查询展示 -> 现在有提供 Jaeger 的接口，可以在 Grafana 展示，或者代替 Jaeger 后端，在 Jaeger UI 展示。

如果说的是所有服务之间的调用关系总览、实时流量 -> 现在还不行，VictoriaTraces 目前只是个非常简单的 Traces Storage 。我们讨论过不同的 Service Map/Dependency Graph 的实现方案，但是还没有定论，具体或许看看哪种方案更高效才能继续推进。

2025 年 8 月 4 日

回复了 RedisMasterNode 创建的主题 › 数据库 › VictoriaMetrics 开发者笔记： Traces 的查询性能与优化倾向

@encro 希望未来有时间测试，但是现在开发时间不够用，没有多余的时间对比更多的产品

1 ... 6 7 8 9 10 11 12 13 14 15 ... 46

❮

❯