6 ms·

We're planning to deploy ClickHouse from Yandex[0]. Would like to hear from anyone who has it in production already, and what is your experience with it. [0] h

We're planning to deploy ClickHouse from Yandex[0]. Would like to hear from anyone who has it in production already, and what is your experience with it. [0] https://clickhouse.yandex/ https://clickhouse.yandex/

gaahrdner 8y ago
Cloudflare[0] uses ClickHouse extensively, might want to reach out to them. [0]https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/ https://blog.cloudflare.com/http-analytics-for-6m-requests-p...
- 11thEarlOfMar 8y ago
  TYVM
MrBuddyCasino 8y ago
We‘re using it at Instana, its very fast, robust and scales linearly with node count. Make sure to batch inserts, it doesn’t like many small inserts.
shaklee3 8y ago
Any reason you choose clickhouse over druid or Pinot?
- mfrye0 8y ago
  I've evaluated Timescale, Clickhouse, Druid, and Pinot for our own use case. Druid and Pinot have a lot of moving parts. If I remember correctly, Druid was something like 6-8 different nodes for different parts of the ingestion / querying processes. So it's going to be a lot of upfront and ongoing dev ops work. Clickhouse is interesting because it seems to just "work". One thing to deploy and you just increase the number of nodes as you scale.
  - shaklee3 8y ago
    To be fair to druid, those 6 are really just three types. They recommend deploying them in groups of 3 types: http://druid.io/docs/latest/design/processes.html http://druid.io/docs/latest/design/processes.html
- bsg75 8y ago
  Simplicity. In our case, the simple deployment and management of Clickhouse is a key feature. It is masterless [1] with no namenodes or coordinators, so each machine looks the same, and there is only one process to manage. If you rely on its replication mechanism for sharding, Zookeeper becomes necessary, but writing directly to nodes in an orderly fashion is also an option (as we are). [1] This means nodes are not aware of what each other contain, so queries hit all nodes with some maybe having no work to do. Depending on your workload this may or may not be a concern.
  - tepidandroid 8y ago
    This is interesting. In effect, you're doing your sharding client-side? What do you plan to do if you need to add new nodes and/or you need to rebalance nodes due to concentrated data access patterns? How do you handle cross-node queries like joins?
    - bsg75 8y ago
      > In effect, you're doing your sharding client-side? Correct. Some ETL inserts to specific nodes when sharding is necessary, in other cases Kafka engine tables on a group of nodes subscribe to common topics, and we simply let the whole cluster participate in queries. This works just fine when table scans are acceptable. Rebalancing is a missing option here, short of moving partitions manually. But in my specific use cases, I have not yet needed to rebalance across nodes. Note using native Clickhouse replication is still an option if we need it. One cost to it is the extra work needed in the database cluster, so addressing it in an eariler layer works for us. > How do you handle cross-node queries like joins? If I understand your question, since we are using the Distributed view type across the cluster definition, a query on any node will receive data from the others as part of a join-less SELECT, and federate on the node with the client connection. We are not doing any database-side JOINs currently. Plans are to augment data in ETL, or join data post-query (potentially Spark). Clickhouse dictionaries handle simple cases.
      - tepidandroid 8y ago
        Thanks for the details, this is very helpful.
tepidandroid 8y ago
I would love to use Clickhouse, if only it has some kind of Cassandra-esque node-to-node replication mechanism. I'm loathe to bring in something heavy like Zookeeper for that. It would also be ideal if they could accelerate the data ingestion process somehow without the need to buffer chunks with yet another moving piece like Kafka. I guess ideally, I'm looking for some kind of standalone HTAP system minus transactional guarantees.
- valyala 7y ago
  Clickhouse cluster can run without Zookeeper and without replication. Data durability may be provided by using durable storage such as Google Compute Engine disks [1]. Data ingestion process may be accelerated without resorting to Kafka - just insert data into Buffer table [2]. [1] https://cloud.google.com/compute/docs/disks/#pdspecs https://cloud.google.com/compute/docs/disks/#pdspecs [2] https://clickhouse.yandex/docs/en/operations/table_engines/buffer/ https://clickhouse.yandex/docs/en/operations/table_engines/b...
