“clickhouse使用者越来越多,在具体的项目中结合现有的ORM框架也是必须的,本文主要记录了在微服务中结合mybaits和mybaits-plus的过程,当然,具体的配置还需结合项目的用途再详细配置。此外,在文章的结尾介绍了使用框架出现的一些问题和提出一些解决思路,也欢迎一起探讨交流。”
引入Jar包
com.baomidou mybatis-plus-boot-starter 3.3.2 org.springframework.boot spring-boot-starter-jdbc
若只使用mybatis不需要mybaits-plus依赖:
org.springframework.boot spring-boot-starter-jdbc org.mybatis.spring.boot mybatis-spring-boot-starter
添加mybatis配置
mybatis: #定义xml存放位置 mapperLocations: classpath:mapper/*.xml #定义实体类存放位置 typeAliasesPackage: iceyung.entity configuration: #设置map-underscore-to-camel-case属性为true来开启驼峰功能 map-underscore-to-camel-case: true default-statement-timeout: 30 default-fetch-size: 100#mybatis-plus配置控制台打印完整带参数SQL语句mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
更多的参数可以参考mybatis和plus的文档,或者延续之前使用的配置即可,若有特殊的需求也可以自定义相应的配置。
mybatis-plus的BaseMapper和ServiceImpl
TestEntity:
@Data@TableName("test_zookeeper")public class TestEntity { @TableId("Id") long id; @TableField("Code") int code; @TableField("Type") String type;}
TestMapper:
public interface TestMapper extends BaseMapper {}
TestService:
public interface TestService extends IService {}
TestServiceImpl:
@Servicepublic class TestServiceImpl extends ServiceImpl implements TestService {}
测试:
testService.list()
可以得出当前表内的数据。
mybatis使用xml构建clickhouse查询语句等操作
上述的查询操作是依赖plus的特性完成的,我们也可以直接使用mybatis的xml的mapper完成clickhosue查询操作。
可在application类中声明dao接口的扫描并注入:
@MapperScan("iceyung.dao")
Dao和Mapper的定义:
public interface TestDao { TestEntity getById(Integer id); }<?xml version="1.0" encoding="UTF-8" ?> select * from test_zookeeper where Id = #{id}
重试配置
开启重试:@EnableRetry,测试:
@Retryable(value = { ClickHouseException.class }, maxAttempts = 3, backoff = @Backoff(delay = 1000L, multiplier = 1))public void call() throws Exception { testService.list(); throw new ClickHouseException(1,"test",null,"127.0.0.1",8123);}@Recoverpublic void recover(ClickHouseException e) { log.info(e.getMessage());}
- @Retryable注解
被注解的方法发生异常时会重试
value:指定发生的异常进行重试
include:和value一样,默认空,当exclude也为空时,所有异常都重试
exclude:指定异常不重试,默认空,当include也为空时,所有异常都重试
maxAttemps:重试次数,默认3
backoff:重试补偿机制,默认没有
- @Backoff注解
delay:指定延迟后重试
multiplier:指定延迟的倍数,默认为1。比如delay=5000l,multiplier=2时,第一次重试为5秒后,第二次为52=10秒,第三次为52*2=20秒
- @Recover
当重试到达指定次数时,被注解的方法将被回调,可以在该方法中进行日志处理。需要注意的是发生的异常和入参类型一致时才会回调。
一些问题
- 查询或写入失败的问题
笔者在初期使用mybatis时,出现过较多的response to fail失败错误,具体的分析可以看之前关于官方clickhouse jdbc的分析文章。在将长连接改为短连接后,目前运行较稳定,作为分析业务来看,稳定性暂时能接受,针对一些其它对稳定性要求较高的业务,推荐使用重试机制,防止因ch报错而导致当前接口出现异常,影响线上服务体验。
- 大数据量写入的性能问题
clickhouse推荐使用大批量少批次的写入模式,在使用框架进行数据写入时,笔者遇到过数据写入耗时过长等现象(写入数据量大约一次100万条,insert语句拼接valuse方式写入),改为纯jdbc写入则现象消失,所以若你也有类似的问题,建议框架只做查询使用,对于大批量的数据导入使用相应的工具或直接jdbc连接操作,避免框架在大数据量写入过程中出现耗时过久的问题。
参考资料
- spring的重试:
- mybaits结合springboot:
end