简单的快乐 2020-05-30
最近公司要做一个用户访问日志记录统计分析的功能,需要记录日志,但是公司的产品一天大概产生百万级的日志信息,
本身日志记录信息就比较固化和简单(基本不会存在改动),平时没有什么用,就是在统计分析时需要查用一下,另外日志需要长期存储不删除!
于是问题的难点是:如何存储大量的日志信息和在此基础上做查询分析。
日志量:1天100万,一个月就是3000万,数据量大,记录多,存储和查询都难!
在我的认知中,发现关系性数据库不太行,其他的非关系性也是够呛,于是在问了下度娘,发现有人推荐使用Infobright,仔细看了几篇博客后
发现似乎可行,于是尝试玩一下Infobright。
rpm -ivh infobright-4.0.7-0-x86_64-ice.rpm --prefix=/app/software/infobrgiht/ 安装完成后,其个配置文件是 /etc/my-ib.cnf.inactive,需要拷贝一份,重命名为:/etc/my-ib.cnf,才能启动成功。默认端口是5029 2、启动和停止 # 启动命令: /etc/init.d/mysqld-ib start # 停止命令: /etc/init.d/mysqld-ib stop 3、卸载, 难免会出问题,或者安装不满意、喜欢折腾 rpm -e infobright
使用 /etc/init.d/mysqld-ib start 启动Infobright后,在linux命令行使用 mysql-ib 指令就可以连接Infobright命令行连接窗口,默认本地root用户连接没有密码。
在mysql命令窗口:指定远程连接的账户和密码设置:
--授权账户权限和密码 grant all privileges on *.* to ‘admin‘@‘%‘ identified by ‘123456‘ with grant option; --刷新权限 flush privileges;
完成后就可以使用本地的mysql客户端工具(navicat等)进行Infobright连接使用。提醒:使用服务器一定要记得防火墙,不然会导致连接不上;
在Infobright中创建数据库后,创建表:
CREATE TABLE `user_log` ( `id` bigint(20) DEFAULT NULL, `visit_name` char(15) DEFAULT NULL, `vistit_ip` bigint(20) DEFAULT NULL, `user_sex` tinyint(4) DEFAULT NULL, `user_province` tinyint(4) DEFAULT NULL, `user_area` tinyint(4) DEFAULT NULL, `visit_path` char(100) DEFAULT NULL, `visit_module` tinyint(4) DEFAULT NULL, `visit_function` char(50) DEFAULT NULL, `visit_day` tinyint(4) DEFAULT NULL, `visit_count` int(11) DEFAULT NULL, `visit_time` int(11) DEFAULT NULL ) ENGINE=BRIGHTHOUSE DEFAULT CHARSET=utf8;
从本地Mysql的user_log中导出1000万条日志记录:
SELECT * FROM user_log INTO OUTFILE ‘D:\\Template\\user_log.csv‘ FIELDS TERMINATED BY ‘,‘ OPTIONALLY ENCLOSED BY ‘"‘ LINES TERMINATED BY "\r\n";
注意:从mysql导出数据时,需要设置mysql导出的安全路径,在my.ini中mysqld下指定,secure_file_priv=导出的路径
导出的 user_log.csv 文件大小为 1.2G多。
load data infile ‘/app/document/user_log.csv‘ into table user_log FIELDS TERMINATED BY ‘,‘ OPTIONALLY ENCLOSED BY ‘"‘ LINES TERMINATED BY "\r\n";
导入时间为: Query OK, 10000000 rows affected (55.01 sec)
导入后,查询Infobright数据库存储目录的大小:只有60M,压缩比惊人!
select visit_name, count(*) from user_log group by visit_name;
本地 mysql user_log,1000万记录分组用时:首次17秒多,第二次17秒多
虚拟机 Infobright user_log,1000万记录分组查询:首次7秒多,第二次4秒多一点
Infobright里面支持所有的MySQL原有的数据类型。其中Integer类型比其他数据类型更加高效。尽可能使用以下的数据类型:
Infobright数据类型使用的一些经验和注意点:
(1)Infobright的数值类型的范围和MySQL有点不一样,比如Infobright的Int的最小值是-2147483647,而MySQl的Int最小值应该是-2147483648。其他的数值类型都存在这样的问题。
(2)能够使用小数据类型就使用小数据类型,比如能够使用SMALLINT就不适用INT,这一点上Infobright和MySQL保持一致。
(3)避免效率低的数据类型,像TEXT之类能不用就不用,像FLOAT尽量用DECIMAL代替,但是需要权衡毕竟DECIMAL会损失精度。
(4)尽量少用VARCHAR,在MySQL里面动态的Varchar性能就不强,所以尽量避免VARCHAR。如果适合的话可以选择把VARCHAR改成CHAR存储甚至转成INTEGER类型。VARCHAR的优势在于分配空间的长度可变,既然Infobright具有那么优秀的压缩性能,个人认为完全可以把VARCHAR转成CHAR。CHAR会具有更好的查询和压缩性能。
(5)能够使用INT的情况尽量使用INT,很多时候甚至可以把一些CHAR类型的数据往整型转化。比如搜索日志里面的客户永久id、客户id等等数据就可以用BIGINT存储而不用CHAR存储。其实把时间分割成year、month、day三列存储也是很好的选择。在我能见到的系统里面时间基本上是使用频率最高的字段,提高时间字段的查询性能显然是非常重要的。当然这个还是要根据系统的具体情况,做数据分析时有时候很需要MySQL的那些时间函数。
(6)varchar和char字段还可以使用comment lookup,comment lookup能够显著地提高压缩比率和查询性能。
Infobright安装和使用都比较简单,存储压缩比惊人(压缩了20多倍),查询快(1000万记录分组查询快3~4倍,这里使用的虚拟机,使用真实机器应该更快)。
强大:单机便可存储大量数据,同时能满足对这些数据进行检索!
缺点:
1)不能做更新操作,于是只能做存储固定形式的数据。
2)只能支持10个左右并发,不能存储需要大量频繁访问的数据。
3)由于只能靠自带的 load data infile 方式导入数据,因而需要编写脚本从源数据库进行数据同步导入操作。
参考文章:不分先后