开发的MES,往往都要做生产执行跟踪扫描,这样会产生大量的扫描数据,用关系型数据库,很容易造成查询冲突的问题。
生产跟踪扫描就发生的密度是非常高的,每个零部件的加工过程,都要被记录下来,特别是在大型工厂。写入密度高,但是每次写入的记录都很少,如果程序设计是实时往数据库写入记录,那基本是每次一条记录,且写入的频率很高,导致表锁时常发生,对查询扫描日志会带来很大的压力。
解决跟踪扫描的问题,最好的办法还是用缓存(Redis),而且要共享缓存,就是不同用户使用同一个缓存空间,防止相同的零部件扫描时候,不会出现相互冲突。实际生产过程中,扫描冲突是不应该发生的,但是偏偏就是会发生,例如操作员后补扫描。程序发起扫描请求时候,先去查询缓存是否存在扫描记录,如果有,则根据缓存中的数据进行扫描校验,例如是否存在扫描的编号、重复扫描、扫描次数限制等;如果缓存中没有数据,则表明零部件从来没有被扫描过,则从数据库中加载基础信息,例如零部件的信息、工序的信息、工作中心的信息等,然后这些信息也放到缓存中,基础信息不能存放太久,一般扫描也就毫秒级完成,算1秒吧,可以设置缓存超时清除,我这里是设置10分钟的绝对超时,10分钟后重新从数据库加载基础数据。
扫描数据一直保存在缓存中,根据生产周期,也可以设定一个延期超时,例如90天,每访问一次,就重置超时时间。扫描记录,可以全部存放到内存缓存中(MemoryCache),用一个定时器往数据库中写入扫描记录,不管扫描是否成功,日志都要写入数据库保存。如果出现数据库事务冲突或者超时,则后续继续往数据库中写入,直到写入成功后,才从内存缓存中移除扫描数据。
一般来说,程序设计查询扫描记录,从缓存中查询即可,数据结构采用Hash保存:
Key: Scan_零部件编号,注意,部件编号这里是全局唯一
HashKey 工序编号
Value 扫描数据json [ {'scanTime':'2024-01-01','operator':'001'}]
因为同一个工序,可能需要扫描2次或者以上的,所以value的设计是个集合
当查询的时候,只需要把key的所有数据一次性读取出来丢去前端即可,完全不需要查询数据库。不管是写入还是读取,都比数据库快很多,代码也很简洁。当然,之类最好把操作缓存的功能封装成一个工具类,毕竟设计到内存缓存和Redis。
在常规的需求中,以上功能已经完全满足日常生产需求,但是,如果超过了90天后,扫描缓存被清除了呢?那么,就需要在数据库中查询组织数据,并重新写入到缓存中。那么,使用clickhouse查询,那是完全优于使用关系数据库,例如oracle、sqlserver、mysql、postgresql。不仅仅是构造扫描缓存,可能还要做一些分析,这里只是用最简单的一个查询来说明clickhouse和关系数据库之间的一些差异。
第一,要把数据同步到clickhouse。前边也已经踩坑了,系统使用的mssql,开发语言是C#,研究了很久,没有现成的方案同步,或者说,还没弄明白。本来打算flink-cdc同步数据,结果弄出一堆问题来,还是没搞通,所以,这个事暂时耽搁下来,自己写了一个cdc的同步工具,也就2天时间,够用就好了,凑合着,后续再研究flink。flink官方没有现成的clickhouse-sink,哪位大神指点一二!
第二,涉及到的查询关键字。用到的关键字做一个简单的说明:
limit n by exp
根据字段取第n条记录,这个关键字不能和distinct同时使用,只取其一。例如扫描记录出现重复的扫描日志,要取最后一次,这样需要配合order by才能实现。limit在clickhouse中,不仅仅用于分页,例如记录中出现(key,value)= {a,1},{a,2},order by value limit 1 by key,则会得到{a,1},第二条记录会被过滤掉。
first_value(exp1) over(partition by exp2 order by exp3)
根据字段exp2分组,exp3的顺序,取第一条记录exp1的值。例如扫描记录有5个步骤,取第一个步骤的工序编号 first_value(processid) over(partition by partId order by scanTime)
groupArray(exp1) over(partition by exp2 order by exp3 Rows BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
加载分组中字段后的exp1字段的所有值,例如部件扫描了5个工序,这个查询构造出一个列表字段,返回扫描的所有工序编号 {001,002,003,004,005},同理,用相同的方法把扫描时间也查出来,放到另外一个字段,顺序是一样的
上述关键字,会对查询条件有限制的,出现在where中的字段,必须在select中出现,类似group by的要求,这个好办,最一个子查询就可以解决了:
with tb as (select ... from ... where ...)
select * from tb
这样就完全规避了查询限制
上个例子,一般的关系数据库是很难实现这样的分组查询,当然,用后端代码也能构造出这样的结构,就另说了。
在mes中,有很多复杂的查询,生产库使用mssql,查询库使用clickhouse,实现了读写分离。mssql通过cdc与clickhouse同步,开发的cdc同步组件,同时支持rabbitmq,可以把变更数据通过rabbitmq分发出去,让其他应用做实时数据统计和分析。
clickhouse驱动在开发语言中还是很丰富的,我使用的是clickhouse.client,在nuget中直接安装即可,使用起来和ado差不多,git中有比较完整的文档。这里报告一个bug,执行executeNonQuery返回整数时候,无论是否成功,都返回0,这个就很蛋疼了!
一开始的时候,读写分离用的是ssis同步到另外一台mssql,虽然这样很方便,但是也有不方便的时候,例如要修改目标数据库的内容,会导致ssis同步报错,关键是,当数据量上亿的时候,再怎么优化也很慢,占用的磁盘空间也大,clickhouse经过压缩后,压缩比例普遍在15~25%左右,可以节约大量的磁盘空间。只要设置好表的分区分片,性能那是杠杠的。