Infobright使用总结

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: Infobright使用总结

INFOBRIGHT介绍

在这里,我将结合我自己的使用以及对开源数据仓库的了解,INFOBRIGHT做下简单的介绍。

INFOBRIGHT产品分为社区版ICE和企业版IEE。相信大家对ICE都有很多的了解。ICE具备了INFOBRIGHT大部分的功能,我列举如下:

1. 超高的压缩比例。 普通10:1, 在极限情况下可以达到40:1 甚至更高。

2. 超强劲的数据导入性能。 ICE 有自己专业的数据导入工具BHLOADER, 不过受到了一些限制,比如不能利用到多核导入。

3. 超强的数据查询能力。 特别适合对于数据统计以及报表生成类得查询。

4. 超大的单表存放规模。 正是因为第一点,超强的压缩比,所以可以存放大量的数据, 节约了磁盘的存储,大大节省了成本。

5. 申请了专利的知识网格体系,这点是其他开源数据仓库哪怕是商业的数据仓库产品所没有的。

6. 与主要的BI分析工具的兼容性。 比如Pentaho等等。

但是除了以上的优点外, ICE 有以下的限制:

1. 不支持数据更新。 这个限制对于我们即要求查询性能外还要对数据库进行写入的需求, 造成了很大的不变。 这个估计是很多人试用后放弃试用ICE的第一个原因。

2. 不支持对多核的使用。 不但不支持查询的多并发,而且连导入导出也没有这样的支持。这个也是放弃ICE的一个原因。 谁也不愿意自己的强劲的硬件只能被用到1%,这样也会被老板给骂死的,他的钱不能白白的被这样折腾。

3. 只能单机使用,不具备任何的复制以及扩展。 这点对于我们现在的大规模海量数据情何以堪那?

所幸的是, INFOBRIGHT提供了商业版本IEE。IEE支持ICE的所有优点,并且弥补了他的不足, 放宽了对他的限制。 特别是早新的版本4.0.x里面提供了一套令人更加兴奋的工具:DLP---分布式数据导入工具。

DLP 优点如下:

1. 减轻了数据库服务器的负载,使它能处理更多的请求。

2. 对应用完全透明, 不用编写额外的代码来处理复杂的导入工作。

3. 数据库的导入时间随着DLP部署的机器的增多二线性减少。当然,这些机器可以是非常廉价的PC服务器,也可以是旧的机器。节省了大量的成本。

4. 减少了对网络带宽的占用。 DLP在导入之前对原始数据已经进行了高效的压缩。

安装

 rpm -i infobright-migrator-1.0-x86_64-eval.rpm

 rpm -i infobright-4.5.0-4-x86_64-eval.rpm

 rpm -i infobright-dlp-1.4-x86_64-iee.rpm

默认参数如下:

 

Current config file: [/etc/my-ib.cnf]
Current brighthouse.ini file: [/usr/local/infobright-4.5.0-x86_64/data/brighthouse.ini]
Current datadir: [/usr/local/infobright-4.5.0-x86_64/data]
Current CacheFolder in brighthouse.ini file: [/usr/local/infobright-4.5.0-x86_64/cache]
Current socket: [/tmp/mysql-ib.sock] 
Current port: [5029]

可以改变默认参数

 

/usr/local/infobright/postconfig.sh

它是用来改变安装的datadir,CacheFolder, socket和port的

把认证文件 iblicense-*.lic 放到 /usr/local/infobright/ 目录下

 

开启或者关闭服务的命令:

/etc/init.d/mysqld-ib start

/etc/init.d/mysqld-ib stop

 

连接

/usr/bin/mysql-ib

 

卸载infobright的命令:

rpm -e infobright

设置root密码

 

/usr/local/infobright/bin/mysqladmin -u root password 'pass'

 

允许远程客户端通过root登录infobright

# mysql-ib -u root -p
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'pass' WITH GRANT OPTION;
mysql> FLUSH PRIVILEGES;

 

DLP工具所在目录

/opt/infobright/tools/distributed-load-processor

在插表时遇到

ERROR 1070 (42000): Too many key parts specified; max 0 parts allowed

是因为有索引导致的,去掉索引就可以了,BRIGHTHOUSE存储引擎建表时不能有AUTO_INCREMENT自增、unsigned无符号、unique唯一、主键PRIMARY KEY、索引KEY。

 

Infobright目录结构:/data/infobright/

解压后,你会发现这不就是一个MySQL吗,infobright-3.3.1是集成于mysql-5.1.40,很自然的就会把infobright理解成MySQL的一个特殊引擎,这又进一步体现出MySQL具有可插拔引擎接口的特点。

cache目录:README里面说是临时文件生成和存放地,但是我一直没有看到里面有文件按出现。

data目录:

bh.err  ——  错误日志这个和MySQ记录启动关闭信息以及一些错误和警告提示,但在infobright中它还有一个特殊的任务就是记录执行计划,因为 infobright没有explain/profile这样的工具。

brighthouse.ini   ——    infobright的配置文件,里面有使用内存大小的分配规则、选择是否开启执行计划记录功能等。

内存占用设置在brighthouse.ini  里

# ServerMainHeapSize - Size of the main memory heap in the server process, in MB
ServerMainHeapSize=6000
# LoaderMainHeapSize - Size of the memory heap in the loader process, in MB.
LoaderMainHeapSize=800

