[jaeger-v2][storage] Add Configuration For ClickHouse

[mahadzaryab1]

As a first step in adding support for ClickHouse, we want to define the configuration that Jaeger will expose for users to create a connection to ClickHouse. The configurable options can be viewed here.

[mahadzaryab1]

@yurishkuro thoughts on if we should be using the native clickhouse interface through go-clickhouse or the standard database/sql package in Go to connect to clickhouse (ref: https://clickhouse.com/docs/en/integrations/go#clickhouse-go-client).

• Native example
• database/sql

[yurishkuro]

I don't have an opinion, did not research this question. Note that we already have an implementation in #4941

[haanhvu]

@yurishkuro thoughts on if we should be using the native clickhouse interface through go-clickhouse or the standard database/sql package in Go to connect to clickhouse (ref: https://clickhouse.com/docs/en/integrations/go#clickhouse-go-client).

• Native example
• database/sql

I thought of this when doing #4941 too. The reason I chose database/sql back then was because OTel ClickHouse exporter used it, and this exporter had been widely used and tested by the community: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter

[yurishkuro]

According to the docs the sql/database API is the least performant of the three APIs, so we should avoid it. It would be interesting to see how more complicated the ch-go usage would be, as that's the most performant way, but the middle ground with clickhouse-go is probably ok.

Another option is to use ch-go for writing and clickhouse-go for reading.

Cc @mahadzaryab1

[adityachopra29]

Working on this issue.

[LGDHuaOPER]

Good!

[adityachopra29]

According to the docs the sql/database API is the least performant of the three APIs, so we should avoid it. It would be interesting to see how more complicated the ch-go usage would be, as that's the most performant way, but the middle ground with clickhouse-go is probably ok.

Another option is to use ch-go for writing and clickhouse-go for reading.

Cc @mahadzaryab1

@yurishkuro Just wanted a confirmation as to what approach we will be taking for clickhouse.(the "ch-go for writing and clickhouse-go for reading." one or simply clickhouse-go one.
I have learned about the problem and the approach to storing data(ie as a single table) (as described here), about clickhouse, and was working on the plugin/storage/clickhouse/options.go.

[yurishkuro]

ch-go for writing and clickhouse-go for reading

yes

[zzzk1]

@yurishkuro Should we first introduce the config in pkg/clickhouse and create the configuration, allowing the storage/clickhouse /options to be reused similarly to how they are implemented in Elasticsearch and Kafka?

[adityachopra29]

@yurishkuro Should we first introduce the config in pkg/clickhouse and create the configuration, allowing the storage/clickhouse /options to be reused similarly to how they are implemented in Elasticsearch and Kafka?

Yes. This makes sense. I see now that the badger storage location is outdated and also needs to refactored to be in the pkg/badger just like Cassandra, ES, and Kafka. I'll make that change into the pr.

[yurishkuro]

I'm closing this, since it invites PRs that are not needed at this time. We start with implementation and integration tests, not with configuration which we have no way of validating.