【IT168 专稿】在本系列的前2篇文章（主流列式数据库评测:南大通用GBase 8a和主流列式数据库评测之Infobright）中，列式存储数据库GBase 8a和Infobright给我们的印象是虽然在数据压缩上面有一些优势，整体查询性能还是落后于传统数据库的，下面要介绍的Calpont公司的基于MySQL的InfiniDB和学术组织开发的MonetDB在性能方面有更好的表现。

　　一、安装

　　和Infobright类似，在InfiniDB网站注册一个免费用户就可以上获得社区版和企业试用版的下载，下载地址：http://infinidb.org/downloads/cat_view/40-binary-releases　(社区版)或　http://www.calpont.com/products/tryinfinidb　(企业试用版)。本文测试的InfiniDB版本是2010年12月20日发布的2.02版，下载文件名分别为InfiniDB64-2.0.2-2.exe 和InfiniDB64-ent-2.0.2-2.exe。安装文件大约在30兆字节。32位最新版只提供了InfiniDB社区版，企业版只有64位，包括Windows和Linux平台。

　　64位InfiniDB在Windows 2008 x64上安装总是失败，但文档说是支持的，经技术人员确认，该安装文件只支持在windows 2008 R2 上安装。网站也提供了一些使用手册文档下载和论坛(社区)的支持，这为用户试用带来了方便。相比Infobright，InfiniDB的文档和论坛的技术支持水平都差不多，都是能比较快地解答用户使用的问题。

　　安装界面全是图形交互式的，很简单，一路Next就安装完成了。但最后一步要耗费一定的时间初始化系统表。

　　安装完成以后，在开始/所有程序下新增了一个InfiniDB的菜单项，有服务器启动、关闭的快捷方式，数据库后台服务默认是自动开启的。与Infobright类似，它的安装不包括图形化管理工具，只提供了命令行界面的客户端和其他工具，但有所差别的是，InfiniDB对MySQL作了更大范围的改动，主要体现在下面几方面。

　　1.执行的后台进程更多。

　　2.文件存储方式更类似DB2和PostgreSQL，采取多目录、多数据文件的方式，目录和文件命名对用户不可辨别，而且在数据库和表删除以后，数据文件并不收缩，而是供新增的其他表和数据利用。

　　按惯例，先看一下数据库安装在磁盘上的文件和目录。

　　D:\Infobright 的目录

　　我们看到，比原始的mysql安装目录多了几个子目录，如bulk,data1,etc等。

　　bulk目录用于批量加载数据。

　　Data1目录用于存放infiniDB存储引擎的数据文件。

　　mysqldb目录用于存放mysql存储引擎的数据文件，相当于原来的data。

　　etc目录用于存放系统表初始化脚本和错误提示信息。

　　Bin目录用于存放可执行文件和动态链接库。

　　如上图所示，安装程序在磁盘上创建了几个目录和一些文件。bin目录下面除了MySQL原始的可执行文件，还包括InfiniDB特有的系统文件和工具，其中3个批处理文件，分别用于InfiniDB后台服务的启动和关闭,客户端的启动。

　　之所以需要初始化脚本，是由于InfiniDB是以插件的方式启动的，需要把这些信息写入系统表。首次启动时，安装程序会调用这些脚本。

　　在Windows任务管理器中可以观察到InfiniDB启动了8个后台进程。

　　我们也可以用控制台方式启动InfiniDB，这种方式可以更详细地观察服务器的启动过程，如果启动出错，可以根据出错信息的提示排除错误。

　　我们观察到InfiniDB采用的MySQL版本是5.1.39.

　　再来观察数据文件物理存储，在创建了一些表以后，data1目录下创建了子目录000.dir,下面还有很多类似的子目录。最外层子目录下有FILE000.cdf、FILE001.cdf等，可以看出，数据文件命名对用户是无法辨认的，这为数据备份带来了难度。而前文提到的infobright只要在数据库进程关闭时将某个数据库的目录备份即可。

图3

　　InfiniDB企业版和社区版的具体区别。参见http://www.calpont.com/resources/community，可见社区版仍然支持DML操作，这点比infobright强，但付出的代价是不支持压缩，但即使是企业版压缩比infobright也差很多。我们对tpch scala=10的10GB数据导入以后，占用空间达8775933952字节，只压缩了13%,而同样的数据，infobright占用1951699241字节，压缩了81%。

　　二、数据库的功能

　　数据库的基本功能有CRUD(表的创建、插入、更新、删除)等方面，下面我们逐个测试。

　　下面创建一个test数据库，然后在其中创建一个表t1,可以观察到默认的存储引擎仍然是MyISAM。

　　这是一个需要注意的地方，如果要使用InfiniDB引擎，或者在创建表时显式说明，或者设置默认存储引擎为InfiniDB，建议用前一种。因为后一种使某些查询语句失效，影响查询执行。最简单的语法都报错。

　　对于比较规律的测试数据，可以通过存储过程产生，语法规则和mysql的一致， InfiniDB引擎的DML速度比较慢，无论设置自动提交开关为关闭或开启，插入性能都很糟糕，但更新和删除的效率还可以，并且不支持truncate 表操作。