hodgesrm 8y ago
There's a ClickHouse meetup 4 June in the Bay Area. Good place to find out more about ClickHouse. Google 'Clickhouse SF Meetup'. Disclaimer: I'm an organizer.

gaahrdner 8y ago

Cloudflare[0] uses ClickHouse extensively, might want to reach out to them. [0]https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/ https://blog.cloudflare.com/http-analytics-for-6m-requests-p...

11thEarlOfMar 8y ago
TYVM

MrBuddyCasino 8y ago

We‘re using it at Instana, its very fast, robust and scales linearly with node count. Make sure to batch inserts, it doesn’t like many small inserts.

shaklee3 8y ago

Any reason you choose clickhouse over druid or Pinot?

mfrye0 8y ago
I've evaluated Timescale, Clickhouse, Druid, and Pinot for our own use case. Druid and Pinot have a lot of moving parts. If I remember correctly, Druid was something like 6-8 different nodes for different parts of the ingestion / querying processes. So it's going to be a lot of upfront and ongoing dev ops work. Clickhouse is interesting because it seems to just "work". One thing to deploy and you just increase the number of nodes as you scale.
- shaklee3 8y ago
  To be fair to druid, those 6 are really just three types. They recommend deploying them in groups of 3 types: http://druid.io/docs/latest/design/processes.html http://druid.io/docs/latest/design/processes.html
bsg75 8y ago
Simplicity. In our case, the simple deployment and management of Clickhouse is a key feature. It is masterless [1] with no namenodes or coordinators, so each machine looks the same, and there is only one process to manage. If you rely on its replication mechanism for sharding, Zookeeper becomes necessary, but writing directly to nodes in an orderly fashion is also an option (as we are). [1] This means nodes are not aware of what each other contain, so queries hit all nodes with some maybe having no work to do. Depending on your workload this may or may not be a concern.
- tepidandroid 8y ago
  This is interesting. In effect, you're doing your sharding client-side? What do you plan to do if you need to add new nodes and/or you need to rebalance nodes due to concentrated data access patterns? How do you handle cross-node queries like joins?
  - bsg75 8y ago
    > In effect, you're doing your sharding client-side? Correct. Some ETL inserts to specific nodes when sharding is necessary, in other cases Kafka engine tables on a group of nodes subscribe to common topics, and we simply let the whole cluster participate in queries. This works just fine when table scans are acceptable. Rebalancing is a missing option here, short of moving partitions manually. But in my specific use cases, I have not yet needed to rebalance across nodes. Note using native Clickhouse replication is still an option if we need it. One cost to it is the extra work needed in the database cluster, so addressing it in an eariler layer works for us. > How do you handle cross-node queries like joins? If I understand your question, since we are using the Distributed view type across the cluster definition, a query on any node will receive data from the others as part of a join-less SELECT, and federate on the node with the client connection. We are not doing any database-side JOINs currently. Plans are to augment data in ETL, or join data post-query (potentially Spark). Clickhouse dictionaries handle simple cases.
    - tepidandroid 8y ago
      Thanks for the details, this is very helpful.

tepidandroid 8y ago

I would love to use Clickhouse, if only it has some kind of Cassandra-esque node-to-node replication mechanism. I'm loathe to bring in something heavy like Zookeeper for that. It would also be ideal if they could accelerate the data ingestion process somehow without the need to buffer chunks with yet another moving piece like Kafka. I guess ideally, I'm looking for some kind of standalone HTAP system minus transactional guarantees.

valyala 7y ago
Clickhouse cluster can run without Zookeeper and without replication. Data durability may be provided by using durable storage such as Google Compute Engine disks [1]. Data ingestion process may be accelerated without resorting to Kafka - just insert data into Buffer table [2]. [1] https://cloud.google.com/compute/docs/disks/#pdspecs https://cloud.google.com/compute/docs/disks/#pdspecs [2] https://clickhouse.yandex/docs/en/operations/table_engines/buffer/ https://clickhouse.yandex/docs/en/operations/table_engines/b...

hodgesrm 8y ago

There's a ClickHouse meetup 4 June in the Bay Area. Good place to find out more about ClickHouse. Google 'Clickhouse SF Meetup'. Disclaimer: I'm an organizer.