New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a feature ClickHouse database support #26

Merged
merged 1 commit into from Nov 20, 2018

Conversation

Projects
None yet
4 participants
@sunsingerus
Contributor

sunsingerus commented Oct 24, 2018

ClickHouse can be tested along with all other DBses.
ClickHouse implementation is based on TimescaleDB.

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch 3 times, most recently from 4b3a0e1 to 3d467fb Oct 24, 2018

@codecov-io

This comment has been minimized.

codecov-io commented Oct 24, 2018

Codecov Report

Merging #26 into master will decrease coverage by 8.24%.
The diff coverage is 15.45%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #26      +/-   ##
==========================================
- Coverage   61.91%   53.67%   -8.25%     
==========================================
  Files          60       66       +6     
  Lines        2610     3173     +563     
==========================================
+ Hits         1616     1703      +87     
- Misses        984     1458     +474     
- Partials       10       12       +2
Impacted Files Coverage Δ
cmd/tsbs_generate_data/main.go 73.61% <0%> (-0.92%) ⬇️
query/clickhouse.go 0% <0%> (ø)
cmd/tsbs_load_clickhouse/creator.go 18.8% <18.8%> (ø)
cmd/tsbs_load_clickhouse/process.go 2.4% <2.4%> (ø)
cmd/tsbs_load_clickhouse/main.go 34.48% <34.48%> (ø)
cmd/tsbs_load_clickhouse/scan.go 78.57% <78.57%> (ø)
...bs_generate_queries/databases/clickhouse/devops.go 9.89% <9.89%> (ø)
... and 3 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cc569e5...87b78a7. Read the comment docs.

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Oct 24, 2018

Implementation of this issue

@RobAtticus RobAtticus requested review from RobAtticus and LeeHampton Oct 24, 2018

@RobAtticus

This comment has been minimized.

Member

RobAtticus commented Oct 24, 2018

Thanks for this! May be a few days before we get to this, but nice to see!

One note, for the commit msgs what I meant was "Add [a feature]" where [a feature] is replaced with what you are implementing. In this case "Add support for Clickhouse benchmarking"

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Oct 24, 2018

... a few days before we get to this...

Yes, sure, no problem at all

... "Add [a feature]" where [a feature] is replaced with what you are implementing. In this case "Add support for Clickhouse benchmarking"

Understood, sorry, missed this idea. Hope to be more precise next time

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from 3d467fb to f435010 Oct 25, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Oct 25, 2018

Fixed commit message, looks better now

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from f435010 to 72b6f0a Oct 30, 2018

@RobAtticus

First of all, thanks for putting it all this work.

I do have two concerns before I actually dig through the Clickhouse code:

  1. There are several refactorings that are not related to the Clickhouse code, which makes this PR a bigger job that it needs to be. Typically we prefer those changes to be separate PRs so that there isn't as much mixing of concerns. Especially since some of them seem to change Golang-style short names (1-2 letters even) for longer, descriptive names.
  2. Some of the formatting as changed in odd ways and some I am pretty sure are not gofmt approved. In particular, changing the format of the queries in TimescaleDB seems unnecessary and is harder to read (too much white space).

I haven't yet looked deeply at the Clickhouse code since I wanted to point these things out. Hopefully its not too much work to revert some of the more subjective changes and make sure it is run through gofmt.

