ClickHouse In the Storm. Part 1: Maximum QPS estimation - 最大QPS估算

ClickHouse是一个用于分析的OLAP数据库, 因此典型的使用场景是处理相对少量的请求:

• 每小时几个查询到每秒几十甚至几百个查询
• 影响大量数据(gigabytes/millions of rows)

但是它在其他情况下表现如何? Let’s try to use a steam-hammer to crack nuts, 并检查ClickHouse每秒将如何处理数千个小请求。 这将帮助我们更好地理解可能的用例范围和限制。

这篇文章分为两个部分。 第一部分介绍连接性基准测试和测试设置。 下一部分将介绍涉及实际数据的方案中的最大QPS。

ClickHouse多实例部署

本人刚接触ClickHouse两周, 难免有错误之处, 感谢指正. 另外一些参数我也不甚理解, 大家也可以先不必纠结参数, 先部署起来再说, 我的感触是部署后就会对整体结构有了一遍认识. 如果多实例都可以部署完毕, 那么生产单实例部署当然就不成问题了.

生产环境并不建议多实例部署, ClickHouse一个查询可以用到多个CPU, 本例只适用于测试环境

Zookeeper3.6.0集群部署文档

一点一点完善…

Kafka版本升级

本文档介绍kafka_2.11_2.1.1升级到2.12-2.4.1的具体操作方法. 其他版本大同小异, 详见1.5 Upgrading From Previous Versions

生成group_replication_group_seeds值的方法

网卡不统一

之前我是通过groups['mfw_test'] | map('extract', hostvars, ['ansible_all_ipv4_addresses'])这种形式, 去一个inventory group下每一个host的ansible_all_ipv4_addresses

ansible_all_ipv4_address是所有网卡上的ip, 包括手动添加的ip(例如vip)

1
2
3
4
5
6

