【IT168 专稿】在上一篇文章中，我们介绍了主流商业列存储数据库Sybase IQ 15.2版的功能特点，并给出了tpc-h scala=10,ssb (星型模式)scala=10性能测试的数据。在本文写作之际， Infobright和InfiniDB刚刚发布了新版本，并声称比之前版本性能上有了进一步提升，而sybase IQ的新版v15.3可能要在4、5月份才能推出，据说在压缩、查询和多节点上也有了大幅度提升，这次测试专门基于它们目前各自的最新版本，以反映各种软件的最大性能表现。另外，基于相同的原因，不再测试性能受限的社区版，只测试企业版。

　　系列文章回顾：

　　主流列式数据库评测:InfiniDB和MonetDB

　　主流列式数据库评测之Infobright

　　主流列式数据库评测:南大通用GBase 8a

　　主流列式数据库评测：Sybase IQ

　　一、测试平台

　　比较测试的平台沿用上篇Sybase IQ安装的机器，是基于Intel Xeon 7550*8的PC服务器上用VMWare VSphere 4.1管理的虚拟机，虚拟机的逻辑CPU个数是8，内存100GB，存储为8个300GB本地磁盘的RAID5阵列。操作系统采用和RHEL 5相同的核心级别的Red Flag Asian Linux Sever 3.0 x64。用于比较的Oracle采用11.2.0.2版本，本次测试采用了并行查询的方式。由于Linux是互联网公司常用的服务器操作系统，因此这一测评，对更大范围的用户也有参考价值。

　　二、安装

　　我们先来安装Infobright和InfiniDB这两个轻量级的数据库的Linux版，虽然比Windows版本复杂一些，但Infobright官方wiki提供的安装文章只有一页，可想而知安装是多么容易，InfiniDB的安装手册页数略多，但包含了升级、集群等复杂安装模式，总体而言，单服务器新装软件还是相当快捷的。下面分别是各种软件的安装步骤。

　　(一) Infobright的安装步骤

　　1. 注册新用户从http://support.infobright.com/Support/Downloads下载对应操作系统的安装包IEE v3.5.2 64-Bit RPM (Red Hat Enterprise 5.x and CentOS 5.x)(69M) ，infobright-3.5.2-0-x86_64-eval.rpm，如果没有测试授权lic文件，也要申请一个。

　　2.登录到操作系统，在软件存放目录输入下面的命令安装软件。

　　rpm -ivh infobright-3.5.2-0-x86_64-eval.rpm

　　3.将授权文件拷贝到安装目录,注意这个授权文件的有效期是从申请日开始计时的，不分操作系统平台和数据库软件版本。

