Infobright数据库使用

Posted gangbalei

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Infobright数据库使用相关的知识,希望对你有一定的参考价值。

最近公司要做一个用户访问日志记录统计分析的功能,需要记录日志,但是公司的产品一天大概产生百万级的日志信息,

本身日志记录信息就比较固化和简单(基本不会存在改动),平时没有什么用,就是在统计分析时需要查用一下,另外日志需要长期存储不删除!

 

于是问题的难点是:如何存储大量的日志信息和在此基础上做查询分析。

日志量:1天100万,一个月就是3000万,数据量大,记录多,存储和查询都难!

在我的认知中,发现关系性数据库不太行,其他的非关系性也是够呛,于是在问了下度娘,发现有人推荐使用Infobright,仔细看了几篇博客后

发现似乎可行,于是尝试玩一下Infobright。

 

一、简介

Infobright是开源的mysql数据仓库解决方案,引入了列存储方案,高强度的数据压缩,优化的统计计算(类似sum/avg/group by之类),
infobright 是基于mysql的,但不装mysql亦可,因为它本身就自带了一个。mysql可以粗分为逻辑层和物理存储引擎,infobright主要实现的就是一个存储引擎,
但因为它自身存储逻辑跟关系型数据库根本不同,所以,它不能像InnoDB那样直接作为插件挂接到mysql,它的逻辑层是mysql的逻辑 层加上它自身的优化器。
 

二、优势

1、高压缩比率,平均压缩比可达10:1,甚至可以达到40:1,我用infobright把3.1G的数据存成不足300M。
2、列存储,即使数据量十分巨大,查询速度也很快。用于数据仓库,处理海量数据没一套可不行。
3、不需要建索引,就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放,每块有知识网格节点记录块内的统计信息,代替索引,加速搜 索。
4、单一台服务器可以高效地读写30T数据。具有可扩展性,这里是指对于同样的查询,当数据量是10T时,它耗费的时间不应该比1T数据量时慢太 多,基本是一个数量级内。
 
注意:与有点相对应的,缺点也是蛮大的
1、没有Mysql的Insert、update、delete功能,只能通过自带的 load data infile 方式导入数据。意味着不能做常规数据,只能存储固定形式的数据。
2、对并发支持不要,也不能使用于大并发查询。意味着只能做一些统计分析等临时的场景。
3、开源版本早已经不在提供支持,只能使用老版本安装包,后期也得不到升级。
 

三、安装和使用

1、 安装
Infobright分为开源的社区版Infobright ICE和 Infobright IEE,区别请自行百度。这里使用的版本是:infobright-4.0.7-0,估计也是开源版本的最后一个版本。
下载好 infobright-4.0.7-0-x86_64-ice.rpm 包,然后拷贝到虚拟机,使用rpm指令安装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

 

 
4、修改配置配置文件(brighthouse.ini):应用于生产环境
  • ServerMainHeapSize为IB所使用内存的最大值(不包括bh_loader),如果是专用DB服务器,可适当调大,保证在业务最高峰,系统swap交换不高即可。
  • LoaderMainHeapSize由于是列式存储,IB需要将多行数据各列数据组合后写入数据块,如果导入表的列数很多,字段很长,将该值调高,加快导入速率(导入前set autocommit=0,完成后commit+复原,可大幅提高导入效率)。
  • ControlMessages 为IB错误日志记录类型,实验环境设为4有利于排错,成熟的生产环境设为2或3即可。
  • KNFolder 为知识网格所在目录,通常情况下大小都很小,直接放在data目录下即可。
  • 根据自身的物理内存大小修改ServerMainHeapSize、ServerCompressedHeapSize,LoaderMainHeapSize的值,文件中已经给出样板。

 

四、使用Infobright

1.授权用户

使用 /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连接使用。提醒:使用服务器一定要记得防火墙,不然会导致连接不上;

 

2. 创建表 

在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 "
";

 注意:从mysql导出数据时,需要设置mysql导出的安全路径,在my.ini中mysqld下指定,secure_file_priv=导出的路径

技术图片

导出的 user_log.csv 文件大小为 1.2G多

 

 

3.导入数据到Infobright中

load data infile /app/document/user_log.csv into table user_log FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY " LINES TERMINATED BY "
";

导入时间为: Query OK, 10000000 rows affected (55.01 sec)

导入后,查询Infobright数据库存储目录的大小:只有60M,压缩比惊人!

 

4.查询对比

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类型比其他数据类型更加高效。尽可能使用以下的数据类型:

TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT
DECIMAL(尽量减少小数点位数)
DATE ,TIME
效率比较低的、不推荐使用的数据类型有:
BINARY VARBINARY
FLOAT
DOUBLE
VARCHAR
TINYTEXT TEXT
 

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 方式导入数据,因而需要编写脚本从源数据库进行数据同步导入操作。

 

 

参考文章:不分先后

 

以上是关于Infobright数据库使用的主要内容,如果未能解决你的问题,请参考以下文章

免费数据仓库——Infobright、Hadoop/Hive 还是啥?

Infobright列式存储数据库

FAQ系列 | infobright下如何使用utf8字符集

Infobright数据库使用

Infobright数据库使用

MySQL开源引擎infobright数据仓库解决方案