brighthouse.log  ——    这个日志中记录了infobright引擎启动和关闭操作,已经我们在导入数据是遇到的错误。

brighthouse.seq ——    这个文件中记录的数字我也不是很理解;查了下,说是被使用的最大的表的号码。我的那个文件里面是708,在BH_RSI_Repository中,可以找到这样的数字,但是我没有看到708,最大的那个数字就是707。

general_query.log ——  这个和MySQL中的那个什么都能记录下来的日志一样。

slow_query.log  ——   慢查询日志,里面有那个用户在什么时间那条语句的执行时间和锁消耗的时间。

BH_RSI_Repository子目录:里面都是rsi文件,似乎和Knowledge Grid相关,一类是HIST开头的,一类是CMAP开头的。

相关数据库子目录:里面分别是对应各个表的frm文件,和bht目录。

 

/usr/local/infobright/bin/mysqldump  备份脚本

 

一旦有数据插入就会执行多条类似这样的语句:

/usr/local/infobright-4.5.0-x86_64/bin/bhloader bhload-info-13499-1463118653-17607 /tmp/bhload-info-13499-1463118653-17607

 

如何调整infobright的存储目录结构

/etc/init.d/mysqld-ib stop

cd /usr/local/infobright

sh postconfig.sh

(1) Move existing data directory to other location,

(2) Move existing cache directory to other location,

(3) Configure server socket,

(4) Configure server port,

(5) Relocate datadir path to an existing data directory.

 

    Datadir       Path to the directory where tables will be created and stored. Use a high-performance storage such as a RAID.

    Cachedir     Path to the directory where temporary files will be created and stored. Should be located on a fast drive, possibly not the same as the data.

                    Allow at least 100 GB of free space (depending on database size).

                         Note: The Cachedir option is disabled when the Datadir option is chosen. To change

                                  Cachedir, rerun the postconfig utility and do not choose Datadir.

    Port          Listening port for the Infobright server instance.

    Socket        Socket connection point for client connections. (The socket connection point will be created during the Infobright installation.)

/etc/init.d/mysqld-ib start

 

//emoji符号会导致插入不进去,IB并且不抛出任何错误

老少皆知的方法

   1. comment 'lookup':对于选择少于10000的字符串型字段,这是一个非常实用的优化

 

列式存储,无需创建索引和分区,再也不用关心索引失效了!

那么,货币流表分表是不是对IB的误用?

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
6月前
|
存储 关系型数据库 MySQL
Mysql第七天,存储引擎
Mysql第七天,存储引擎
96 0
Mysql第七天,存储引擎
|
4月前
|
存储 关系型数据库 数据库
MySQL设计规约问题之是否可以使用分区表
MySQL设计规约问题之是否可以使用分区表
|
4月前
|
SQL Oracle 关系型数据库
MySQL单表千万级数据查询优化大家怎么说(评论有亮点)
单表千万级数据是MySQL查询的一个坎,可能还不是天花板。“一个人走的慢,一群人走的快”,通过讨论可以发现MySQL千万数据的全貌大概是怎样的。
197 0
|
存储 算法 固态存储
三高Mysql - Inndb存储引擎和索引介绍
内容为慕课网的《高并发 高性能 高可用 MySQL 实战》视频的学习笔记内容和个人整理扩展之后的笔记,这一节的内容是对于InnoDb的存储结构进阶了解,同时介绍为什么会使用B+索引作为最终数据结构,但是实际上InnoDb在具体实现中也并没有完全遵循B+的格式,而是在内部做了很多“手脚”,这也是所谓理论和实践之间的差异。
71 0
|
存储 算法 关系型数据库
MySQL · 引擎特性 · Infobright 列存数据库
简介 系统架构 存储引擎 优化器和执行器 数据装载和卸载 领域知识 查询优化 简单场景的示例 小结 存储结构 Data Pack Knowledge Node 数据压缩 总结 简介 Infobright 是一个面向 OLAP 场景的开源列
4006 0
|
存储 算法 关系型数据库
三高Mysql - Inndb存储引擎和索引介绍(上)
三高Mysql - Inndb存储引擎和索引介绍(上)
111 0
|
存储 固态存储 前端开发
三高Mysql - Inndb存储引擎和索引介绍(下)
三高Mysql - Inndb存储引擎和索引介绍(下)
169 0
|
SQL 存储 缓存
MySQL 大表优化方案(长文)
单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候My
MySQL 大表优化方案(长文)
|
SQL Web App开发 存储
MySQL Federated存储引擎引起的慢SQL优化
这个案例并不是我遇到的,但是我的工作生产环境中有使用到federated存储引擎,所以记录一下。 有一条SQL部分截取内容如下,执行约268秒才能出结果: 从这条SQL的执行计划中可以看出来mego.trade_order并没有出现在table列中,经查看,mego.trade_order是一个Federated存储引擎,类似Oracle的DBlink,在本地只是个链接的形式存在,实际数据文件并不存在。
3646 0
|
存储 安全 Java
MySQL常见的两种存储引擎:MyISAM与InnoDB的爱恨情仇
MyISAM更适合读密集的表,而InnoDB更适合写密集的的表。 在数据库做主从分离的情况下,经常选择MyISAM作为主库的存储引擎。
3782 0
下一篇
无影云桌面