go-graphite / carbon-clickhouse

Graphite metrics receiver with ClickHouse as storage
MIT License
186 stars 48 forks source link

Refactoring configuration #91

Open Felixoid opened 3 years ago

Felixoid commented 3 years ago
  1. The SQL queries listed here are pretty much outdated because they don't suggest using any codecs which should be the default: I'm not aware of any major downsides of using codecs. For example, why not make the schema mentioned here the default?
  2. There are no recommendations on when a user doesn't need the daily index and in what cases it can be beneficial.
  3. There is no hint as to what the cache (cache-ttl = "12h0m0s") is used for and what problems it can create like getting stale data or not getting fresh data. Right now I can only hope that everything will work fine with that cache.
  4. There's no clear description of why a user might need the hash parameter (hash = "").
  5. There are no recommendations on when a user should use an inverted index and when not. (trees?)
  6. Not clear how the min-interval/age, max-interval/age parameters affect queries when there are other tables defined (I assume that other data tables can be defined because otherwise, I don't understand why these parameters even exist). CGH
  7. Not clear how graphite-clickhouse decides which data tables to query when there are multiple matching ones. GCH
  8. What is the context = [] parameter? GCH
  9. There's no clear guideline in the documentation on when zero-timestamp=true is a bad thing, you have to search through PRs to find the answer.
  10. Having some use-case examples with fine-tuned configurations would be great.