💾 Additional storage backends

[yurishkuro]

This issue is a tracker of different community-supported backends that work with Jaeger. None of them are officially support by the Jaeger project.

• ScyllaDB Why not use ScyllaDB? #197 (available)
• InfluxDB via grpc-plugin (for v1 and v2 and iOx) InfluxDB as trace storage backend #272 (available)
• Couchbase via grpc-plugin Couchbase as storage backend #1575 (available)
• ClickHouse ClickHouse as a storage backend #1438
• PostgreSQL PostgreSQL gRPC storage plugin #1895
• Alibaba Cloud Log Service Support Alibaba Cloud Log Service as storage backend  #3172
• RediSearch https://github.com/nicolastakashi/jaeger-redisearch
• Amazon S3 Google Cloud Storage(GCS) and Microsoft Azure Blob Storage support Amazon S3 as a storage backend #2633
• ConsmosDB Comsos DB as storage backend #1667
• MySQL Support mysql as backend ? #1944
• Humio Humio as storage backend #3005
• Quickwit Quickwit as a storage backend #4362
• YugabyteDB Jaeger YugabyteDB(YCQL) support #4220
• Azure Data Explorer (Kusto) [Feature]: Support Azure Data Explorer as storage #4640
• MongoDB [Feature]: Support MongoDB as a storage backend #4712
• ❌ Amazon DynamoDB DynamoDB support #421
• ❌ BigTable Bigtable Support #1208
• ❌ Elasticsearch APM data format Compatibility with Elasticsearch APM UI #1365
• ❌ Netflix Dynomite Support for Netflix Dynomite as storage backend #331
• deprecated PostgreSQL with Promscale

Relevant issue: plugin support #422 (done).

[nbettiol]

Did you remove the flags for elasticsearch in jaeger-collector? Because I'm doing a test using the image docker, which version is:

{"gitCommit":"dbd5db721fc59431b1e64874cc7d6265d89ec917","GitVersion":"v1.1.0","BuildDate":"2018-01-08T21:56:21Z"}

and I cannot see the elasticsearch flags.

[black-adder]

It looks like you're using latest instead of 1.1. We recently moved around some of the flags so that we can support plugins better #625. Using latest, you have to instead use env variable SPAN_STORAGE=elasticsearch to use the elasticsearch flags. I'd recommend that you use 1.1 since this change will be apart of 1.2 and will be documented at that time.

[nbettiol]

Thanks for the reply, yes I was using the latest version. I will use the 1.1

[fzakaria]

I would love to see a SQL option (whatever ANSI SQL that will be least vendor lock-in).
Setting up Cassandra / ElasticSearch might be too ambitious for projects that want distributed tracing but honestly don't have the TPS to warrant a distributed datastore.

[ringerc]

Since I work with PostgreSQL, I sure wouldn't complain. But honestly I'm not sure a SQL db is an optimal store for largely free-form metrics of this nature. PostgreSQL at least offers the jsonb type for indexable free-form data. If you're trying to do this in a vendor neutral way you'll land up with your own json blobs, or doing EAV, and both of those are terrible. ANSI SQL is a poor fit for variable-structured or key/value form data and you'll need some vendor extensions to get usable performance.

But you inevitably land up with someone putting an ORM on top to "abstract" the DB. Then the ORM performs terribly, gobbles memory and everyone says "the SQL backend is slow, use instead".

[pavolloffay]

Related issue to this one is #551. Upvote if you are interested in it.

[SwarnimRaj]

New related issue-
Files - #894

[wy100101]

We are looking at using BigQuery as a storage layer. Presumably this could work with a SQL storage option. SQL can be a generic way to deal with columnar data stores in a generic way. I would complain about a BigQuery specific solution, but I think there is a place for generic SQL interface beyond RDBs.

[yurishkuro]

I assume that even if some database can be treated as SQL and accessed via standard database/sql API, we still need to statically import the actual driver. Granted, this may be less maintenance than a dedicated SpanStorage implementation. However, now that the protobuf model has been merged, nothing is blocking us from moving on the storage plugin dev, eg using something like harshicorp grpc plugin framework.

[isaachier]

Our model is sufficiently simple to warrant looking into using an ORM to support a large number of backends. I'll take a look at what's available. Reread above and understand what @yurishkuro means.

[bruth]

Giving my two cents.. an ANSI SQL could work for small workloads, so may be useful for lower-throughput applications that still want to benefit from this tool.

I will also throw out there that Timescale (a Postgres extension) may be a good fit for the required high write throughput.