[转][转]列式数据库之infobright以及架构 - 为程序员服务
[转][转]列式数据库之infobright以及架构
文章来源：http://www.cnblogs.com/inmanhust/tag/infobright/　　年前听过Sybase中国区副总裁的关于列式数据库的讲座之后就一直被列式数据库强大的性能吸引。最近邂逅了infobright，列式数据库的学习展开了。　　Sysbase可以说是列式数据库的先驱，Sysbase IQ 15 就是Sybase 目前最新的列式数据库。它具有强大的功能，包括数据的快速加载、超高速的分析性能、强大的业务智能分析、领先的数据建模能力等等。
infobright是一个基于MySQL的数据仓库系统，的blog上有挺详细的介绍。同样是列式数据库，但是infobright和Sybase IQ系列还是有很大的不同。infobright采用的Knowledge Grid来组织数据，infobright内部是没有索引，就这点就节省了不少的空间。而Sybase IQ系列还是使用了索引，而这些索引我个人的理解就是位图索引的改进版。白皮书上说，infobright的数据压缩比可以是10：1到40：1，个人拿庞大的日志数据库做了个小小实验，感觉压缩也没那么夸张。如果依据位图索引的思想，每列数据的相似度越高就会具有越高的压缩比。infobright应该也是满足这一点的，但是具体Knowledge Grid内部如何实现还不清楚，有待继续考究。
&　　 infobright的优点有很多，简单列举如下：
&　　Infobright的优点：（1）高压缩比率（2）快速响应复杂的分析查询语句（3）随着数据库的逐渐增大，查询和装载性能基本保持稳定（4）没有特殊的数据仓库模型（比如星状模型、雪花模型）要求（5）无需要物化视图、复杂的数据分区策略、索引（6）实施和管理简单，需要极少的管理（7）和众多的BI套件相容，比如Pentaho、Cognos、Jaspersoft。infobright有两个版本ICE和IEE，目前ICE的版本是3.3.1，支持64位Linux和32位windows。ICE不支持DML，也就是不支持insert、update等操作。至于infobright的框架待改天分析。　　Infobright的总体构架图如下:　　　　如上图所示，Infobright采用了和MySQL一致的构架，分为两层。上层是服务及应用管理，下层是存储引擎。Infobright的默认存储引擎是brighthouse，但是Infobright还可以支持其他的存储引擎，比如MyISAM、MRG_MyISAM、Memory、CSV。Infobright通过三层来组织数据，分别是DP(Data Pack)、DPN（Data Pack Node）、KN（Knowledge Node）。而在这三层之上就是无比强大的知识网络（Knowledge Grid）。　　数据块（DP）是存储的最低层，列中每64K个单元组成一个DP。DP比列更小，具有更好的压缩比率；又比单个数据单元更大，具有更好的查询性能。　　数据块节点（DPN），DPN和DP之间是一对一的关系。DPN记录着每一个DP里面存储和压缩的一些统计数据，包括最大值、最小值、null的个数、单元总数count、sum等等。　　KN里面存储着指向DP之间或者列之间关系的一些元数据集合，比如值发生的范围（MIin_Max）、列数据之间的关联。大部分的KN数据是装载数据的时候产生的，另外一些事是查询的时候产生。　　在这三层之上是知识网络（Knowledge Grid），Knowledge Grid构架是Infobright高性能的重要原因。　　　　Knowledge Grid可分为四部分，DPN、Histogram、CMAP、P-2-P。　　DPN如上所述。Histogram用来提高数字类型（比如date，time，decimal）的查询的性能。Histogram是装载数据的时候就产生的。DPN中有mix、max，Histogram中把Min-Max分成1024段，如果Mix_Max范围小于1024的话，每一段就是就是一个单独的值。这个时候KN就是一个数值是否在当前段的二进制表示。　　　　Histogram的作用就是快速判断当前DP是否满足查询条件。如上图所示，比如select id from customerInfo where id&50 and id&70。那么很容易就可以得到当前DP不满足条件。所以Histogram对于那种数字限定的查询能够很有效地减少查询DP的数量。　　CMAP是针对于文本类型的查询，也是装载数据的时候就产生的。CMAP是统计当前DP内，ASCII在1-64位置出现的情况。如下图所示　　　　比如上面的图说明了A在文本的第二个、第三个、第四个位置从来没有出现过。0表示没有出现，1表示出现过。查询中文本的比较归根究底还是按照字节进行比较，所以根据CMAP能够很好地提高文本查询的性能。　　Pack-To-Pack是Join操作的时候产生的，它是表示join的两个DP中操作的两个列之间关系的位图，也就是二进制表示的矩阵。　　Knowledge Grid还是比较复杂的，里面还有很多细节的东西，可以参考官方的白皮书和这篇论文。　　前面已经简要分析了Infobright的构架，现在来介绍Infobright的工作原理。　　粗糙集（Rough Sets）是Infobright的核心技术之一。Infobright在执行查询的时候会根据知识网络（Knowledge Grid）把DP分成三类：　　相关的DP（Relevant Packs），满足查询条件限制的DP　　不相关的DP（Irrelevant Packs），不满足查询条件限制的DP　　可疑的DP（Suspect Packs），DP里面的数据部分满足查询条件的限制　　下面是一个案例：　　　　如图所示，每一列总共有5个DP，其中限制条件是A&6。所以A1、A2、A4就是不相关的DP，A3是相关的DP，A5是可疑的DP。那么执行查询的时候只需要计算B5中满足条件的记录的和然后加上Sum（B3），Sum（B3）是已知的。此时只需要解压缩B5这个DP。从上面的分析可以知道，Infobright能够很高效地执行一些查询，而且执行的时候where语句的区分度越高越好。where区分度高可以更精确地确认是否是相关DP或者是不相关DP亦或是可以DP，尽可能减少DP的数量、减少解压缩带来的性能损耗。在做条件判断的使用，一般会用到上一章所讲到的Histogram和CMAP，它们能够有效地提高查询性能。　　多表连接的的时候原理也是相似的。先是利用Pack-To-Pack产生join的那两列的DP之间的关系。　　比如：SELECT MAX(X.D) FROM T JOIN X ON T.B = X.C WHERE T.A & 6。Pack-To-Pack产生T.B和X.C的DP之间的关系矩阵M。假设T.B的第一个DP和X.C的第一个DP之间有元素交叉，那么M[1,1]=1，否则M[1,1]=0。这样就有效地减少了join操作时DP的数量。　　前面降到了解压缩，顺便提一提DP的压缩。每个DP中的64K个元素被当成是一个序列，其中所有的null的位置都会被单独存储，然后其余的non-null的数据会被压缩。数据的压缩跟数据的类型有关，infobright会根据数据的类型选择压缩算法。infobright会自适应地调节算法的参数以达到最优的压缩比。　　Infobright里面支持所有的MySQL原有的数据类型。其中Integer类型比其他数据类型更加高效。尽可能使用以下的数据类型：　　TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT　　DECIMAL（尽量减少小数点位数）　　DATE ，TIME　　效率比较低的、不推荐使用的数据类型有：　　BINARY VARBINARY　　FLOAT　　DOUBLE　　VARCHAR　　TINYTEXT TEXT　　Infobright数据类型使用的一些经验和注意点：　　（1）Infobright的数值类型的范围和MySQL有点不一样，比如Infobright的Int的最小值是-，而MySQl的Int最小值应该是-。其他的数值类型都存在这样的问题。　　（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号称数据压缩比率是10:1到40:1。前面我们已经说过了Infobright的压缩是根据DP里面的数据类型，系统自动选择压缩算法，并且自适应地调节算法的参数以达到最优的压缩比。　　先看看在我的实验环境下的压缩比率，如下图所示：　　　　相信读者可以很清楚地看到，整体的压缩比率是20.302。但是这里有一个误区，这里的压缩比率指的是数据库中的原始数据大小/压缩后的数据大小，而不是文本文件的物理数据大小/压缩后的数据大小。很明显前者会比后者大出不少。在我的实验环境下，后者是7:1左右。一般来说文本数据存入数据库之后大小会比原来的文本大不少，因为有些字段被设置了固定长度，占用了比实际更多的空间。还有就是数据库里面会有很多的统计信息数据，其中就包括索引，这些统计信息数据占据的空间绝对不小。Infobright虽然没有索引，但是它有KN数据，通常情况下KN数据大小占数据总大小的1%左右。　　既然Infobright会根据具体的数据类型进行压缩，那我们就看看不同的数据类型具有什么样的压缩比率。如下表所示：　　　　首先看看Int类型的压缩比率，结果是压缩比率上Int&mediumint&smallint。细心地读者会很容易发现tinyint的压缩比率怎么会比int还小。数据压缩比率除了和数据类型有关之外，还和数据的差异性有特别大关系，这是显而易见。posFlag只有0，1，-1三种可能，这种数据显然不可能取得很好的压缩比率。　　再看看act字段，act字段使用了comment lookup，比简单的char类型具有更佳的压缩比率和查询性能。comment lookup的原理其实比较像位图索引。对于comment lookup的使用下一章节将细细讲述。　　在所有的字段当中date字段的压缩比率是最高的，最后数据的大小只有0.1M。varchar的压缩比率就比较差了，所以除非必要，不然不建议使用varchar。　　上面的数据很清楚地展示了Infobright强大的压缩性能。在此再次强调，数据的压缩不只是和数据类型有关，数据的差异程度起了特别大的作用。在选择字段数据类型的时候，个人觉得性能方面的考虑应该摆在第一位。比如上面表中一些字段的选择就可以优化，ip可以改为bigint类型，date甚至可以根据需要拆分成year/month/day三列。　　前面的章节一直涉及到comment lookup，这里将简单介绍comment lookup的使用。　　comment lookup只能显式地使用在char或者varchar上面。Comment Lookup可以减少存储空间，提高压缩率，对char和varchar字段采用comment lookup可以提高查询效率。　　Comment Lookup实现机制很像位图索引，实现上利用简短的数值类型替代char字段已取得更好的查询性能和压缩比率。CommentLookup的使用除了对数据类型有要求，对数据也有一定的要求。一般要求数据类别的总数小于10000并且当前列的单元数量/类别数量大于10。Comment Lookup比较适合年龄，性别，省份这一类型的字段。　　comment lookup使用很简单，在创建数据库表的时候如下定义即可：　　act & char(15) & comment 'lookup',　　part &char(4) comment 'lookup',　　前面已经分析了Infobright的构架，简要介绍了Infobright的压缩过程和工作原理。现在来讨论查询优化的问题。　　　　（1）配置环境　　　　在Linux下面，Infobright环境的配置可以根据README里的要求，配置brighthouse.ini文件。　　（2） 选取高效的数据类型　　　　参见前面章节。　　（3）使用comment lookup　　　　参见前面章节。　　（4）尽量有序地导入数据　　　　前面分析过Infobright的构架，每一列分成n个DP，每个DPN列面存储着DP的一些统计信息。有序地导入数据能够使不同的DP的DPN内的数据差异化更明显。比如按时间date顺序导入数据，那么前一个DP的max（date）&=下一个DP的min(date)，查询的时候就能够减少可疑DP，提高查询性能。换句话说，有序地导入数据就是使DP内部数据更加集中，而不再那么分散。　　（5）使用高效的查询语句。　　　　这里涉及的内容比较多了，总结如下：　　 & & &尽量不适用or，可以采用in或者union取而代之　　　　减少IO操作，原因是infobright里面数据是压缩的，解压缩的过程要消耗很多的时间。　　　　查询的时候尽量条件选择差异化更明显的语句 & & & & Select中尽量使用where中出现的字段。原因是Infobright按照列处理的，每一列都是单独处理的。所以避免使用where中未出现的字段可以得到较好的性能。 & & & & 限制在结果中的表的数量，也就是限制select中出现表的数量。 & & & &尽量使用独立的子查询和join操作代替非独立的子查询　　　 &尽量不在where里面使用MySQL函数和类型转换符 & & & &尽量避免会使用MySQL优化器的查询操作　　　 &使用跨越Infobright表和MySQL表的查询操作　　　　尽量不在group by 里或者子查询里面使用数学操作，如sum（a*b）。　　　　select里面尽量剔除不要的字段。　　Infobright执行查询语句的时候，大部分的时间都是花在优化阶段。Infobright优化器虽然已经很强大，但是编写查询语句的时候很多的细节问题还是需要程序员注意。　　
作者：heiyeshuwu 发表于 1:07:25
阅读：415 评论：0
个人技术微博: weibo.com/heiyeluren 【微信公众号：heiyeluren2012】
原文地址：, 感谢原作者分享。
您可能感兴趣的代码Infobright&数据仓库
是一款开源列式数据仓库引擎，采用他们自己的Knowledge
Grid架构（一直没有明白这两个单词），该引擎采取内部管理自身优化查询的方式，给用户带来更为轻松的体验。我们所要做的就是写出“漂亮”的SQL，后面我会关于SQL语句说点有趣的东西。
Infobright像很多优秀的开源软件一样，也都具有两个版本，社区版（ICE）和企业版（IEE），多数情况下，如果免费的能满足我们的实际需求，领导更愿意采用社区版；企业版需要付费，那么自然就会给用户提供更加完善的功能、保证运行的稳定性以及良好的后期服务。下面具体介绍一下Infobright在我的实际环境中的应用。
系统环境：CentOS 5.4
64位、&infobright-3.3.1-x86_64-ice、4G内存、8核CPU
Infobright安装：
在下载适合的版本，通常我会下载二进制tar包的版本，解压缩后，按照里面有个叫做README的文件，去一步步操作就可以了，各个参数的介绍里面都有，其中，&datadir和&cachdir这两个安装选项，可以将data目录和cache目录安装到我们制定的目录下。（不是我懒得写，真地，是非常简单!）
Infobright目录结构：
解压后，你会发现这不就是一个MySQL吗，infobright-3.3.1是集成于mysql-5.1.40，很自然的就会把infobright理解成MySQL的一个特殊引擎，这又进一步体现出MySQL具有可插拔引擎接口的特点。
cache目录：README里面说是临时文件生成和存放地，但是我一直没有看到里面有文件按出现。
data目录：
错误日志这个和MySQ记录启动关闭信息以及一些错误和警告提示，但在infobright中它还有一个特殊的任务就是记录执行计划，因为
infobright没有explain/profile这样的工具。
brighthouse.ini&&
infobright的配置文件，里面有使用内存大小的分配规则、选择是否开启执行计划记录功能等。
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目录。
Infobright实际应用：
我们之所以使用数据仓库，是因为目前MySQL数据库中的数据增长很快，定期会对一些历史记录表进行清除，但后期的统计分析还会用到这些历史数据，随着数据量的增大，查询也越来越慢，而数据库仓库特有的存储格式能够减小磁盘空间内的占用，同时列式的特点使得查询速度大为改观。于是，我们就将数据仓库作为存储历史数据的地方。很多数据库仓库软件，基于数据的压缩比和查询速度考虑，我看上了其中两个Infobright和Infinidb，Infobright的压缩比最高（我测试的结果是25：1），但是查询速度慢于Infinidb,Infinidb是所有比较的开源数据仓库中查询速度最优的，但是压缩比远不及Infobright。最后选择Infobright是因为它锁支持的数据类型更多些，更接近于mysql，更节省磁盘空间，毕竟主要的统计查询还不是在数据仓库上，偶尔的查询一下速度倒不是要求最优，但是ICE最大的不变用了后你是不能做DM操作的，这点我深有体会，每次如果插入数据有些不合适的地方，需要删除，你只能drop
table，然后从新建表和导入数据，麻烦呀。而Infinidb在这方便就让你很开心。
Infobright遇到的问题：
昨天加班，同事需要在infobright上做一个需求的统计，查询3个月的数据，牵扯到4个表的外连接查询，其中有两张大表都在1亿条以上，结果我的infobright每次执行到2分钟以后就crash掉了，连续尝试了几次，按照查询计划里面的提示，修改的了my-ib.cnf里面的一些参数还是无济于事（我同事一直在嘲笑我的数据仓库，说mysql也比它好，我也觉得很有意思，怎么就被一条语句给弄崩溃了）。我还是很挺infobright的，决定改他的sql，将之前的4个表，我通过一个目标大表和2个小表现做内连接，然后将该结果与另一个大表再做外连接，调整后再查2分钟左右看到结果。这就是我之前说的，我们要给infobright提供漂亮的sql。
之前试图尝试使用infobright与mysql搭建主从复制，考虑到每次手动导来导去的很麻烦，但是没能成功，即便主库mysql的语句已经被记录到relay
log中，但由于ICE版不支持DML语句，所以数据也就无法同步过来。
Infobright执行计划：
如果你想知道infobright是如何去处理你发过来的sql语句的，通过开启infobright记录执行计划的功能，便可清楚可见（说实话，不太好看懂-_-0），修改brighthouse.ini配置文件，将ControlMessages
2，默认是0，不开启执行计划记录，1为详细记录，但不带时间。下面我截了两张执行计划的图，大家可以看看。
第一张是一条内连接sql语句的执行过程；
第二张就是infobright垮掉后记录的错误提示。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。　　几大优点：
　　1、高压缩比率，平均压缩比可达10：1，甚至可以达到40:1，我用infobright把3.1G的数据存成不足300M。
　　2、列存储，即使数据量十分巨大，查询速度也很快。用于数据仓库，处理海量数据没一套可不行。
　　3、不需要建索引，就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放，每块有节点记录块内的统计信息，代替索引，加速搜 索。
　　4、单一台服务器可以高效地读写30T数据。具有可扩展性，这里是指对于同样的查询，当数据量是10T时，它耗费的时间不应该比1T数据量时慢太 多，基本是一个数量级内。
　　下面是Infobright的架构图：
　　灰色部分是mysql原有的模块，白色与蓝色部分则是 infobright自身的。
　　系统结构分析：
　　跟mysql一样的两层结构，上面的逻辑层处理查询逻辑，下面的是存储引擎。逻辑层右端的loader与unloader是infobright的数据导入导出模块，也即处理SQL语句里LOAD DATA INFILE … 与SELECT … INTO FILE任务，由于infobright面向的是海量数据环境，所以这个数据导入导出模块是一个独立的服务，并非直接使用mysql的模块。逻辑层的infobright优化器包在mysql的外面，如下面将会提到的，因为它的存储层有一些特殊结构，所以查询优化方式也跟 mysql有很大差异。存储层最底层是一个个的Data Pack（数据块）。每一个Pack装着某一列的64K个元素，所有数据按照这样的形式打包存储，每一个数据块进行类型相关的压缩（即根据不同数据类型采 用不同的压缩算法），压缩比很高。它上层的压缩器与解压缩器就做了这个事情。压缩层再向上就是infobright最重要的概念：Knowledge Grid（知识网格），这也是infobright放弃索能应用于大量数据查询的基础。它包含两类结点：每个Data Pack Node（知识节点）对应于一个Data Pack，存储该Data Pack的一些统计信息，如min, max, avg, null的个数，甚至不同值的量等等；Knowledge Node则存储了一些更高级的统计信息，以及与其它表的连接信息，这里面的信息有些是数据载入时已经算好的，有些是随着查询进行而计算的，所以说是具备一 定的“智能”的。
&|&相关影像
互动百科的词条（含所附图片）系由网友上传，如果涉嫌侵权，请与客服联系，我们将按照法律之相关规定及时进行处理。未经许可，禁止商业网站等复制、抓取本站内容；合理使用者，请注明来源于www.baike.com。
登录后使用互动百科的服务，将会得到个性化的提示和帮助，还有机会和专业认证智愿者沟通。
此词条还可添加&
编辑次数：3次
参与编辑人数：3位
最近更新时间： 12:36:00
贡献光荣榜
扫码下载APP一、infobright几大优点：
1、高压缩比率，平均压缩比可达10：1，甚至可以达到40:1，我用infobright把3.1G的数据存成不足300M。
2、列存储，即使数据量十分巨大，查询速度也很快。用于数据仓库，处理海量数据没一套可不行。
3、不需要建索引，就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放，每块有知识网格节点记录块内的统计信息，代替索引，加速搜索。
4、单一台服务器可以高效地读写30T数据。具有可扩展性，这里是指对于同样的查询，当数据量是10T时，它耗费的时间不应该比1T数据量时慢太多，基本是一个数量级内。
二、infobright与mysql对比：
1、infobright适用于数据仓库场合，即非事务、非实时、非多并发；分析为主；存放既定的事实（基本不会再变），例如日志，或汇总的大量的 数据。所以它并不适合于应对来自网站用户的请求。实际上它取一条记录比mysql要慢很多，但它取100W条记录会比mysql快。
2、mysql的总数据文件占用空间通常会比实际数据多，因为它还有索引。infobright的压缩能力很强大，按列按不同类型的数据来压缩。
3、服务形式与接口跟mysql一致，可以用类似mysql的方式启用infobright服务，然后原来连接mysql的应用程序都可以以类似的方式连接与查询infobright。这对熟练mysql者来说是个福音，学习成本基本为0。
infobright有两个发布版：开源的ICE及闭源商用的IEE。ICE提供了足够用的功能，但不能INSERT，DELETE，UPDATE，只能LOAD DATA INFILE。IEE除提供更充分的功能外，据说查询速度也要更快。
三、mongodb数据库做适合的事情
mongodb的文档里提到的user case包括实时分析、logging、全文搜索，国内也有人使用mongodb来存储分析网站日志，但我认为mongodb用来处理有一定规模的网站日志其实并不合适，最主要的就是它占空间过于虚高，原来1G的日志数据它可以存成几个G，如此下去，一个硬盘也存不了几天的日志。另一方面，数据量大了肯定要考虑sharding，而mongodb的sharding到现在为止仍不太成熟。由于日志的不可更新性的，往往只需APPEND即可，又因为对日志的操作往往只集中于一两列，所以最合适作为日志分析的还是列存储型的数据库，特别是像infobright那样的为数据仓库而设计的列存储数据库。
由于mongodb不支持事务操作，所以事务要求严格的系统（如果银行系统）肯定不能用它。
引用自不周山： http://www.wentrue.net/blog/?cat=4&
阅读(...) 评论()MySQL&Infobright-数据仓库一些不支持的地方[转]
BRIGHTHOUSE存储引擎建表时没有能有AUTO_INCREMENT自增、unsigned无标记、unique唯1、主键PRIMARY
KEY、索引KEY&
http://blog.s135.com/infobright/&
实现infobright的数据load&
mysql -uroot -S /tmp/mysql-ib.sock -D web_game --skip-column-names
-e "LOAD DATA INFILE
"/data1/backup/web_game/analysis/myfile.csv"&
INTO TABLE webgame_gamelogin FIELDS TERMINATED BY "," ENCLOSED BY
brighthouse 是infobright 数据库的要害引擎。infobright
数据库是基于mysql的，它的计划主要是用于年夜规模的数据客栈战标明劣化。可以也许往www.infobright.org下载开源社区版。&
它的安拆极端简单：解开了下载的gz包后，直接运转install-infobright.sh就ok了，正在redhat5下安拆根本没有碰到任何麻烦。&
安拆以后，它的建立文件是/etc/my-ib.cnf. 启动脚本是/etc/init.d/mysqld-ib.
客户端敕令是mysql-ib.&
假定所安拆的呆板上同时安拆有其他mysql，年夜概就有一面小麻烦了：没法普通利用mysql-ib敕令。那只要是my.cnf弄的鬼。固然infobright用的建立文件是/etc/my-ib.cnf,然则my.cnf也会干扰。比圆，假定正在my.cnf中有‘comment’的建立项，当运转mysql-ib,就会有那样的错误：unknown
option "--comment"。&
拆完以后试了试，果然没有赖。导进了5000万行纪录，一条count语句没有到30秒。想想正在innoDB上，没有个10分钟出没有往。&
当前的版本支撑30T的数据，采取的是数据压缩的存储体例，压缩比例可达40：1。本往5000万行的数据，十多G呢，导进infobright以后，我一向到琢磨：它把我那5000多万行纪录放哪往了^_^&
那对象好是好，没有外有很多没有爽的地方：&
开源版没有支撑insert等数据操做语句，导进数据只能用load语句（谁人导进数据很快）&
借没有支撑UTF－8（谁人最烦人了，固然它供应了一种圆案往措置谁人题目）&
企业版可也已便宜$10000/T
（mysql才600刀）(数据客栈类的软件都很贵，那已经算很便宜的了^_^)&
跟我们泛泛用的其他引擎（如innodb）没有是很兼容,比圆没有支撑bit类型；position也是要害字，没有能用往做字段名。归正是利用正在innodb上的数据库脚本年夜概没有能正在那上直接利用。（那都算，太懒了^_^）&&
BRIGHTHOUSE存储引擎建表时没有能有AUTO_INCREMENT自增、unsigned无标记、unique唯1、主键PRIMARY
KEY、索引KEY&
实现infobright的数据load&
mysql -uroot -S /tmp/mysql-ib.sock -D web_game --skip-column-names
-e "LOAD DATA INFILE
"/data1/backup/web_game/analysis/myfile.csv"&
INTO TABLE webgame_gamelogin FIELDS TERMINATED BY "," ENCLOSED BY
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。