INFORMIX动态服务器表分片策略的计划和调整

作者：Neo  出处：Unix爱好者家园unix-cd.com 

　　“数据分片”允许在表一级对数据存储进行控制。“表分片”是INformIX数据库的一个特征。用户可以对表中的记录或索引进行分组，并且存储在不同的位置，这样可以将数据存储到多个磁盘上，从而减少对磁盘I/O的竞争。数据分片的方案以及分片数据所存放的一组dbspace构成了“分片策略”。数据分片有两种基本类型：基于轮转分片“和 ”基于表达式分片”，对于“基于轮转法分片”，正如其名字一样，数据是根据轮转法方式存入表中的。“基于表达式分片”则根据表中的一个或多个字段对分片的规则进行定义。一般在预知查询条件时采用这种方式，从而避免查询中对某些分片的扫描。

　　对“表中的数据”和"索引"进行分片主要是为了提高应程序的效率，由于INformIX动态服务器可以并行地扫描多个磁盘上的数据，从而实现内部查询的并行操作，因此采用”分片“技术可以提高查询效率。内部查询的并行化有助于减少对一个复杂查询的响应时间。”表分片“技术与并行数据查询（PDQ）特征联系在一起使用，这样INformIX服务器可以分配多条线索。从所有数据分片上并行地选取数据。此外，还可以仅仅对包含“目标数据”的数据分片进行扫描。从而大幅度地提高了整个系统效率。“DATASKIP"这一个特征还允许用户跳过那些出现故障或者不包含“目标数据”的数据分片，当某些数据所在的盘出现故障时，就可以体现出高度的“数据可获得性” 我们通过大量的数据分片将数据分布在许多的磁盘上，也实现了外部查询的并行操作。这样在大量用户对同一个表进行访问时，可以减少I/O的竞争，每秒钟完成的事务数（系统吞吐能力）也得到了提高。“表分片”技术还通过对存储在dbspace上的数据分片进行备份/恢复操作。


分片方案

　　在“创建表”和“创建索引”时候均可以用到分片方案。索引可以附加在与其相关联的数据上，或与数据分离存放。一个索引如果出现在对表数据的分片方案中，就可以认为索引已经附加在数据上。另外一个方面，如果索引的分片方案与数据不同，就称为索引与数据分离。这种情况下，索引存放在指定的dbspace上。

　　“数据分片”方式主要有两种：“基于轮转法”和“基于表达式”的方案，


轮转法方案

　　轮转法（PR)所使用的分片规则是系统内部定义的。使用这种方案，新追加的记录被存放在轮转法方式指定的下一个数据分片。记录所插入的第一个数据分片也是随机选定，例如，下列语法用于创建一个名为xyz的表：

CREATE TABLE xyz FRAGMENT BY ROUND ROBIN

IN dbspace1,dbspace2......dbspaceN

INformIX不支持用轮转法方式创建索引，因为这样会降低系统性能。轮转法方案的优点在于各数据分片上数据量是比较均匀的，对记录进行更新时，并不需要对记录进行转移。然而轮转法有一个缺陷，在进行一个查询时，要扫描所有的数据分片 。因此，轮转法方案不支持DATASKIP，不允许INformIX动态服务器越过某个数据分片。如果不支持DATASKIP，同时又有一个数据分片出现错误，那么整个查询将会失败，因为不能确定出现故障的数据分片上是否有符合条件的数据记录存在。轮转法方案适用的情况是：用户需要快速加载数据，用户预先不知道数据访问的方式。用户的数据经常更新，或者是用户对于数据分布方式未知。

“基于表达式”的分片方式

对于“基于表达式的分片方案“，用户可以用下面两种规则对数据进行分片”

　　范围规则

　　绝对规则


范围规则

　　范围规则用SQL的关系或逻辑操作定义表的数据分片的边界。范围规则可以包含关系操作符，比如 >,<,>=,<=,还可以包含一些逻辑操作符，比如AND。范围规则最好根据表的某一个字段进行分片，但也可以根据两个或者多个字段进行分片。下面的分片实例运行效率并不很高，因为向表中插入一行时候需要进行太多的运算。所有不符合表达式条件的记录将 存放在REMAINDER dbspace中。基于“范围表达式”的分片方案可以确保只对包含目标数据的数据分片进行扫描。

下面是一个采用“基于范围表达式分片方案”创建表的例子：

CREATE TABLE xyz (aa integer....)

FRAGMENT BY EXPRESSION

aa<=100 IN dbspace1

aa>1000 AND aa<2000 IN dbspace2

REMAINDER IN dbspace3


绝对规则

　　“绝对规则”使用了SQL的关系与逻辑操作符。与“范围规则”不同，“绝对规则”运行用户采用关系操作符与逻辑操作符对规则进行定义。此外，表中可以有多个字段参与分片。

例： FRAGMENT BY EXAMPLE

zipcode=94536 OR zipcode=94538 IN dbspace

zipcode=94025 OR zipcode=92310 IN dbspace

REMAIDER IN dbspace3

对于以上这种分片方案，必须知道每一个邮政编码所联系的数据个数，以确保每个数据分片上的数据量比较平衡，从而使INformIX动态服务器减少扫描的数据分片的数目。指定分片方案时，要确保数据分片之间不互相重叠。此外，定义数据分片时可以不包括REMAINDER分片。


分片的基本原则

　　“数据分片”的表达式必须尽可能简单，因为执行较复杂的表达式将加重CPU的负荷。同时，数据库中并不是每一个表都需要分片，除非能从“数据分片”中得到显著的收益。“分片”的表达式因为能确保磁盘I/O操作均衡，尽管我们没必要制定一个均衡的数据分片方案。如果大量的查询只对表数据中很小的区域进行访问，那么应该用表达式将那些被频繁访问的数据分片到多个盘上，尽管这样的分片也许数据量并不均衡。表达式应该把限制性最强的部分放在前面。对表达式进行修正是为了减少表达式的计算量，减少每次访问的数据量，从而最终减轻CPU的负荷。如果表达式中第一个不等式的结果为假，那么整个表达式的结果也将为假，因此不必计算表达式的其它部分(AND表达式）。比如说，为了插入数值25，下列表达式需要计算6个不等式：

　x>=1 and x<=10 in dbspace1

　x>10 and x<=20 in dbspace2

　x>20 and x<=30 in dbspace3

如果用如下表达式，则只需要计算4个不等式：

　x<=10 and x>=1 in dbspace1

　x<=20 and x>10 in dbspace2

　x<=30 and x>20 in dbspace3

　　分片的表达式中应该避免数据类型的转换。例如，日期数据类型在表达式中内部转换为整数类型。对于频繁更新的字段进行分片，会带来许多管理上附加工作。例如，如果根据一个日期字段进行分片，而超过保存日期的记录被删除，那么包含”超期数据”的数据分片将最终变空。这样就需要删除旧的数据分片，并为最新日期的记录创建一个新的数据分片。

“分片”策略的设计

　　一个“分片”策略包含数据分布方案以及数据分片所存放的一组dbspace。制定“数据分片”策略时需要根据分片的目标以及数据库的信息，诸如硬件/软件特性、查询特性、数据分布等作出决策。同时还需要知道一个现存的未分片数据库是否做转换，以及是否需要临时创建相应的应用程序。在前面的例子中，已经预知查询的方式，则可以加以利用。我们还应考虑到查询方式在将来的不断变化，诸如数据库的区域和/或帐户的附加部分，这一点也很重要。

　　“数据分片”的目标包括最大程度的内部查询并行化、外部查询并行化、提高数据可用性、更细的备份/恢复粒度以及更强的数据加载效率。

　　数据分片获得“内部查询并行化”：是指INformIX动态服务器充分发挥“数据分片”与PDQ功能的优势，并行地处理一个复杂的查询。这是决策支持系统(DSS)一类应用程序的主要目标。DSS查询从一个表中顺序读出大量数据记录。我们推荐使用数据分片。选择“轮转法”分片方案还是“基于表达式”的分片方案取决于查询特征、数据分布等因素，一般来说，当用户不能确定根据表中哪一个字段做“基于表达式”的分片，从而保持数据分片的均衡，或者不知道数据访问的方式时，我们推荐采用“轮转法”方式。“轮转法”方式不支持对索引的分片，因为扫描线索要越过分片的边界去读取索引，这样会导致效率的下降。“分片策略”还应该确保数据均衡的分布在不同的数据分片上，确保并行顺序扫描能均衡地完成。 　　数据分片获得“外部查询的并行化”：是指在大量用户运行较小的查询、返回少量的数据的条件下，INformIX动态服务器最大程度提高性能的能力。一般来讲，对于“存在大量用户，需要实时响应的应用程序，称为联机事务处理（OLTP)。OLTP查询总是在同一时间访问数据的一小部分区域，总是随机地对一些数据行进行更新或者删除操作。这些操作总是和”索引扫描”有关。在这种情况下，应该用表达式将数据表和索引表进行分片，从而允许查询在扫描过程过中某些数据分片。如果不考虑I/O竞争，数据分片和索引分片可以在同一个盘上，并使用同样的“分片”策略。另一方面，在一个大系统中如果额外有空余的盘，并且磁盘I/O可能成为潜在的瓶颈，那么最后将索引单独建在一块盘上。调换一下顺序，当按照某一字段创建索引时候，如果每一个查询都根据同一字段访问数据时，我们也可以使用与“数据分片”不相同的策略对索引进行分片。这种情况下，最好在WHERE子句中使用另外一个字段，“分片”策略的理想化程度取决于数据的分布和对表的查询的分布情况。我们的目标通过数据分布消除I/O瓶颈，尽管每个数据分片上的数据量可能不太均匀。

　　数据分片增强“数据可获得性”：是指可以在某些数据分片发生故障的时候，数据库仍然能接受应用程序的查询请求。这种能力是有INformIX动态服务器的DATASKIP特征提供的。

　　数据分片“增强数据加载的性能”：尤其适用于”周期性地加载几个G的数据，从而需要快速加载技术”的大型应用程序。将数据 分片到不同的磁盘上，可以使数据自动地进行并行加载，这是通过使用多个I/O流向数据分片所驻留的磁盘上写数据而达到的。轮转法分片方案应该最能保证快速数据加载，因为复杂表达式的计算会加重CPU的负荷，如果采取较简单的表达式并将每个数据分片放在单独的盘上，用“基于表达式”的分片方案同样可以保证快速加载数据。


以下是“确定合理的分片策略”所必须的步骤：

硬件/软件特征

　　要搞清楚硬件平台，如CPU的速度，数目，磁盘数目，大小，磁盘控制器的数目，以及与每个控制器相连接的磁盘数目，等等。这些信息对于确认表分片的数目以及怎样存放数据分片以减少I/O竞争，都是十分有用的。除了可用的磁盘外，对于每个表的数据分片的数目都有一定的上限，这些限制与分片的目标有关，如果分片的主要目的是增强内部查询的并行程度，那么系统CPU的数目和数据总线的带宽将限制一个表所能得到的并行线索的最大数目。另一个方面，如果分片的主要目标是增强外部查询的并行程度，那么分片的数目可大于CPU的数目，从而保证数据分布在许多磁盘上，在OLTP条件下可以允许用户并发地访问不同的磁盘，然而，当数据分片的容量变小的时候，应用程序会寻找多个数据分片，同时对寻找的结果进行合并。这些都会降低查询的效率。

　　对于具有高速CPU和低速盘的系统，每个表的分片数目可以超过物理CPU的实际个数。

　　所选的硬件平台 的操作系统类型和编译器对选择“分片”方案也是一个重要的因素。有的操作系统擅长处理MOD操作以及数据类型转换。


了解查询的特征

要了解一个应用程序到底是OLTP还是DSS类型，还要了解SELECT语句查询用的频繁还是update/delete操作频繁。如果查询多用SELECT语句，还要确定带有 “group by","order by"等复杂子句查询的执行频度。对于这些情况的了解有助于平衡I/O，消除瓶颈。检查每个SELECT 查询的选择性以及返回数据的比例。如果一个查询的选择性（selectivity)很大，就需要为查询创建索引。检查有无JOIN操作，并确认JOIN操作的主码是什么。如果在DSS查询中总对某一特定的表进行JOIN操作，那么这个表应该被分片到不同的磁盘上以避免I/O瓶颈。检查每个查询的查询条件。最后将所涉及的表中的字段画一个矩阵。接着将某一查询中用做查询条件的字段填上“+”字符。有了这个矩阵，我们可确认在所有的查询中，哪个查询条件最常用。这一信息与每一查询的执行频度一起，有助于确认对哪个字段做“基于表达式的分片”收益最大。检查数据是怎样被访问的，即数据是通过“顺序读取”还是通过“INDEX SCAN"被访问。为每一个查询配备“SET EXPLAIN" 子句，加上表的模式信息，可以达到以上目标。

数据分布及特征

确认表中用户查询条件的字段的取值范围。确认表中每一取值范围内符合记录的个数。在许多DSS类应用程序中，结果是从几个GB的数据或几个月，甚至一年的数据中得出来的。在这种条件下，很容易确认某一州，某个城市的记录数，或者是整个月的数据供以后使用。如果大多数查询将某个州和某月作为筛选条件，那么这些字段是参与”基于表达式”的分片方式的最佳选择。此外，还应了解表中数据被修改的速率，诸如增、删、改等。