ClickHouse实战问题总结

• 对于大多数正式的任务，应该使用MergeTree族中的引擎。 创建单表建议首选MergeTree引擎(ClickHouse中最强大的表引擎当属 MergeTree引擎及该系列(*MergeTree)中的其他引擎。)，创建分布式表建议选择MergeTree + Distributed引擎，若保证高可用，建议选择ReplicatedMergeTree + Distributed引擎；
• 针对当前ClickHouse版本，Nullable(DateTime)不生效，插入空值报错；
• 在SQL解析方面，ClickHouse是大小写敏感的，这意味着SELECT a 和 SELECT A所代表的语义是不同的(经测试的确如此)；
• 分布式表之间关联没问题，但分布式表跟普通表关联进行left join时报普通表不存在。解决办法:要将普通表也在分布式每个实体表的机器上都创建并有数据；
• 分布式表只是一个视图，要在每个机器上建立实体表，然后进行关联形成一个聚合视图，同时若与其它分布式表进行关联查询的话，需要在每个涉及的机器上都建立分布式表；
• 创建分布式表，若使用userId等作为sharding_key，这个建的字段类型必须为Int或Uint类型，否则使用rand()函数作为sharding_key，但rand()方式可能会造成数据不均衡。数据分片键(sharding_key)的概念就是数据插入时是根据什么原则分配到具体分片上；
• 通过分布式引擎可以像使用本地服务器一样使用集群。但是集群不是自动扩展的,必须编写集群配置到服务器配置文件中;
• ClickHouse用户加密码后，若要使用分布式表，不仅要在user.xml中设置密码，同时要在config.xml中设置<listen_host>0.0.0.0</listen_host>，还要在config.xml/metrika.xml中设置数据分片的用户名、密码；
• 进行关联查询时，将小表放在右边比小表放在左边，查询效率会变快；
• ClickHouse分布式表的本质并不是一张表，而是一些本地物理表（分片）的分布式视图，本身并不存储数据，如果写入，会把请求丢到集群里的节点（有算法控制），如果查询，会做查询转发再聚合返回；
• ClickHouse的分布式是一个彻底手动挡的分布式，无论是分布式集群的搭建还是还是表引擎的维护都能体现引擎的定制化感觉，相较于其他分布式比如Hadoop等分布式来说，需要手动维护的内容较多；
• ClickHouse的节点变动，无需重启，会自动加载。利用利用这个特性，我们先去掉一个节点的配置，再加上这个节点的配置（DNS变更后），即可不重启就完成Fail Over；
• ClickHouse不支持NVL()、DECODE()等函数；
• SQL中有聚合函数时，聚合指标不能同时出现在两个select字段中；
• 应该慎用Nullable类型，包括Nullable的数据表，不然会使查询和写入性能变慢。因为在正常情况下，每个列字段的数据会被存储在对应的[Column].bin文件中。如果一个列字段被Nullable类型修饰后，会额外生成一个[Column].null.bin文件专门保存它的Null值。即在读取和写入数据时，需要一倍的额外文件操作；
• 不要在大结果集上构造 虚拟列：select id, pv, uv, pv/uv rate from app.scene_model，虚拟列非常消耗资源浪费性能，拿到pv uv后在前端显示时构造比率；
• ClickHouse 数据目录的配置默认在config.xml中的 path 字段，默认目录为/data/clickhouse/clickhouse-server/data；
• 单表查询性能相比Presto、Impala等要快，所以单表查询建议使用ClickHouse；多表join查询性能相比Presto、Impala要若，所以多表join查询建议使用Presto；
• 数据写入分布式表其实是先写入接入的那台机器，然后对数据进行分发，因此性能较低，不建议直接将数据写入分布式表中。建议在写入之前上游进行划分分表操作，这样直接分开写入到不同的分片上，磁盘的压力就会变成原来的1/n；
• 最新版ClickHouse已经解决了Local Top非全局Top的问题，但牺牲了一定的执行性能，大分布式进行表join容易导致内存溢出；
• 数据量成指数级增长的情况下，建议针对不同的维度，建立对应的预聚合，物化视图，这样可以提升查询效率，用空间换时间；
• 物化视图是实时的；
• 后台查询之前对内容ID进行路由，直接访问目标Shard，减少(n-1)/n的负载，大量缩短查询时间，能够提升用户体验；
• 建议在后台做查询缓存，即相同查询的SQL结果缓存起来（目前腾讯做的是1分钟缓存），这样有相同查询结果的信息可以大大缩短查询时间。
  

最新经典文章，欢迎关注公众号

————————————————
链接：https://blog.csdn.net/u013473512/article/details/114918013

谢谢分享