PostgreSQL确实有过人之处,MySQL这个事情很难办到!

体娱   2024-08-09 20:00   山东  
公司的TeamCenter系统,需要跟U8对接,就写了传输接口。
世界上没有完美无缺的程序,都会出bug。有时候是U8那边的BOM件没有正确建立,有时候是零件树结构不正确。
为了查找原因,就需要看看哪一个环节出了问题?
我就去看Log文件。
但是Log文件的分布比较零散,
一种是tc.log,这个是TeamCenter本身的日志文件,采取“每日滚动”机制,每天先把昨天的内容重命名为一个带日期的文件,这个日期就是昨天的日期,然后新建一个新的tc.log,很多人都知道这种形式就是所谓的“Rolling”日志形式。
这种tc.log存在一个固定的目录下面,叫logs。
另外一种是中间转化程序的log,他包含零件建立、传输情况等动作的log。它存放在另外一个目录下面。
上面两种日志,都可以查找到零件的编码,基本从附近行就可以看到操作的结果,非常方便分析。
但是,唯一的缺点就是他们分布在不同的目录下面。如果查找问题,我需要从这么多日志文件里面去找,需要打开多个文件,一个一个去排查。
这个时候,我就想了一个办法。
我写了一个Go程序,每天定时把日志文件写入到PG数据库里面,这样查找直接用like就可以找到了。
是的,真的方便了很多。
另外,还写一个WPF界面,可以从窗口直接发送指令到Go端,让它去服务器爬数据,完成日志入库,方便查找;也可以从这里直接查找!
不得不说,情况大有好转。
但是,性能问题开始凸显。因为一个日志文件可能就3M大小,我放在一个text字段里面,即使是数据库查询,速度也有点慢!
每次查询,我都明显感觉等待好久!
那我怎么办呢?
给数据库上索引吧!
结果发现,text字段类型只能上hash索引,对于查找基本没意义。
另外,我发现PG的text还支持所谓“全文索引”,但是很可惜,它有一个限制条件,字段值最大为1024,超过这个数值就没有办法了,只有全文索引这前024个!
至此,情况仿佛陷入了僵局!
但是,秉着“永不放弃”的精神,和“来都来了,都这样了”的不要脸情怀,我觉得继续寻找。
后来,我发现了一个PG的插件pgroonga插件。

这个插件的自我介绍是“fulltext search engine”-全文搜索引擎。
既然如此,那就安装一个pg的这个extension,试试水!
安装还是挺简单的。
安装完成,create extension来加载插件!
随后,用pgroonga来建立索引,这个时间确实比较长,文件也有点多的缘故。
在建立完成之后,我测试了一下,大概1-2秒就可以搜索到结果了!
至此,算是比较圆满的完成了构想!
从这个事情,我体会到了PostgresSQL强大的插件机制。虽然用过这么久的MySQL,但是我从来没有见过这样功能强大的插件。所以,我觉得如果联合使用软件,把Mysql的数据同步到ElasticSearch里面,再进行查询或许也能达到这样的效果吧!
但PG在自己的体系之内就能完成,可见其先进性!
我是明月,
PostgresSQL还挺好用的!

明月三千
将进酒,杯莫停。与君歌一曲,请君为我倾耳听。荔枝成为linux大师!
 最新文章