"msg": {
    "centos-1": {
        "ansible_all_ipv4_addresses": [
            "192.168.124.136", 
            "172.16.120.10"
        ], 

canal -> kafka -> consumer. flatMessage=False
参考 canal Python客户端.
由于canal Python客户端是作为canal的client直连canal 11111端口消费数据而非消费kafka数据, 所以example不能照搬, 需要做一些修改

Python3.7.4

requriments

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

backcall==0.1.0
bleach==3.1.0
canal-python==0.4
certifi==2019.6.16
chardet==3.0.4
confluent-kafka==1.3.0
decorator==4.4.2
docopt==0.6.2
docutils==0.15.2
idna==2.8
ipython==7.13.0
ipython-genutils==0.2.0
jedi==0.16.0
parso==0.6.2
pexpect==4.8.0
pickleshare==0.7.5
pkginfo==1.5.0.1
prompt-toolkit==3.0.4
protobuf==3.9.1
ptyprocess==0.6.0
Pygments==2.4.2
readme-renderer==24.0
requests==2.22.0
requests-toolbelt==0.9.1
six==1.12.0
tqdm==4.34.0
traitlets==4.3.3
twine==1.13.0
urllib3==1.25.3
wcwidth==0.1.8
webencodings==0.5.1

最近在新公司搭了一套canal. 按照<>设置了canal.mq.topic和canal.mq.dynamicTopic

意图将一些不符合dynamicTopic匹配的语句的消息发送到一个默认的topic而避免报错INVALID_TOPIC_EXCEPTION

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# table regex
canal.instance.filter.regex=fanboshi\\..*,sysbench\\..*
# table black regex
canal.instance.filter.black.regex=.*\\.\\_.*\\_ghc,.*\\.\\_.*\\_gho,.*\\.\\_.*\\_del
# table field filter(format: schema1.tableName1:field1/field2,schema2.tableName2:field1/field2)
#canal.instance.filter.field=test1.t_product:id/subject/keywords,test2.t_company:id/name/contact/ch
# table field black filter(format: schema1.tableName1:field1/field2,schema2.tableName2:field1/field2)
#canal.instance.filter.black.field=test1.t_product:subject/product_image,test2.t_company:id/name/contact/ch

# mq config
canal.mq.topic=default_topic
# dynamic topic route by schema or table regex
#canal.mq.dynamicTopic=mytest1.user,mytest2\\..*,.*\\..*
canal.mq.dynamicTopic=.*\\..*
#canal.mq.partition=0
# hash partition config
#canal.mq.partitionsNum=3
#canal.mq.partitionHash=test.table:id^name,.*\\..*

canal.mq.flatMessage

是否为json格式
如果设置为false,对应MQ收到的消息为protobuf格式
需要通过CanalMessageDeserializer进行解码

canal.mq.flatMessage = true 生产到kafka的消息就是json的, 否则就是protobuf二进制的

[TOC]

mlanuch

使用此工具，您可以快速启动并监视本地计算机上的MongoDB环境。 它支持独立服务器，副本集和分片群集的各种配置。 单个节点或节点组可以轻松停止并重新启动。

除了下面列出的mlaunch的所有列出的参数之外，您还可以传递mongos或mongod二进制文件可以理解的任意选项，mlaunch会传递正确的参数给mongos或mongod二进制文件。 这包括-f或--config选项，以传递带有更多选项的配置文件。

未来同事跑了几个月的canal突然报下面的错, 使用了dynamicTopic. 其实我没有用过dynamicTopic, 只能搜一搜issue

关于dynamicTopic和partitionHash的说明

canal.mq.dynamicTopic 表达式说明

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

>canal 1.1.3版本之后, 支持配置格式：schema 或 schema.table，多个配置之间使用逗号或分号分隔 >例子1：test\\.test 指定匹配的单表，发送到以test_test为名字的topic上 >例子2：.*\\..* 匹配所有表，则每个表都会发送到各自表名的topic上 >例子3：test 指定匹配对应的库，一个库的所有表都会发送到库名的topic上 >例子4：test\\.* 指定匹配的表达式，针对匹配的表会发送到各自表名的topic上 >例子5：test,test1\\.test1，指定多个表达式，会将test库的表都发送到test的topic上，test1\\.test1的表发送到对应的test1_test1 topic上，其余的表发送到默认的canal.mq.topic值 >为满足更大的灵活性，允许对匹配条件的规则指定发送的topic名字，配置格式：topicName:schema 或 topicName:schema.table >例子1: test:test\\.test 指定匹配的单表，发送到以test为名字的topic上 >例子2: test:.*\\..* 匹配所有表，因为有指定topic，则每个表都会发送到test的topic下 >例子3: test:test 指定匹配对应的库，一个库的所有表都会发送到test的topic下 >例子4：testA:test\\.* 指定匹配的表达式，针对匹配的表会发送到testA的topic下 >例子5：test0:test,test1:test1\\.test1，指定多个表达式，会将test库的表都发送到test0的topic下，test1\\.test1的表发送到对应的test1的topic下，其余的表发送到默认的canal.mq.topic值 >大家可以结合自己的业务需求，设置匹配规则，建议MQ开启自动创建topic的能力

canal.mq.partitionHash 表达式说明

1 2 3 4 5 6 7 8 9

>canal 1.1.3版本之后, 支持配置格式：schema.table:pk1^pk2，多个配置之间使用逗号分隔 >例子1：test\\.test:pk1^pk2 指定匹配的单表，对应的hash字段为pk1 + pk2 >例子2：.*\\..*:id 正则匹配，指定所有正则匹配的表对应的hash字段为id >例子3：.*\\..*:$pk$ 正则匹配，指定所有正则匹配的表对应的hash字段为表主键(自动查找) >例子4: 匹配规则啥都不写，则默认发到0这个partition上 >例子5：.*\\..* ，不指定pk信息的正则匹配，将所有正则匹配的表,对应的hash字段为表名 >按表hash: 一张表的所有数据可以发到同一个分区，不同表之间会做散列 (会有热点表分区过大问题) >例子6: test\\.test:id,.\\..* , 针对test的表按照id散列,其余的表按照table散列

注意：大家可以结合自己的业务需求，设置匹配规则，多条匹配规则之间是按照顺序进行匹配(命中一条规则就返回)

其他详细参数可参考Canal AdminGuide