　　cp /user1/app/*lic /usr/local/infobright-3.5.2-x86_64/

　　4.用/etc/init.d/mysqld-ib start命令启动infobright，并用mysql-ib连接数据库。

　　5.安装完后可以执行脚本以改变安装选项，比如数据存储位置，这一步是可选的，并且可以在任何时候根据需要关闭数据库执行。注意最后一步删除原有存储位置的数据在3.42版是脚本自动完成的，而3.52版让用户手工执行，更有利于数据的安全。

　　(二) InfiniDB的安装步骤

　　1.从http://www.calpont.com/resources/resource-library/category/3-infinidb-enterprise-edition下载对应操作系统的安装包InfiniDB Enterprise Edition Trial Software - 64 bit RPMs (26.17 MB)，calpont-infinidb-2.0.3-4.x86_64.rpm.tar.gz。

　　2.登录到操作系统，在软件存放目录输入下面的命令解压缩安装包并安装软件。

　　tar zxf calpont-infinidb-2.0.3-4.x86_64.rpm.tar.gz

　　rpm -ivh cal*rpm

　　3.运行/usr/local/Calpont/bin/postConfigure，执行安装后配置，这一步是必须的。主要用于初始化InfiniDB数据库，以及将后台服务进程加入/etc/init.d/，令数据库随系统重启自动启动。

　　如果执行脚本出现错误，需要解决错误后，关闭数据库后台服务进程再执行上述脚本。

　　如果执行配置脚本无误，运行产生别名的脚本，便于用户执行各种管理命令。

　　InfiniDB无法直接改变数据的存储位置，但安装文档指出在Linux系统中可以将/usr/local/Calpont/下的data1目录挂载(mount)到外部存储，实际上也可以用软连接(ln -s)指向一个空闲空间较多的分区。利用软连接的操作步骤如下：

　　1)在安装完InfiniDB数据库软件，尚未配置之前将安装目录下的data1目录的内容移动到另一个空闲目录下。

　　2)删除这个data1目录，并创建一个同名的软连接

　　3)执行安装后配置

　　注意：如果数据库已经配置过并创建了新的内容，需要关闭数据库才能进行移动操作，但不建议这么做，如果操作失误，可能导致启动失败或数据丢失。尽量在数据库安装阶段就规划好磁盘分布。

　　三、功能比较

　　各种数据库提供的主要功能在前面的文章中有过详细介绍，这里简述一下它们有区别的地方。

　　1. 对SQL标准的支持

　　SybaseIQ对SQL标准的支持程度较高，具备其他列式数据库不具备的建立索引和主键功能。其他列式数据库还不支持分析函数和group by cube等扩展语法。

　　2. 数据库指定数据存储位置

　　我们在安装过程中特别关注能否改变数据存储位置，因为一般Linux系统的/usr/local空间很有限，主要用于保存软件的二进制文件，而用户数据需要保存在其它位置，现在我们看到，各种数据库都具备了这方面的能力。无论是通过配置脚本、操作系统系统命令或SQL语句，都能最终完成任务。如果是不支持软连接的Windows操作系统，InfiniDB的存储位置在安装后不可改变，因此要特别注意将软件安装到空间较大的硬盘分区。

　　3. 数据加载错误处理

　　默认情况下，如果数据加载时错误Sybase IQ会报错并中止导入，所有数据回滚，而Infobright和InfiniDB会忽略错误继续导入。Sybase IQ也可以忽略错误继续导入，但需要在Load脚本中加入ON FILE ERROR CONTINUE语句。

　　4. 数据库空间扩展

　　Sybase IQ、Infobright和InfiniDB都可以自动自动增长，SybaseIQ 还可以人工创建和维护数据库空间，并支持裸设备。

　　四、性能测试

　　测试项目包含三方面，第一是加载，数据仓库要处理的数据量巨大，数据加载能力是选择数据库软件要考虑的重要因素之一，我们将测试包括外部文本数据加载和从数据库内部抽取部分数据到其他表的性能。第二是压缩，数据压缩时常被作为列式存储数据库的一个卖点来宣传，因此我们单独把它拿出来测试。由于多数数据库没有单独的表压缩命令，都是依靠参数指定是否压缩或根本无法指定不压缩(Sybase IQ),只测试压缩后的占用空间对原始外部文件的压缩率。第三是测试重点，数据查询，分别采用tpc-h scala=10,SSB (星型模式基准)scala=10数据作全表分组查询。

　　(一) 数据加载

　　1. 从外部文本文件导入

　　4种数据库分别采用各自推荐的最快的导入方式。Oracle用sqlldr直接路径加载，Infobright用自带的加载引擎使用load data命令。InfiniDB利用cpimport 采用8个读入和写入进程的参数，Sybase利用前面介绍的Load table方式。为了解决末尾一个列分隔符的问题，利用了命名管道，这个转换的负担很轻，基本不影响导入速度。

　　Gzip解压缩“管道”的负担对数据加载而言很轻，因为此时解压缩无论是消耗的CPU还是I/O比起文件加载到数据库都不是瓶颈。如果实际工作中经常需要将大量数据搬移到另一台机器使用，采用gzip格式是个很不错的选择。采用并行gzip工具pigz可以充分利用cpu资源大幅度提升压缩速度。

　　InfiniDB只支持外部数据数据来源被重定向到STDIN标准输入，而不支持其它的命名管道，另外3种数据库都支持命名管道方式。不过cpimport是一个独立的可执行文件，而不需要用命令行工具登录后再执行内部命令，不支持命名管道也不是什么大问题。

　　由于原始数据当中存在一些不是数字的非法值，导入SybaseIQ失败。我们在Sybase IQ导入整数类型的HUI表时也采用了命名管道，与前一个转换相比，这个awk转换大大降低了加载速度，时间达到11118.569秒，缺乏可比性，因此利用Sybase导出此表的文本文件，重新导入再计时。其他数据库都是利用Sybase导出的文本文件加载的。

　　Infobright不知何故，当数据加载引擎设为Infobright的文本方式(set @BH_DATAFORMAT='txt_variable')时，导入SSB数据集某些表总是出错，但最大的lineorder表反而能够导入成功，因此其它小表采用mysql加载引擎加载，速度稍慢，但总时间影响不大。由于ren表记录实在太多，原始数据又带有一些不是整数的非法值，因此没有在Oracle和SybaseIQ中进行字符到整数类型的转换，依靠hui表已经足够说明问题。

　　对于RK数据集，Infobright在利用Infobright加载引擎并关闭自动提交的情况下，仍然比其他数据库慢很多，耗费时间大约是InfiniDB的4到5倍，原因是它的高压缩比要耗费大量的CPU等资源，拖累了导入的性能，如果它能适当地在压缩比和时间之间取得一个平衡，就更实用了。

▲各种数据库加载外部文本文件时间 (单位：秒)

　　把上述数据制作成统计图如下：纵坐标是时间，单位：秒。

▲

　　我们看到对TPC-H数据和SSB数据，Sybase IQ的导入时间最短，对于用户自定义数据，InfiniDB的导入时间最短，Oracle的sqlldr导入一般不如列存储数据库，除了自定义数据集，但Oracle的导入时间不包括数据压缩，若指定导入压缩表，则时间大大增加，不如导入完成以后在数据库中并行转换为压缩格式来得高效。对于Infobright和InfiniDB,导入列类型为整数的表速度更快，而SybaseIQ则不是，对rk的hui表平均比字符类型的hu表慢50%。

　　SybaseIQ不但从外部文本格式文件导入文本表比导入整数类型更快，导出也是同样的结果，看来它的数据类型转换的开销还真的很大。

　　2. 从数据库内部抽取部分数据到其他表

　　各种数据库从库内转移数据的能力各不相同，Infobright,SybaseIQ,Oracle均支持insert into 表1 select * from 表2这种方式。

　　Infobright 虽然支持这种方式，但它的内部操作过程，是先把压缩数据解压缩到cache目录，然后从cache目录读取数据插入压缩表，当数据量较大时，这种做法不但占用了大量磁盘空间，转换时间很长，而且还很容易失败，不如将数据先导出为文本，再用load data加载效率高，因此实用性有限。

　　InfiniDB不支持子查询插入，只能通过文本或操作系统管道导出和导入，这点也有待加强。那么只剩下Sybase和Oracle可以一较高下了。

　　我们从hu表取出ID第一位为'1'的记录保存到hu1表，Oracle占用的时间是56.99秒，上篇文章SybaseIQ的用时是271.953秒。但考虑到SybaseIQ自动创建索引的消耗，这个时间差是可以接受的。

　　Oracle的命令行：

　　(二) 数据压缩

　　Sybase IQ采用sp_iqtablesize('用户名.表名')查看各个表占用的空间大小。我们将Kbytes的数据换算成GB。

　　Oracle采用查询USER_SEGMENT数据字典的bytes列的总和查看。同样换算成GB。

　　Infobright采用du -sh 目录名 查看数据存储目录下的物理文件大小。或者查询information_schema系统库的tables表，这2种方法得到的结果是相近的。

　　InfiniDB的information_schema系统库的信息不正确，也没有提供其它的函数或过程，只能从磁盘空间粗略估算，而且它的命名规律不是人能读懂的格式，只能从导入前后的空间差计算，这点不太方便，有待改进。Calpont的技术支持给我提供了一套脚本，在Linux操作系统下运行，可以列出数据库、表、列占用的存储空间，本文的数据就用此脚本的结果。

　　为了给出和专用压缩工具压缩绿的比较，专门引入了gzip格式的默认压缩文件大小。

　　我们将原始csv文件的大小除以各种数据库压缩后的数据大小，得到的倍数作为它们的压缩率，得到下面的表格：

　　由此得到的统计图如下：

▲各种数据库压缩率统计图(单位：GB)

　　从上图我们可以直观地看出，对于每种数据集Infobright压缩后的空间是最小的，对于整数类型压缩率尤其高，实际上它比gzip的压缩率更高，一般而言SybaseIQ次之，InfiniDB较差，但也不一定，压缩效果跟数据的分布关系密切，比如对于用户实际的rk数据集，SybaseIQ压缩率反而不如InfiniDB。大部分列存储的压缩率和行存储的Oracle相比差别不大，当然，在存储日益廉价的当今，数据占用空间不是主要的问题，更主要的是查询效率。

　　(三) 数据查询

　　系统和数据库参数的配置对数据库性能影响很大，因此，虽然在同一台机器上进行测试，也有必要为各种数据库采用相近的配置。这里，InfiniDB和Infobright均采用安装时默认的内存设置，一般为系统内存的25%。

　　Oracle的SGA和PGA设为默认的40%内存，由于其他数据库不可指定并行度，在Oracle测试时也不指定具体并行度而让查询优化器CBO自行决定。

　　Sybase的缓存大小对性能影响很大，我们把参数文件最后2个缓冲区大小设定为-iqmc 23768和-iqtc 24576。下面各个测试项目列出的均是采用修改参数文件后的结果。

　　1.原始tpch查询测试

　　为了测试的公平和一致，我们采用同一套数据和查询SQL语句，同时用于4种不同的数据库，第一次，只针对不同的数据库作语法修改，尽量不改变语句的结构。

　　测出的结果见原始tpch查询时间对比表。

▲

　　我们看到，infobright的表现还是不尽如人意。区区10GB数量级的数据，如果1个查询时间以小时计或者几十分钟，这样的性能基本不具备实用价值。在3.42 版scala为1时某些数据库执行效率很差的语句，在3.52 版scala为10时仍然较差。InfiniDB 2.02不支持的某些语句，在2.03版本仍然不支持，这也不足为奇，毕竟这不是一个大版本升级而只是一个bug修补版本。Oracle和Sybase在这方面表现不错，基本上所有的原始脚本都能执行，而且基本没有执行特别慢的语句，而且IQ的大部分查询都优于Oracle，可以看出列式数据库的优势。Oracle在启用并行后性能突飞猛进，所有查询都能在10秒以内完成。稍感意外的是，Sybase不支持其它三种数据库都支持的date''、interval''和extract from用法，只好改用date()、year()等函数。而用于限定结果集行数的top语句同limit或rownum的一个明显区别是要求结果集已经排序，否则虽然也能输出结果，但输出错误提示消息。

　　2.人工改写后的部分tpch等价查询测试

　　第二次，为了排除数据库的查询优化器对复杂查询产生的执行计划不合理的影响，我们用人工手段改写了Infobright一些耗时过长的查询，作为我们最终评测的统一的语句放到所有数据库上运行，同时为了解决某些种类数据库对某些SQL语法不支持的情况，InfiniDB额外采用了Calpont技术支持人员提供的等价语句，这样我们得到了下面的人工改写后的部分与tpch查询等价的各种数据库的时间对比表。

▲

　　修改后的语句相比原始tpch查询语句在Infobright当中有着显著的优势，那些运行几十分钟或几小时的查询基本上不到10分钟就能完成了，SQL表达式超过数字精度的语句，通过减少小数点后多余的后缀0也有了执行结果。了我们注意到，修改后的语句有些在Sybase和Oracle中运行时间变长，这是由于它们的优化器对原始tpc-h查询产生的执行计划已经足够好，而我们的修改未必是更好的，这也从一个侧面说明编写跨平台的查询语句，要在各种数据库上都取得较好的结果是多么不易。

　　我们将修改的测试记录(包括Calpont技术支持人员提供的等价语句)和原始测试记录按运行时间最短的结果进行合并，得到了如下优秀的解决方案表格，基本可以反映各种数据库在查询tpc-h时的最高性能。

▲

　　这一轮测试，除了Sybase IQ之外，其他列式数据库都败给了行式数据库，真是一个意外的结果。Infobright由于在1、10、18、21等项目糟糕的成绩拖累，总时间约为InfiniDB或SybaseIQ的10多倍。其实它有些项目成绩还是不错的。

　　下面是以优秀的解决方案表格的Infobright查询时间除以其他数据库查询时间得到的倍数制作的统计图。

▲

　　从图中可以看出，各种不同类型的查询，不同数据库的性能差别非常明显。有的达到了上百倍。

　　3.SSB查询测试

　　有读者反映我的上一系列文章的测试不全面,遗漏了SSB测试，这次专门补充写上，以下是时间对比表。

▲

　　因为Infobright3.52发版说明中声称对连接进行了优化，为了证实这一点，我们把在相同配置下Infobright3.42的测试结果也列出来，从结果可见，对第一类查询和第3、4类查询，速度确实有显著改善，但第2类查询反而有微小的下降。虽然infobright在进步，但距离其他竞争对手的差距还是较大的，13个查询只有3个低于10秒，而其他数据库所有查询都低于10秒。

　　下面我们把各个查询都用较慢的Infobright3.52的用时作为基准，用它除以其他数据库的用时得到倍数，用这个倍数作统计图如下。纵坐标表示速度倍数。

▲

　　从图中可以看出，列存储数据库在ssb测试中对行存储也没有特别明显的优势，InfiniDB和SybaseIQ的性能稍好。其他数据库对Infobright的速度倍数一般在3倍以上，最高达到10倍。

　　五、比较结论

　　由于用户的实际需求千差万别，因此很难简单地划分那类查询属于数据仓库方面而哪些查询不是。比如，tpc-h查询中2个大表的exists和not exists条件查询,Infobright在这类查询的表现难以接受。Ssb scala=10的查询，除Infobright外的各种数据库都是几秒钟完成一个查询，不足以将彼此的差距拉大，如果不是要执行成千上万次，那么随便选那种数据库都差不多是不错的选择。好的数据库管理系统应该能够最大限度地适应用户不同类型的查询语句，并针对不同查询都尽量给出较好的执行计划，当然要做到这点很难，Oracle的cbo优化器10多年来一直在改进，才有目前的水准，对于新兴的列存储数据库，这方面要走的路还很长。

　　Infobright以它的性能表现，目前还不足以担当生产环境的苛刻要求，但正因为如此，编写适用于它执行的SQL语句也成了程序开发人员的富有挑战性的任务。而传统大厂的产品更有广泛的适应性，优化器能帮助程序员解决大量问题，可以让他们集中注意力在业务逻辑上，而不必拘泥于特定产品SQL写法的特殊要求。从Infobright 3.52版本的进步来看，它也在奋起直追，下一个版本应该会更好。

　　InfiniDB在某些方面的确具有了与大厂产品一较高下的实力，可以作为它们的替代品，如果它的价格同样具有竞争力，将成为列式存储数据库厂商中非常抢眼的新星。缺点在上一篇文章中也提到过，支持的SQL写法限制太多，同样需要程序员的额外学习和试验，但这种努力往往也能带来乐趣。

　　Infobright的短板主要落在tpc-h查询的4\17\20\21等几个，这类查询的特点是表间关联条件比较复杂，人工优化的效果更加明显。

　　Sybase作为老牌数据库厂商，在列式数据库起步较早，IQ产品相对成熟，在标准支持方面比较好，缺点是一些工具和配置不够直观，对初学者有一定的难度。

　　再说数据加载工具，几种数据库都还不错，各有长处和短处，Infobright的性能稍差一些，InfiniDB和Sybase 都能较好地利用多个CPU,Linux下很多实用的文字处理命令工具，比如tr,awk可以弥补某些ETL功能的不足，比如Sybase的最后一个列的分隔符问题和cpimport不支持Windows格式的回车换行符等。但最好能在数据库本身的功能中增加这些选项，以便更多的平台都可以使用。Sybase IQ默认的文件数据合法性检查更严格(也可以通过选项忽略约束检查)，而其他数据库有的采取了将非法数据截断的简单处理方式，不利于保证数据质量。

　　从数据库的稳定性方面，Infobright有了长足进步，不再出现lic文件读取错误的问题，InfiniDB和Sybase IQ在执行它所不支持的SQL语法的查询时，有时数据库意外宕机，有待各个厂商提高他们的系统稳定性和容错性。

　　下面将各种列式数据库的功能和性能排名罗列如下，按照在各自测试项目中的表现，分别打1-3分，3分为最优，1分最差。最后加总所有项目的分数，分数越小越好，读者可以依据自己对不同项目的重视程度赋予不同的权数再加总，以求得自己心目中的优胜者。

▲

　　这里没有考虑价格因素，仅仅是从一个最终用户使用的角度做出的评价。

　　由于本人接触列式数据库的时间不长，一些性能优化的方法还未掌握，文章中的不足和错误之处，欢迎读者们讨论和指正。