如果要恢复原始的MySQL加载工具，设置BH_DATAFORMAT环境变量为'mysql'。
数据加载后，tpch数据库的大小为169 MB (177,304,450 字节) ，压缩比约18%。
下面是查询测试结果。由于64位企业版无法启动，改用配置稍低的32位服务器，因此绝对时间与前面的GBase和Oracle不可比，只说明大致的趋势。
表1 TPC-H 2.8 scale=1的测试对比，单位：秒▲
*修改SQL为等价的方式后3.63秒。
如上表所示，infobright在22个测试项目全都落后于Oracle,但有3个比GBase用时短。只有1个测试项目未执行成功，比GBase的2个未执行成功要少。有6个项目执行时间远远长于Oracle,有时通过修改SQL的写法可以获得较好的性能，比如下面第20个查询，通过把第2个in子查询改为关联，执行时间缩短到原来的200分之一。
select s_name, s_address
from supplier, nation
where s_suppkey in (select ps_suppkey
from partsupp
where ps_partkey in (select p_partkey
from part
where p_name like 'forest%')
and ps_availqty > (select 0.5 * sum(l_quantity)
from lineitem
where l_partkey = ps_partkey
and l_suppkey = ps_suppkey
and l_shipdate >= date '1994-01-01'
and l_shipdate < date '1994-01-01' + interval '1' year))
and s_nationkey = n_nationkey
and n_name = 'CANADA'
order by s_name
limit 100;
/*修改后的第20个查询语句*/
select s_name, s_address
from supplier, nation
where s_suppkey in (select ps_suppkey
from partsupp
,(select l_partkey,l_suppkey, sum(l_quantity) l_quantity_SUM
from lineitem,part
where l_partkey = p_partkey and p_name like 'forest%'
and l_shipdate >= date '1994-01-01'
and l_shipdate < date '1994-01-01' + interval '1' year
GROUP BY l_partkey,l_suppkey
)a
where l_partkey = ps_partkey
and l_suppkey = ps_suppkey
and ps_availqty > 0.5*l_quantity_SUM
)
and s_nationkey = n_nationkey
and n_name = 'CANADA'
order by s_name
limit 100;
四、结束语
看到这里，相信读者对Infobright已经有了初步的印象，无论是企业版还是社区版，数据压缩都非常强悍，SQL的兼容性也不错，在brighthouse引擎内部，各种内外关联、子查询都支持,tpc-h的22个SQL,除了limit -1这种写法不被支持，只有#1，#13需要修改。至于查询性能，表现平平，几个耗时特别长的查询和GBase的一致。由于测试的项目有限，现有的测试未观察到企业版在多线程上的表现比社区版没有明显的区别。二种版本具体区别详情参考http://www.infobright.org/Learn-More/ICE_IEE_Comparison/。
要说最大的问题，就是服务器的稳定性，我的测试机企业版经常出现授权文件非法的奇异错误，导致服务器无法启动，社区版要好一些，因为不存在授权文件的问题。
总的来说，如果用户十分在意存储空间，对查询速度要求一般，那么Infobright是一个好的选择。而对最终用户来说，缺少图形化的管理工具也是一个不容忽视的问题。其次，infobright对SQL的编写要求较高，如果需要高效的查询，需要开发人员有较丰富的经验。
对于有能力的用户，社区版是更好的选择，它虽然有些功能不如企业版，但它免费，而且提供了源代码，用户可以基于它作个性化的修改，以满足自己特殊的需要。