selectClauses := d.getSelectClausesAggMetrics("max", metrics)
sql := fmt.Sprintf(`
SELECT

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

This format seems very weird and hard to parse.

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed. I've figured out that there is sql-formatter shipped with ClickHouse, which formats queries into the 'canonical form of ClickHouse SQL dialect' - and I've used it in new iteration.
Summary: updated

FROM cpu
WHERE %s AND time >= '%s' AND time < '%s'
GROUP BY minute ORDER BY minute ASC`,
sql := fmt.Sprintf(`

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

I would prefer these formats not to change since I find this new way much more difficult to read.

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed. In general, I've rolled back all Timescale changes because it is a rudiment of of code reverse and understanding.
Summary: updated

This comment has been minimized.

@RobAtticus

RobAtticus Nov 6, 2018

Member

I don't see these changes yet?

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Just pushed, I am writing this notes along with code review

@@ -22,22 +22,22 @@ const (
// DoubleGroupByDuration is the how big the time range for DoubleGroupBy query is
DoubleGroupByDuration = 12 * time.Hour
// HighCPUDuration is the how big the time range for HighCPU query is
HighCPUDuration = 12 * time.Hour
HighCPUDuration = 12 * time.Hour

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

was this run through gofmt? This is not the way my gofmt treats these

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed - gofmt has different view on this part than I am.
Anyway, I've run all code through gofmt, so there should not be any issues like this
Summary: updated

// significantly. The subset of the permutation should have no duplicates.
func getRandomSubsetPerm(scale, nItems int) []int {
if nItems > scale {
// getRandomSubsetPermutation returns a subset of numItems of a permutation of numbers from 0 to totalNumbersScale.

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

I don't think this func needs a name change

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed.

// getRandomHosts returns a subset of numHosts hostnames of a permutation of hostnames,
// numbered from 0 to totalHostsScale.
// Ex.: host_12, host_7, host_22 for numHosts=3 and totlaHostsScale=30
func getRandomHosts(numHosts int, totalHostsScale int) []string {

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

Changing the order of the arguments in this file worries me -- are you sure you got all the places where it may have changed?

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor
  1. Regarding changing order of the arguments - main idea is that it seems to be more human-friendly to say get 5 random items out of 12 - and I personally stumbled several times during code digging in this. Totally agree that this is subjective, but still would be nice (from my point of view) to keep it
  2. As to all the places - yes, hope to find and modify all the places - there are not so many of them and GUI helps a lot with this.

This comment has been minimized.

@RobAtticus

RobAtticus Nov 6, 2018

Member

Cool, I agree with 1. So if all the spots are gotten (since it is unexported it should only be in that package), then it's a fine change to me.

This comment has been minimized.

@RobAtticus

RobAtticus Nov 6, 2018

Member

Actually if it's not too much trouble, can you separate this out for a separate PR like you did for the other change?

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Yes, think this getRandomHosts refactoring can be extracted into separate PR. We may complete it before this big ClickHouse PR

This comment has been minimized.

@sunsingerus

sunsingerus Nov 7, 2018

Contributor

Extracted random refactoring into separate PR here
Let's move on with this new PR (random functions) and then return back to ClickHouse

@@ -24,27 +24,28 @@ func ackAndMaybeSend(ch *duplexChannel, count *int, unsent []Batch) []Batch {
// sendOrQueueBatch attempts to send a Batch of data on a duplexChannel; if it would block
// or there is other work to be sent first, the Batch is stored on a queue. The count of
// outstanding work is adjusted upwards
func sendOrQueueBatch(ch *duplexChannel, count *int, batch Batch, unsent []Batch) []Batch {
func sendOrQueueBatch(ch *duplexChannel, count *int, batch Batch, outstandingBatches []Batch) []Batch {

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

don't think this parameter name change is improvement.

In general we try to keep the names somewhat short

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed.
Summary: updated

cases := make([]reflect.SelectCase, numChannels+1)
// Using an array with Select via reflection gives us this flexibility (i.e.,
// we can either pass the whole array of cases, or the array less the last item).
cases := make([]reflect.SelectCase, numChannels + 1)

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

pretty sure this is not gofmt. While I don't like that it is smushed together, this is just going to revert back to that once gofmt is run again.

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed. gofmt did indeed smushed this piece as numChannels+1. let it be so
Summary: updated

br *bufio.Reader
statProcessor *statProcessor

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

I prefer the shorter names of sp and c, pretty common golang-ism to keep them short.

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed
Summary: updated

@@ -10,42 +10,50 @@ import (
// scanner is used to read in Queries from a Reader where they are
// Go-encoded and then distribute them to workers
type scanner struct {
r io.Reader
limit *uint64
reader io.Reader

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

keep as r

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed
Summary: updated

@@ -9,11 +9,21 @@ import (

This comment has been minimized.

@RobAtticus

RobAtticus Nov 1, 2018

Member

not sure any of the changes in this file are needed. it would also help reduce the scope of what I need to review if we remove the subjective refactorings and leave it mostly Clickhouse changes

This comment has been minimized.

@sunsingerus

sunsingerus Nov 6, 2018

Contributor

Ok, agreed.
Summary: updated

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 5, 2018

There are several refactorings that are not related to the Clickhouse code
...
some of them seem to change Golang-style short names (1-2 letters even) for longer, descriptive names.
...
to revert some of the more subjective changes...

Thanks for the review, and yes, I agree - there are some refactorings not directly related to the ClickHouse functionality. These refactorings originate from the code reversing process - when I've started with implementation, I had very vague understanding of the project, therefore each tool has to be reversed and understood. That's where small code-related refactorings are very handy. As Martin Fowler said: "Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent." So through those small refactorings comes code understanding. As to extracting those small refactoring into separated PRs - yes, of course this can be done, but those refactorings are not the goal by themselves and as Martin says: "You refactor because you want to do something else, and refactoring helps you do that other thing."

As a next step, I'll review all the changes, especially subjective ones and revert those that does not makes code better or are not liked by formatter.
I'll notify as soon as update would be ready.

@RobAtticus

This comment has been minimized.

Member

RobAtticus commented Nov 5, 2018

Great, thank you! With regards to refactorings, some of them are definitely improvements -- spelling fixes, adding code comments where they are sparse before, and some of the name changes (e.g., scaleVar -> scale). However so that the review process does not get too unruly or drawn out, I'd like to focus the PR on Clickhouse stuff.

In general I agree with the gist of what you're saying and definitely want to make the code approachable for others to contribute so we can definitely look at those changes in isolation and see which ones make sense. Just want to keep the PRs more narrowly focused.

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from 72b6f0a to 3d125dc Nov 6, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 6, 2018

PR updated, some files are completely excluded, some other are partially reverted back.

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch 3 times, most recently from d6b4551 to 67b89b3 Nov 6, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 7, 2018

Looking into code modifications and it seems to me, that there are some more smaller PRs, that can be extracted from this mega-PR (as we did with random functions). This may be the way to go.

@RobAtticus

This comment has been minimized.

Member

RobAtticus commented Nov 7, 2018

@sunsingerus You might be right. I think reviewing some things piece meal will go more smoothly.

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch 2 times, most recently from 6d0759d to 154e07a Nov 7, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 8, 2018

PR updated, one more smaller-PR extracted as a separate PR

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from 154e07a to f8edd39 Nov 8, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 8, 2018

Continue to extract separated items into smaller PRs. One more with code cleaning just added

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch 2 times, most recently from b9586d5 to 0fa4f68 Nov 8, 2018

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch 3 times, most recently from 56c99a2 to 454ea22 Nov 13, 2018

@RobAtticus

This looks mostly good to me, assuming this is the best/most efficient way to connect to Clickhouse.

Can you elaborate on whether that is the case, or if you were mostly trying to re-use TimescaleDB scaffolding here? I am curious because a cursory search finds a few Clickhouse-specific adapters for Go, so I am wondering what the benefits or drawbacks of using those are? For example:
https://github.com/mailru/go-clickhouse
https://github.com/kshvakov/clickhouse
other libs here: https://clickhouse.yandex/docs/en/interfaces/third-party_client_libraries/

Since it seems to support a variety of connection methods (HTTP, JDBC, etc), did you see if there were performance differences?

want string
}{
{
desc: "single host - no json or tags",

This comment has been minimized.

@RobAtticus

RobAtticus Nov 13, 2018

Member

seems like these test descriptions can be updated to remove mention of json

This comment has been minimized.

@sunsingerus

sunsingerus Nov 14, 2018

Contributor

Yes, agree, there is no JSON support in ClickHouse atm.
Updated.

// readDataHeader fills dbCreator struct with data structure (tables description)
// specified at the beginning of the data file
func (d *dbCreator) readDataHeader(br *bufio.Reader) {
// First N lines are header, with the first line containing: "tags:comma-separated list of tags"

This comment has been minimized.

@RobAtticus

RobAtticus Nov 13, 2018

Member

This comment leads me to believe the first line is:

tags:hostname,region,datacenter,...

rather than:

tags,hostname,region,datacenter,...

(same with the description of second through N-1 lines)

This comment has been minimized.

@sunsingerus

sunsingerus Nov 14, 2018

Contributor

Yes, I agree, this part may be confusing and not clear. Explanation rewritten.

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch 3 times, most recently from 02034ac to faf520c Nov 13, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 14, 2018

Can you elaborate on whether that is the case, or if you were mostly trying to re-use TimescaleDB scaffolding here?
... what the benefits or drawbacks of using those are? ...
... Since it seems to support a variety of connection methods (HTTP, JDBC, etc), did you see if there were performance differences?

ClickHouse exposes two API endpoints:

  1. native binary API endpoint
  2. HTTP endpoint

Native binary API is less (should actually be read as poorly) documented and thus very few driver implementations are based on it. Go adapter used is one of those native-API implementations. Native protocol is considered to be more effective and faster than HTTP. HTTP - on the other hand - is simpler, well documented and generally more welcomed by application developers. JDBC driver implementation, for example, is based over HTTP protocol under the hood. So, general idea is that native protocol is expected to be faster, however, there are no any numbers available (at my knowledge). This may be one of the possible future test-cases - compare speed of native vs HTTP protocols on the same tasks.

So my thoughts were like:

  1. Seems to be faster
  2. Close to existing code - easier to adopt.

HTTP protocol can be touched sometime later

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from faf520c to 062f003 Nov 14, 2018

db := sqlx.MustConnect(dbType, getConnectString(false))
defer db.Close()
sql := "SELECT name, engine FROM system.databases WHERE name = '" + dbName + "'"

This comment has been minimized.

@LeeHampton

LeeHampton Nov 15, 2018

Contributor

You mostly use string concatenation for dynamically generating strings in this package, whereas you use string formatting (eg fmt.Sprintf) in the query generation package. Any reason for this discrepancy? I generally find the concatenation harder to read.

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

There is no strict rule, but main idea is that short one-line-strings are constructed using concatenation, while long-multi-line strings are fmt.Sprintf-ed. It is exactly like this in creator.go under discussion, where one-line SQL queries (like short SELECT or CREATE DATABASE) are concatenated and multi-line queries (like CREATE TABLE long table spec goes here) are fmt.Sprintf-ed. The threshold after which string must not be concatenated is, I believe, line break. However, this is just personal.

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

Updated to fmt.Sprintf

// loader.DBCreator interface implementation
func (d *dbCreator) CreateDB(dbName string) error {
// Connecto to ClickHouse in general and CREATE DATABASE

This comment has been minimized.

@LeeHampton

LeeHampton Nov 15, 2018

Contributor

*Connect

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

Fixed

//cpu,usage_user,usage_system,usage_idle,usage_nice,usage_iowait,usage_irq,usage_softirq,usage_steal,usage_guest,usage_guest_nice
//disk,total,free,used,used_percent,inodes_total,inodes_free,inodes_used
//nginx,accepts,active,handled,reading,requests,waiting,writing
for _, cols := range d.cols {

This comment has been minimized.

@LeeHampton

LeeHampton Nov 15, 2018

Contributor

You have a createTagsTable function above for the tags table, why not extract a similar one for the metrics tables instead of having all of the logic in this function? Would make this function a bit easier to read (and test).

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

This makes sense

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

Updated

// https://blog.learngoprogramming.com/golang-variadic-funcs-how-to-patterns-369408f19085
// Passing a slice to variadic param with an empty-interface
// +1 is here for id
var ihellos []interface{} = make([]interface{}, len(tagRow)+1)

This comment has been minimized.

@LeeHampton

LeeHampton Nov 15, 2018

Contributor

Even though ihellos is just a placeholder to wrangle a slice into a variadic function call, I think we should change the variable names from hello and ihellos here to something that makes a bit more sense in this context ;-)

This comment has been minimized.

@RobAtticus

RobAtticus Nov 15, 2018

Member

Also, can it not be simplified to doing:

ihellos := []interface{id}
ihellos = append(ihellos, tagRow...)

Or does that not work since tagRow is a []string?

But yes, name change please :)

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

Yes, this piece of code is not nice. However, it is not easy to name this work-around with something reasonable and descriptive at the same time. Descriptive work-around naming is a challenge by itself. Hope variadicFriendlyRow would make a reasonable compromise
Updated

This comment has been minimized.

@sunsingerus

sunsingerus Nov 16, 2018

Contributor
ihellos := []interface{id}
ihellos = append(ihellos, tagRow...)

doesn't work, so no major changes in this part

@@ -0,0 +1,49 @@
package main

This comment has been minimized.

@LeeHampton

LeeHampton Nov 15, 2018

Contributor

So I know we kind of started this pattern by putting the profile stuff in tsbs_load_timescaledb, but now that we're adding general system profiling to more of the databases, I'm wondering if it might make sense to extract this to a generic package that could be re-used by all of the databases, instead of having to duplicate OS profiling calls for each separate DB that we implement?

This comment has been minimized.

@RobAtticus

RobAtticus Nov 15, 2018

Member

There's actually a few problems with this profiling, the big one being that it doesn't work if the client & server are not the same. Given that, I think it's probably better to just not include this in new databases (i.e., remove this file and its other code) until we come up with a cleaner way to do this. It probably should be removed from TimescaleDB too but I haven't bothered to do it yet.

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

Profiling removed from ClickHouse implementation

@@ -0,0 +1,160 @@
// tsbs_run_queries_clickhouse speed tests ClickHouse using requests from stdin or file.
//
// It reads encoded Query objects from stdin or file, and makes concurrent requeststo the provided ClickHouse endpoint.

This comment has been minimized.

@LeeHampton

LeeHampton Nov 15, 2018

Contributor

*requests to

This comment has been minimized.

@sunsingerus

sunsingerus Nov 15, 2018

Contributor

Updated

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch 4 times, most recently from 35bc22f to 8d65584 Nov 15, 2018

@RobAtticus

Just two nits.

Thanks for the explanations of why you chose this. I see this code was used in a blog post (I believe, unless some one else did it as well?), so presumably the performance was satisfactory.

}
// getHostWhereWithHostnames creates WHERE SQL statement for multiple hostnames.
// NB 'WHERE' itself is not included, just hostname filter clauses, ready to concatenate to 'WHERE' string

This comment has been minimized.

@RobAtticus

RobAtticus Nov 16, 2018

Member

NB -> NOTE:

This comment has been minimized.

@sunsingerus

sunsingerus Nov 16, 2018

Contributor

Ok, updated, just used to write NB as shortcut for nota bene from students' time. May be it is shorter

// more details on the item:
// https://blog.learngoprogramming.com/golang-variadic-funcs-how-to-patterns-369408f19085
// Passing a slice to variadic param with an empty-interface
var variadicFriendlyRow []interface{} = make([]interface{}, len(row)+1) // +1 here for additional 'id' column value

This comment has been minimized.

@RobAtticus

RobAtticus Nov 16, 2018

Member

variadicArgs is a shorter name

This comment has been minimized.

@sunsingerus

sunsingerus Nov 16, 2018

Contributor

Agree, this is shorter - updated.

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from 8d65584 to c7fb823 Nov 16, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 16, 2018

Thanks for the explanations of why you chose this.

My pleasure!

I see this code was used in a blog post (I believe, unless some one else did it as well?),

CTO of Altinity Alexander Zaytsev wrote blogpost with detailed comparison of databases available in the test

so presumably the performance was satisfactory.

Each of databases has an area where it shines! Timescale and ClickHouse are in general faster than Influx, however Influx simply surprised with disk usage - it seems not to need any disk space at all!

hostnameField := "hostname"
joinClause := ""
if d.UseTags {
//hostnameField = "tags.hostname"

This comment has been minimized.

@LeeHampton

LeeHampton Nov 19, 2018

Contributor

Let's get rid of this comment

This comment has been minimized.

@sunsingerus

sunsingerus Nov 19, 2018

Contributor

Yes, this part of code is not clear and looks like some development retries - I do not remember clearly what was that, sorry. Anyway, need to be cleaned.
Updated

@LeeHampton

This looks ready to merge other than 1 extremely small comment on my end. Thanks again for your work on this and for being so responsive during the PR process!

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from c7fb823 to 5129e3a Nov 19, 2018

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 19, 2018

Thank you for your efforts - really appreciate and enjoying the process!
Two small PRs more are ready - Influx shell script and docs update. And that would be all for now, have no more ready updates at the moment

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from 5129e3a to 64e5ac8 Nov 19, 2018

Add ClickHouse database support
ClickHouse can be tested along with all other DBses.
ClickHouse implementation is based on TimescaleDB.

@sunsingerus sunsingerus force-pushed the sunsingerus:clickhouse branch from 64e5ac8 to 87b78a7 Nov 20, 2018

@sunsingerus sunsingerus referenced this pull request Nov 20, 2018

Closed

Update README doc. #38

@sunsingerus

This comment has been minimized.

Contributor

sunsingerus commented Nov 20, 2018

As discussed here doc modifications are merged into this PR.
PR updated.

@RobAtticus RobAtticus merged commit 431ce18 into timescale:master Nov 20, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
license/cla Contributor License Agreement is signed.
Details
@RobAtticus

This comment has been minimized.

Member

RobAtticus commented Nov 20, 2018

Thanks again, merged!

@sunsingerus sunsingerus deleted the sunsingerus:clickhouse branch Nov 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment