SybaseIQ非结构化数据解决方案.docx

Sybase IQ非结构化数据解决方案 Sybase IQ是Sybase公司推出的特别为数据仓库设计的 HYPERLINK /view/495393.htm \t _blank 关系型数据库。IQ的架构与大多数 HYPERLINK /view/495393.htm \t _blank 关系型数据库不同，它特别的设计用以支持大量并发用户的即时查询。其设计与执行进程优先考虑查询性能，其次是完成批量 HYPERLINK /view/286818.htm \t _blank 数据更新的速度。而传统 HYPERLINK /view/495393.htm \t _blank 关系型数据库引擎的设计既考虑在线的事务进程又考虑数据仓库（而事实上，往往更多的关注事务进程）。 列存储 IQ以列存储数据，而不是行——这与其他所有 HYPERLINK /view/495393.htm \t _blank 关系型数据库引擎广泛使用的存储方法方向相反。在其他 HYPERLINK /view/495393.htm \t _blank 关系型数据库内核中，数据库的一张表典型的表示为一条数据库页链，每一数据页中有一行或多行数据记录。在 HYPERLINK /view/19711.htm \t _blank 数据仓库应用中，从查询性能的观点出发，这种存储方式是所有可能的 HYPERLINK /view/551712.htm \t _blank 数据存储方式中最不可取的。在IQ中，每张表是一组相互独立的页链的集合，每一页链代表表中的一列。所以有100 列的表将有100 条相互独立的页链，每一列都有一条页链与之对应，而不是象其他数据库引擎，一张表对应一条页链。列存储所固有的优越性在于：大多数数据仓库应用的查询只关心表中所有列的一个很小的子集，从而可以以很少的磁盘I/O得到查询结果。现在考虑这样一个例子，假设我们要得到所有生日在七月份的客户的名字和电子邮件地址。 在一个典型的OLTP数据库引擎中， HYPERLINK /view/684791.htm \t _blank 查询优化器将根据返回行的百分比（如1/12，在本例中，假设各月的生日都基本平均）来决定是否值得在该列上使用索引。因此，典型的数据库引擎对该查询可能会做全表的扫描。为了对扫描??成本做一估算，我们假设每个客户的行记录为3200个字节，共有1000万个条记录。因此， HYPERLINK /view/684719.htm \t _blank 表扫描必须读取320亿个字节的数据。 IQ HYPERLINK /view/68455.htm \t _blank 数据库引擎可以只读取查询所需的列。在本例中，有三个相关的列：全名、电子邮件地址和出生日期。假设全名为25个字节，电子邮件地址为25个字节，出生日期为4个字节（日期以二进制做内部编码）。那么IQ 只需要读取5400万个字节的数据——大约减少了59倍！ 数据压缩 传统的数据库引擎不能以一种通用的方式进行数据压缩，主要是由于存在以下三个问题： 1. 第一个问题是其按行存储的数据存储方式不利于压缩。这是因为数据（大多为二进制数据）在以这种方式存储时重复并不多。我们发现，按行存储的数据，最多能有5-10%的压缩比例； 2. 第二个问题是对于许多的2K 和4K 的二进制数据的页来说，为压缩和解压缩而增加的开销太大； 3. 第三个问题是在OLTP 环境中，大量读取和更新混杂在一起。每一次更新需要进行压缩操作，而读取只需解压缩操作，大多数的数据压缩算法在压缩时比解压缩时慢4 倍。这一开销将明显降低OLTP 数据库引擎的事务处理效率而使得 HYPERLINK /view/286827.htm \t _blank 数据压缩的代价昂贵到几乎不能忍受。 在 HYPERLINK /view/19711.htm \t _blank 数据仓库应用中， HYPERLINK /view/286827.htm \t _blank 数据压缩可以用小得多的代价换取更大好处。其中包括减少对于 HYPERLINK /view/540495.htm \t _blank 存储量的要求；增大数据吞吐量，这相当于减少查询响应时间。 Sybase IQ使用了 HYPERLINK /view/286827.htm \t _blank 数据压缩。这是由于数据按列存储，相邻的字段值具有相同的数据类型，其二进制值的范围通常也要小得多，所以压缩更容易，压缩比更高。Sybase IQ 对列存储的数据通常能得到大于50%的压缩。更大的压缩比例，加上大页面I/O，使得Sybase IQ 在获得优良的查询性能的同时，减少了对 HY