　　InfiniDBInI的事务处理实现与Oracle的类似，但默认是自动提交的,可设置不自动提交事务，默认是在会话级的。设置不自动提交事务以后，本会话可以脏读，其他会话则只能查询到最后一次提交时的内容。如果多个会话对同一个表执行dml操作，后发出的命令被挂起，等候前一个会话提交或回滚才能执行。大部分和Oracle的表现一致，就不一一举例了。

　　InfiniDB支持中文，不过需要做一些设置。

　　InfiniDB和原始MySQL的SQL解释、执行引擎不同，因此，不支持包含InfiniDB的表和其他数据引擎的表的关联操作，但其他原始MySQL的数据引擎支持从InfiniDB表查询数据并保存结果。

　　下一步是批量插入数据，企业版数据加载仍支持mysql的load data infile命令。但对InfiniDB存储引擎，在大数据量的时候，这种方式的效率太低，不适用。InfiniDB专门开发了二个工具配合，可以达到高速加载的效果，参见下一节测试的结果。

　　InfiniDB专门为InfiniDB存储引擎的表添加了系统数据库calpontsys和2个系统表systable、syscolumn记录一些系统信息，可供用户参考。

　　三、数据加载和查询性能

　　为了提供用户在做数据库选型的参考，下面沿用TPC-H 2.8 scale为1的大约1G字节数据来进行较大数据量的测试，先进行数据加载测试，MySQL原始加载工具在InfiniDB表的性能表现是不可接受的。区区100000行耗时24秒，和Infobright不在一个水平。

　　下面我们来看专用工具cpimport。

　　这里有一个陷阱，Infinidb的默认存储引擎是myisam,该存储引擎不被cpimport支持，所以在调用cpimport时报如下错误：

　　修改ddl语句，重新设置存储引擎，又出现新的问题，原来infinidb不支持约束，包括主键约束和非空约束。

　　取消约束后再次生成表，这下工具可以成功执行了。

　　前面花了较大篇幅描述InfiniDB,下面简略介绍一下MonetDB, MonetDB是一个内存数据库原型系统，目前仍然是一个学术机构的开源项目，差不多每6个月出一个Release，目前版本号为v5.22.1，但文档比较陈旧，只有2008年的，并不推荐在生产环境中使用。除了SQL版本，还有XQuery版本，我使用的是2010年10月发布的SQL版，下载地址为http://dev.monetdb.org/downloads/Windows/Oct2010-SP1/MonetDB5-SQL-Installer-x86_64-20101215.msi，安装包大约8.9M,是目前所测试的几种数据库管理系统中最小的，因为它是个独立的软件，不用包含对MySQL的支持。安装后同样生成启动服务器和客户端的快捷方式。双击即可运行。在客户端执行ddl脚本和导入数据都非常顺利。　

　　下面是查询测试结果。InfiniDB对多种SQL语句的语法支持不太好，原始tpch查询脚 本有6个无法运行，经联系InfiniDB技术人员，使用了他们提供的修改后版本运行成功。  

表1 TPC-H 2.8 scale=1的测试对比，单位：秒

　　*表示原始SQL语法不被支持，修改SQL为等价的方式后的结果。

　　单纯从上面的结果看，似乎MonetDB比InfiniDB绝大多数时候都具有更好的性能，但是对于更大的数据量以后，二者的表现还有待进一步研究。

　　MonetDB只是一个单机版的软件，并不支持网络访问，这限制了它的应用。

　　四、结束语

　　测试进行到这里，相信读者对InfiniDB已经有了初步的印象，查询性能某些方面已经超越了传统的行存储数据库(22个查询中的7个)。但它对SQL写法也是最挑剔的，需要开发人员非常熟悉InfiniDB的语法。MonetDB在scala为1的时候表现优异，除了第21个查询异常慢外，22个查询中的18个都超越了Oracle。而且它对SQL语法的支持上佳，不加修改全部通过，支持with语句查询，支持索引，另外还支持主键和外键约束，这在列存储数据库中是难能可贵的。

　　本系列文章选择了一种国产列存储数据库和三种国外列存储数据库。我们看到，列存储数据库在它声称所擅长的数据仓库应用中还不能取代传统行存储数据库。只有两者结合，各发挥所长才能提供给用户较好的效果。原因有下面几点：

　　1.由于先天的列存储限制，缺乏对索引的支持(MonetDB除外)，降低了进一步优化的可能。而行存储数据库如果加上合适的索引，上述耗时较长的查询还可以大大降低。

　　2.支持的查询语法限制。所有的4种数据库都不支持分析函数，查询类型大打折扣。

　　3.不支持DML操作或者虽然支持，但效率很低。不能存储查询的结果就很难用了。

　　4.多数数据库不支持大量用户连接，不能满足多用户分析需要。

　　5.大多数不包含图形界面管理工具，用户需要另外购置第三方工具。

　　6.如果已有系统是基于传统数据库，如果要往列存储数据库迁移，SQL语法不兼容和不同写法的效率大相径庭使迁移难度很大。

　　另一种商业列存储数据库Sybase IQ也在其文档中明确说明，其需要和传统的Sybase ASE配合使用，方能发挥出更大的作用。这也从另一侧面反映了列存储数据库在当今的处境，还没有达到大规模真正成熟应用的程度。