注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

zjcjack的博客

 
 
 

日志

 
 

infobright实战  

2012-04-04 22:23:23|  分类: infobright |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

之前的简介架构分析之后,我做了一些实践,验证infobright用于大量数据存储与查询的可行性。

我是从这里下载的infobright开源版本ICE3.1(据说刚出的ICE3.2查询速度更快)。用DEB包在ubuntu装过一个,后来觉得内存不够大体现不出它的优势,就下载了源代码包在64位的gentoo服务器编译安装了一个。编译源代码的话,按照压缩包里的README文件做就行了,基本没遇到什么问题。

装好之后,要作一些配置,才能使它发挥出最大的效能。我从源码安装好之后在/usr/local/infobright/share/mysql/有一个brighthouse.ini文件,那就是用来配置infobright运行时参数的(DEB包安装的没注意找放在哪)。把这个文件拷贝到infobright服务配置文件my-ib.conf定义的data-dir目录下。

brighthouse.ini的几个主要参数如下:

  • ServerMainHeapSize:服务进程的主堆栈空间,存储临时数据,如果可能,尽量把它设置得大一些,以免跟磁盘的IO过多。
  • ServerCompressedHeapSize:服务进程的压缩堆栈空间,存放压缩数据。
  • LoaderMainHeapSize:infobright独有的数据loader进程的堆栈空间。

自带的brighthouse.ini有一些根据不同系统的推荐值,要注意给系统其它进程留下空间,以免得使用swap区会使效率大大下降。我32G内存的系统当16G来用,设置参数为:

  • ServerMainHeapSize:10GB
  • ServerCompressedHeapSize:1GB
  • LoaderMainHeapSize:800MB

内存自然是越大越好。但在我的实验环境下服务进程从未超过5G,可以认为infobright应对我实验这些数据量完全不在话下。

运行服务:sudo /usr/local/infobright/bin/mysqld_safe –defaults-file=/etc/mysql/my-ib.cnf –user=mysql

以下对一个包含7亿条记录的数据表tt进行实验,原数据文本大小约为100G,infobright存储的压缩文件总共占空间14G,压缩比超过7(其中有一些我自己的数据转换)。

tt表包含了DATE、TIME、INT、BIGINT、TINYINT、SMALLINT、MEDIUMINT、FLOAT、VARCHAR等多种数据类型,正好拿来对比(TEXT等类型就不要拿来捣乱了)。现在看看infobright针对不同类型的数据采用不同压缩算法的威力:

  • DATE:因为实际中不同的DATE非常少,而且是连在一起的,所以infobrigt把这个字段的信息绝大多都以统计信息的形式存放于知识网格(Knowledge Grid),这个字段的数据文件大小为1.4K!!!
  • TIME:TIME类型与DATE类似,但不同的TIME比DATE多,所以它的数据文件的大小是3.6M。
  • INT:4个byte的INT视实际情况而定,从几百M到1G多不等。
  • MEDIUMINT(3 byte)、SMALLINT(2 byte)、TINYINT(1 byte):通常都比INT小。
  • BIGINT:8个byte的bigint在tt表里有将近2G的大小。
  • FLOAT:4个byte的FLOAT占空间跟INT差不多。
  • VARCHAR(255):基本都是在3G以上。

压缩包的大小直接影响了解压缩时的效率以及IO量。所以:1、能用小类型就不要用大类型;2、尽量少用varchar;3、分布在高值的数值类型压缩比有限,但要是数据主要分布在低值且分布集中,则可获得可观的压缩比。

查询操作:

  1. select count(*) from tt,不耗费时间,因为infobright存储引擎跟MyISAM一样,是存储记录数目的。
  2. 范围查询:select * from tt where xx=xx,有赖于知识网格,infobright对这类查询友好,无论是=<>这些查询还是between,大数据集与小数据集的查询时间差不远。良好的数据可扩展性。
  3. 群组操作:select date, count(1) count from tt group by date order by date,在1秒内得到结果,这类操作也是infobright擅长的。
  4. DISTINCT操作:select count(distinct f1) from tt,2千万的数据用了2秒多,全部7亿的数据用了6分半钟。distinct在知识网格里不能存储太多的信息,所以会比较慢,ICE3.1还没有太好的方法,看后面的版本怎么对付这个问题吧。但需知对于大量数据这从来就不是个容易的问题。
  5. 全取:select * from tt。这样的操作总是费劲的,因为瓶颈在磁盘IO,但因为infobright的高压缩比,所以取出数据还是要比mysql快不少。(补充:解压缩的过程也很耗费时间)

注意:

  • 从之前的架构分析可以知道,infobright的查询条件越多越好,越有区分度越好,因为这样经过对知识网格过滤之后,需要取出来解压缩查询的数据块就少了,速度就上来了。
  • 尽量使用范围性的查询,因为这些知识就存储在知识网格里。
  • 要对varchar之类的文本类型进行查询,最好先用其它类型把范围缩小。

ICE3.2刚出来,据说查询速度有了较大提升,等源代码包放出来再研究研究。

转载请保留本文原始链接:http://www.wentrue.net/blog/?p=289

  评论这张
 
阅读(349)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017